This is currently 4.0.1 and is set as an attribute. The recipe is very simple now, it installs the npm package, and the systemd service runs /usr/bin/sockethub and sets the environment variables
This has been tested in a VM and deployed to nodejs-2. It should be deployed at the same time as a release of Hyperchannel that supports the new Sockethub
This is currently 4.0.1 and is set as an attribute. The recipe is very simple now, it installs the npm package, and the systemd service runs `/usr/bin/sockethub` and sets the environment variables
This has been tested in a VM and deployed to nodejs-2. It should be deployed at the same time as a release of Hyperchannel that supports the new Sockethub
Closes #145, #91
greg
self-assigned this 2020-03-25 11:47:03 +00:00
Aside from this being useful to be configurable as an attribute per node/role/environment, I think this should not use full debug logs in production.
I'm pairing with @slvrbckt in 2 hours, so I'll find out about the best config value here.
Aside from this being useful to be configurable as an attribute per node/role/environment, I think this should not use full debug logs in production.
I'm pairing with @slvrbckt in 2 hours, so I'll find out about the best config value here.
I would suggest DEBUG=sockethub* as a reasonable log level, as it will report on the core sockethub components (sockethub, platforms and schemas) but not the auxilary libraries which would increase verbosity a lot.
I would suggest `DEBUG=sockethub*` as a reasonable log level, as it will report on the core sockethub components (sockethub, platforms and schemas) but not the auxilary libraries which would increase verbosity a lot.
greg
marked the pull request as work in progress 2020-04-21 15:06:26 +00:00
I'm having second thoughts about deploying from the npm package. What if we have to use a hotfix on a whim, because there's a security hole for example?
Perhaps a better way is to keep deploying from Git, so we can point the source to any repo or branch we need. WDYT?
I'm having second thoughts about deploying from the npm package. What if we have to use a hotfix on a whim, because there's a security hole for example?
Perhaps a better way is to keep deploying from Git, so we can point the source to any repo or branch we need. WDYT?
Maybe. But you don't really want to have an official patch release immediately for every experimental or custom fix.
Also, there may just be general customizations that are outside of upstream scope. That's why we deploy most apps from our own repos and branches.
Maybe. But you don't really want to have an official patch release immediately for every experimental or custom fix.
Also, there may just be general customizations that are outside of upstream scope. That's why we deploy most apps from our own repos and branches.
Changed my mind again. You're right, @slvrbckt, security patches should be released asap anyway.
Also, any customizations we have must be useful to someone else, so they should be part of the released feature set, except for testing/staging instances that we can deploy from source.
I'd just turn the systemd unit here into a native Chef resource, now that that's possible. And update to the latest release version, of course.
Changed my mind again. You're right, @slvrbckt, security patches should be released asap anyway.
Also, any customizations we have must be useful to someone else, so they should be part of the released feature set, except for testing/staging instances that we can deploy from source.
I'd just turn the systemd unit here into a native Chef resource, now that that's possible. And update to the latest release version, of course.
This is running on nodejs-2, with a haproxy rules on centaurus. I haven't switched the DNS entry yet (to centaurus' IP, 78.46.59.98), @raucao maybe do that just before you deploy the new Hyperchannel?
This is running on nodejs-2, with a haproxy rules on centaurus. I haven't switched the DNS entry yet (to centaurus' IP, 78.46.59.98), @raucao maybe do that just before you deploy the new Hyperchannel?
raucao
approved these changes 2021-07-14 09:32:35 +00:00
The Websocket issue has been solved, but there's a firewall rule missing for port 10550, to be configured on Centaurus (so it's not overwritten by Chef).
Edit: the firewall rule was there, but obviously not run the last time Chef was run against centaurus from master. m(
<del>The Websocket issue has been solved, but there's a firewall rule missing for port 10550, to be configured on Centaurus (so it's not overwritten by Chef).</del>
Edit: the firewall rule was there, but obviously not run the last time Chef was run against centaurus from `master`. m(
raucao
approved these changes 2021-08-31 08:59:46 +00:00
raucao
merged commit 483481b141 into master2021-08-31 09:00:07 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
raucao
This is currently 4.0.1 and is set as an attribute. The recipe is very simple now, it installs the npm package, and the systemd service runs
/usr/bin/sockethuband sets the environment variablesThis has been tested in a VM and deployed to nodejs-2. It should be deployed at the same time as a release of Hyperchannel that supports the new Sockethub
Closes #145, #91
@@ -81,0 +57,4 @@user: "sockethub",group: "sockethub",entry: "/usr/bin/sockethub",environment: { 'DEBUG' => '*',Aside from this being useful to be configurable as an attribute per node/role/environment, I think this should not use full debug logs in production.
I'm pairing with @slvrbckt in 2 hours, so I'll find out about the best config value here.
@slvrbckt Could you add a comment here perhaps about which log setting you think would make sense in production?
I would suggest
DEBUG=sockethub*as a reasonable log level, as it will report on the core sockethub components (sockethub, platforms and schemas) but not the auxilary libraries which would increase verbosity a lot.I'm having second thoughts about deploying from the npm package. What if we have to use a hotfix on a whim, because there's a security hole for example?
Perhaps a better way is to keep deploying from Git, so we can point the source to any repo or branch we need. WDYT?
@raucao wouldn't it be sufficient to just have a patch release of sockethub that you could update to?
Maybe. But you don't really want to have an official patch release immediately for every experimental or custom fix.
Also, there may just be general customizations that are outside of upstream scope. That's why we deploy most apps from our own repos and branches.
Changed my mind again. You're right, @slvrbckt, security patches should be released asap anyway.
Also, any customizations we have must be useful to someone else, so they should be part of the released feature set, except for testing/staging instances that we can deploy from source.
I'd just turn the systemd unit here into a native Chef resource, now that that's possible. And update to the latest release version, of course.
This is running on nodejs-2, with a haproxy rules on centaurus. I haven't switched the DNS entry yet (to centaurus' IP, 78.46.59.98), @raucao maybe do that just before you deploy the new Hyperchannel?
LGTM. 👍
Feel free to switch the DNS. I'll push Hyperchannel then.
Found a problem with the new setup: #333
The Websocket issue has been solved, but there's a firewall rule missing for port 10550, to be configured on Centaurus (so it's not overwritten by Chef).Edit: the firewall rule was there, but obviously not run the last time Chef was run against centaurus from
master. m(