Restart node-red inside node-red

Hi,
I find a flow that helps me to edit settings.js in order to set a password protection.
It works fine but normally I have to restart node-red (needs to read settings.js on boot).
Is it possible to restart node-red within node-red. I mean some flow code that I can trigger.
If we can do that we can help people to set their password to node-red setup without having any cli expertice.

You can use an exec node to call node-red-restart

The how is somewhat dependent on your platform and how you run Node-RED.

On Linux when run under systemd, you need sudo to restart it and so will need to add the appropriate command to sudoers so that you don't get prompted for a password.

If you are running node-red manually, you need to capture the PID as a global variable in settings.js so that you can kill it from within node-red.

Either way, you might also like to set up a watch node so that changes to the file will automatically trigger a restart. I often do that when developing uibuilder solutions.

Another alternative would be to use something like PM2 to run node-red. You can configure PM2 with a watch, again to auto-restart on file changes.

Thanks for the answers. The node-red is running on aws lightsail container which is provisioned with node-red official docker image. Sorry not to tell this at the beginning. Can you please help for this situation.

Regards,
Nuri

Sorry, don't really use Docker much so can't really help. I think it will be a Linux container though. I am sure it will auto-start so probably uses systemd or some equivalent.

No, the container will run for as long as the entrypoint executable is running. Once that stops the container will stop. (For the official container the entrypoint executable is Node-RED it's self).

If it restarts is down to how the container runtime is configured.

And no, there is noway to control any of this from within in Node-RED.

Also as an aside, unless the /data directory is a mounted volume, restarting the container will not persist any changes so it will not include the changes to the settings.js.

Yes that is what I am having at the moment. If I restart the container from lightail panel it did not persist the settings.js.

Containers are the fastest and the easiest solution for ordinary users that want to try node-red. But not having a password protected environment is not acceptable.

Rather than re-invent the wheel may I suggest you look at FlowForge? (full disclosure I work for FlowForge Inc)

It is a system specifically for managing mutliple Node-RED instances. It can be made to use AWS Firecracker VMs with Kubernetes which iirc is similar to the lightsail containers...

https://flowforge.com

2 Likes

I'm runnig the official docker on AWS but using Fargate and I can restart my docker with a system node and command reboot now
Works fine.

[{"id":"77bc37b9d8f69f5e","type":"debug","z":"e598616e5e82dd15","name":"stdout","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1310,"y":140,"wires":[]},{"id":"9df694a9a4bb2b0f","type":"debug","z":"e598616e5e82dd15","name":"stderr","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1310,"y":180,"wires":[]},{"id":"a5b61c83e2c08d12","type":"debug","z":"e598616e5e82dd15","name":"retcode","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1320,"y":220,"wires":[]},{"id":"7aea7cca7eb973e8","type":"exec","z":"e598616e5e82dd15","command":"reboot now","addpay":"","append":"","useSpawn":"true","timer":"","winHide":false,"oldrc":false,"name":"","x":390,"y":240,"wires":[["77bc37b9d8f69f5e"],["9df694a9a4bb2b0f"],["a5b61c83e2c08d12"]]},{"id":"2ceb381ba0bf7995","type":"inject","z":"e598616e5e82dd15","name":"Restart","props":[],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","x":210,"y":240,"wires":[["7aea7cca7eb973e8"]]}]

But that doesn't solve the persistence problem. A proper framework is the right way forward here

I will go and look at it. Can I have my own FlowForge by deploying it to aws from github source?

Can we persist the flows by mounting a data directory to a volume outside the container in AWS Fargate?

Yes, you can run your own (though we haven't used it with firecracker yet)

And no need for volumes with FlowForge as it uses a storage plugin and stores settings and flows in a database.

Yes, we have an EBS mounted as /data

I hope I don't get you wrong (I'm not familiar with containers) but wouldn't it help if you implemented a check (in user-authenication.js) for the adminAuth property in settings.js? We have a node-red dashboard ui where a user can change his/her password which is put in an sqlite db and whenever the user accesses the editor, the password entered (then hashed) gets compared to the one stored in db. I can give you more details if this may fit the bill.

Thanks for the info @r0ller That is what I am looking for. I want the users can set and change their password. I want it to run in a container because it is very easy to set up a node-red server on container which returns with https endpoint with port 80. If you can share with me more info regarding your UI I will be happy.

What are the prerequisites for installing flowforge on aws. I can not make it run.

Hi
I'm just a long time user of Node-RED and an open source advocate and I'm NOT speaking for the NR or Flowforge team

This is what I think
Discussions of Flowforge should take place via Flowforge site

IMHO Flowforge is designed to be a commercial success and although the project is open source, there is no value for the Flowforge team in assisting someone running their own instance of it (unless that assistance is paid for)

Just my opinion :slight_smile:

1 Like

You are not wrong :slight_smile:

The dashboard ui part is pretty simple, the pw is hashed via bcrypt and gets stored together with the user name in a db table.

The tricky part is to implement the check when the user enters the editor. In setting.js we set the adminAuth property and the httpAdminMiddleware like:

adminAuth: require("./user-authentication"),

httpAdminMiddleware: function(req,res,next) {
//console.log("req.originalUrl:"+req.originalUrl);
    if(req.url.startsWith("/red")===true){
         process.env.checkEditorRequest='true';
    }
    next();
}

This references the user-authentication.js file and sets an env. variable (checkEditorRequest) if someone enters the editor. There may be better ways now but the hint to check for /red came from Knolleary. In the user-authentication.js (which is developed according to the docs) we check if the env. variable checkEditorRequest is set to 'true' and in that case we compare via bcrypt the entered password with the db counterpart. If the passwords don't match, we simply do a resolve(null) as in the docs. Of course, after each check (when the env. var. was set to true), the env. var. must be set back to 'false' in user-authentication.js so that the two code parts play nicely together.