Contrib-node version management and process restarting

Core Development Feature Requests
1

I’m sure there are clear cut reasons why this is not implemented as this, but I only wonder if it’s technically possible to upgrade nodes in the node-RED palette and restart those parts of the flows with new versions without restarting node-RED as such?

Also if choosing a version of nodes in the palette is feasible.

2

We cannot upgrade the nodes without a restart of the node.js process to load their new code.

The current catalog format doesn't include a history of versions, just the most recent. But it is something to consider.

3

That makes sense. And even without that limitation I’m sure there are other reasons not to automatically restart parts of flows for users.

Even when reading release notes first (and sadly not bothering with a staging environment) sometimes there are problems with new versions of nodes, and a quick downgrade would be a very nice option in the UI.

Oh, and a “restart Node-RED” button? Sometimes I don’t have SSH handily available.

Other than that, I love it and node-RED-ing gives me great joy in the evenings of this dark season. Especially when I create something fail-safe which “just works” with above average W.A.F.:slightly_smiling_face:

4

Oh, and a “restart Node-RED” button? Sometimes I don’t have SSH handily available.

When node-red stops, it cannot start itself

I see that someone was able to use an exec node with node-red-restart (i thought you needed sudo for this but ok, perhaps you could try it)

5

You do need sudo for node-red-restart, at least on Raspbian/Linux. However you can tell the system not to require a password for systemctl, then you can use sudo (with systemctl in node-red-restart). For a home system which is not accessible to the internet this is probably a minor security risk.

6

This is what I do - or rather I tell sudo that the user running Node-RED is allowed to issue the systemctl command without requiring a password. It is pretty secure for the most part if you only use that login for Node-RED, have a nice strong passcode and don't allow remote (SSH/VNC) logins for that user.

There is some residual risk from an attacker gaining access and then being able to swap accounts but it is pretty small if you follow standard secure setups which you should be doing anyway if you are allowing remote access to your device.

Slightly off this topic but just for completeness:

I now have one of my Pi's set up with a flow that will turn on a secure NGROK channel via a Telegram bot. I can use NR remotely then another Telegram bot command turns it off again so I don't need to leave it running. I configure NGROK to only allow HTTPS and I have an uid/pw set up as well. So you need to know the dynamically created URL and the uid and the password. I recon that is plenty of security for something that will only be online typically for maybe an hour very occasionally.

7

Yes, that is what I meant, though not what I posted. Not to allow anyone to use systemctl without a password, just the node-red user.

8

You can even set up the sudoers file to only allow commands with specific arguments to be run without password. That way you can allow systemctl for only certain applications, for only specific actions, for example status and restart, but not stop.
http://manpages.ubuntu.com/manpages/eoan/en/man5/sudoers.5.html
For a practical example, see https://unix.stackexchange.com/a/366420

1 Like