Node-RED Install Script - for v5

General
21

Would it be worthwhile chaining a usersettings.js file instead ?

All standard stuff in the settings.js file, then it looks for a usersettings.js file - anything found in there overrides what has been set in settings.js ?

Julian and others can then play to their hearts content, you can deliver a standardised settings.js that follows best practices and then anyone can override this is they feel comfortable ?

Craig

22

Yes, that's pretty much what I was suggesting. It would be a lot more robust.

23

That is the way other applications manage and secure their config.

For example Mosquitto:
There is a config file /etc/mosquitto/mosquitto.conf (or C:\Program Files\mosquitto\mosquitto.conf) and a directory conf.d with local .conf files to override and extend the defaults.
Mosquitto user credentials are held in a separate file /etc/mosquitto/passwd (Windows - dunno)

Could a similar scheme be adopted for Node-red?

  • Does the runtime need to edit the settings file? I think not, but creating a new settings file at startup if none exists would have to stop.
  • Does NR need to handle multiple instances with different settings? Yes.
  • Does NR require multiple users per instance? Yes.
  • No doubt many more questions...
24

In theory the settings.js file does just contain defaults anyway as they should all be defaulted in the core (may not be quite true... but) - so the settings.js is really mainly for "documentation" of the options and so should be considered the users one anyway... (also how does conf.d translate cross platform - just more complication).

25

You would be so cool if you did tho...

Honestly, this is a huge failing for all my installs. They're kept up to date via the script, but I never make the time to update settings files and so I have no clue what's going on with most of the older installs and what a modern setting file even looks like at this point. Maybe a prompt to ask if the script should try to reconstruct your settings file?

Anyway, thanks again for the hard work.

26

This is the biggest problem for me. I have to keep copies of all original settings.js files, compare the differences and then apply those to my own files. It is, quite frankly, a pain. And one of the weaker aspects of Node-RED in my view.

But that is a trivial issue. We already have sub-folders for things. Just specify a standard name in the userDir - preferably one that starts with a dot which most OS's already recognise as being a system thing. So a .conf folder inside the userDir - issue sorted and fully cross-platform compliant.

Agreed! :smiley: You know what we are like Dave - we can never stop innovating. :rofl:

27

Please consider the already well-aired security failings of that arrangement, which are eliminated by using eg /etc/node-red/setting.js or similar.

But if you must lay down your application at the altar of cross-platform uniformity, at least modify the security advice given at the end of the Linux install script to say.

  • First make the settings.js file immutable
  • Then forbid or severely restrict the node-red user's access to sudo
28

Indeed. And the revision as suggested in this thread would indeed greatly improve this issue given that the core settings would be in a secured area and inaccessible to flow authors. The issue with a sub-folder could be dealt with by using an external folder with a soft link I believe. Or by using Linux/Windows ACL's (or both!)

Haha, yes, we absolutely must! It is one of Node-RED's core strengths. :smiley:

Good points indeed - and they probably should be in the Node-RED documentation?

29

No it isn't!
There is a totally separate installation and startup procedure for different platforms.
(And the Windows versions suck, Someone [a Leader of men] has devoted a great deal of time to greatly improving the Linux experience)

Cross-platform interoperability yes. Uniformity no.

30

I like the --nodexx option as it allows me to update nodejs without all the hassle

31

For v5 models 24 is the answer. So no need for the option :slight_smile:

32

I think @Buckskin means that when an upgrade is required then the script may well be the easiest way to do that. I must admit that I have used the script just to upgrade nodejs on occasions.
If the script is not going to upgrade then we will have to work out for ourselves how to upgrade, and remember to run npm rebuild.

After a nodejs upgrade is it necessary to run npm rebuild on node-red itself as well as in the user folder?

I suppose that, if the script no longer upgrades nodejs, then all one has to do (on a debian based system) is run 'sudo apt remove nodejs` before running the script.

33

Yes. I think the basic scenarios are

  1. clean install - Just run the script
  2. just upgrade/ update Node-RED - Just run the script
  3. Just update nodejs ( same version) - run sudo apt update && sudo apt upgrade
  4. Just upgrade nodejs ( new version 24) - run sudo apt remove nodejs then run script

Any I am missing ?

Some of my thinking is that we generally only recommend one version of nodejs as ā€œtheā€ current best version to run on so the script may as well just do that. If the user wants to or has already installed another ( older or newer) for many reasons then we wonā€™t touch and maybe break it for them. (though we may flag it as too old for example)

And no you should not need to run rebuild against the core as I donā€™t think we have any binary dependencies in there. But if you did the apt remove nodejs and then run the script you would get a new build anyway :slight_smile:

34

The potential issue there is that a major version of NR may span multiple LTS versions of node.js since they currently change fairly rapidly. So unless NR versions are more closely tied to node.js versions, there is a really good chance that people would indeed need to be able to change node.js versions.

35

Yes sort of. So far I have kept the script to one LTS version eg node 20 for NR v4 and no- one has complainedā€¦ so even if we do every other LTS as long as there is an overlap in support between them then :person_shrugging: . Of course if there is an imperative I can change the recommended version. And as I said Iā€™m not stopping anyone installing whatever they want.

36

I wonder whether it would be worth keeping the --nodejs option to allow the specification of which version to install, but still only install if it is not already installed. That would make it easier for those wanting to check compatibility with the next version before it becomes the recommended one. V26 is already available and 24 will go into maintenance mode before the end of the year.

[Edit] I meant only install the specified version if no nodejs is installed. If a different version is already installed then just show a warning that it has not been upgraded.

37

Not yet they haven't but time is running out. v20 runs out of support in April. So a delay to the release of v5 might put Node-RED out of use in some controlled production environments.

Of course, if node.js moves to annual major releases as they are discussing at the moment, this might be easier in the future. Though I have noticed some potentially breaking changes in node.js 24 and beyond which may impact some contributed nodes or even NR core. Any of these things might delay someone from being able to up-version.

Anyway, as you say, people can still manually install node.js (something that I actually recommend, at least for dev environments since it is good to learn the basics of the platforms you are dependent upon).

And it is your script to do with as you wish! :rofl:And anyone could contribute and extension or a different version if they wanted to. :smiley:

38

... a different version ??? who would do such a thing... :wink:

39

The problem that I am struggling with is.... That as armv6 support is dropped with v24 - then if I allow the option to select nodejs version then I have to handle the "You can't do that on this platform" and all the possible combinations of options that may fight against each other. If I just force v22 for arm6 and 24 for everything else then it's a lot cleaner.

Once everyone gets past us dropping the Pi1 and old Pi0 (indeed maybe when node 26
goes mainstream) then I could add back in more flexibility.

PS. In fact the current script does default to nodejs v22 :slight_smile:

PPS. again I stress I won't be deleting anyones nodejs install - and so far v5 seems to still run fine on nodejs22 for me at least - so while we will "support" v24 I'm sure v22 will still be fine for a while yet

40

True, I had forgotten the arm6 issue.