Hi all,
For anyone who uses it, I've just published a new version of the alternate installer for Node-RED.
Not a major update but a couple of corrections, especially to the example systemd script. Also some improvements to the example settings.js file which contains some best practice, extended help and some additional settings.
Brings the package into line with v3.0.2 of Node-RED.
Thank you 
This is my goto tool for adding in extra NR instances on a machine that's already running a standard install
For security perspective alone, I would vote to make it default behavior. Are there any downsides to installing node-red in non admin mode ?
Only 1 as far as I know and that is that your setup is not the one often assumed by forum respondees and tutorials
Otherwise, it is a far better solution for a production setup. Especially when coupled with the use of a dedicated user id and group which is something I really should probably add to the setup as an option. Such a setup brings node-red into line with other services such as web and DB servers which also have dedicated user ids and groups.
Of course, separate uids/groups does make some things a bit more complex in that you need to manage access to folders, files and resources that a standard login user would normally have access to but a dedicate account would not. But then that same complexity is what makes everything safer.
I am assuming most of the times, node-red is self contained. So having it sandboxed will be awesome. Any external file share can be easily handled by regular file sharing methods. How do we take this suggestion to node-red gods ?
It is considered an advanced topic and so I don't think will ever be the standard approach. What is probably needed is more time to expand this alternate installer to make it more comprehensive and bullet-proof. But at present, I just don't have any spare time sadly.
Though contributions always welcome!
... The gods are omnipresent ...
The original path was chosen as we were trying to work closely with the Pi guys, and to get Node-RED as part of the default software load. To do that it had to be a deb package and installed from the repo. And the default for that is to load things into protected space and not mess with user space. Also the separation meant that it was easier to make sure we didn't accidentally wipe user configs or flows etc... which would be bad. So for several good reasons it is as it is...
Of course over time, things move on... Pi themselves slimmed down their pre-installed suite, and more recently moved away from the default pi user, and so on. So yes we are not totally averse to the concept of more local installs, but as has been pointed out due to the "legacy" all the default help and advice starts by assuming the install is as per... so we are not immediately going to change it.
However as the core project is tracking major nodejs releases then we could consider various "breaking" options at that point, such as dropping Arm6 (as no official nodejs version available), and x86, etc... but would need to consider the ramifications of that first of course.
how about creating two different packages, one which with current pi support and other for x86 linux/ubuntu user space ?
Because no-one wants to look after two different scripts, create two sets of docs, confuse users when both are Linux and what about Ubuntu on Pi. Just no.
You mentioned that this could be considered during next breaking change. I am good with that.
One suggestion is during the transition phase, there could be dual release where current method is offered in maintenance mode. There are several products which offer multiple variations (for different platform/deployment measures). Like Home Assistant, Tasmota etc. So it wouldn't hurt to have an overlap during the transition. For now I am switching to docker.
probably around April 23. Depends how big a change we end up going for. Either way we would probably leave the old script available for anyone who needs it.
Are we talking about a change so that node-red is installed under the user rather than globally? If so then I am sure you will be considering how existing installations will upgrade their node-red version.
All has to be considered.
I have been successful with the older version of the installer. It brings Node-RED to another level. We are communiating between instances with MQTT. It opens up running independent threads and cross monitoring of each instances status.
TotallyInformation , would you consider releasing a docker container with your code ? That will make it incredibly easy to spin up multiple instances while not using root user.
Probably not since that would need me to learn how to do that and then also maintain it.
Though possibly I might be persuaded to include a build script using Gulp if you know how to generate/update and upload docker containers?
err - surely the whole point of docker is the container isolation so you can use the existing Node-RED docker image and run up as many as you want ? how it is installed inside the container shouldn't make a difference.
@dceejay current node-red in docker still runs as root. I am not sure if it will run without root. If it does, that will be awesome !
@TotallyInformation , I can try creating a docker (still learning docker), from what I know, docker can run scripts, move/copy/delete files at time of installation. I see your method uses javascript for installation, is there a shell script equivalent ? That will make it easier to setup docker container with no root.
No, it is all JavaScript because that works across all platforms having node.js installed which is a pre-requisite for Node-RED anyway. That isn't going to change I'm afraid.
Does that matter? The "root" inside docker is, after all, not like the host OS root and I don't believe that the docker version of node-red can change itself.
... but it's inside the container - so it doesn't have access to the rest of the host machine - and one instance can't interfere with another. It also runs as the node-red user. What problem are you trying to solve ?
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy