Error after changing port

[quarfie]

I would like Node-RED to listen on port 443.

I changed

uiPort: process.env.PORT || 1880,

to

uiPort: 443,

and also tried

uiPort: process.env.PORT || 443,

but in both cases I got this error when trying to start Node-RED:

I already tried running

sudo lsof -i -P -n | grep LISTEN

to confirm that port 443 is not in use.

Ubuntu 20.04
Node v12.22.0
Node-RED v1.2.9

edit: by the way, I do have SSL working. Used these instructions:

Node-RED SSL using Letsencrypt & Certbot

I've written this up in case it helps other who may wish to secure their node-RED online presence, by using SSL certificates. The installation uses Letsencrypt to issue the certificates and also Certbot to fully automate and handle renewals - so it's a fit & forget solution. Pre-requisites I've started with a RPi3b+ and a fresh 'Buster' operating system, with node-RED installed via the official script. Because node-RED is going to provide my online presence, no other webserver (such as apach…

[Andrei]

The error message in the log indicates permission issue. The reason is that it is necessary root privilege's to use ports below 1024.

Some references:

Raspberry Pi and UDP?

The error is exactly what it says: If you want to use a port number < 1024, you need to run as root. We generally recommend not to run as root, so if you can, pick a port higher than 1024.

Problems to open port 162 (SNMP-TRAP)

I want to use node-red-contrib-snmp-trap-listener to receive traps via snmp, on port 162, but I get this error "can't open port: 162". I have the same problem with node-red-contrib-syslog, which uses port 514. I have read that only the root user can open privileged ports (1-1024). Is there any way for node-red to open privileged ports without error? Best regards

Modbus TCP Server on port 502

Not to bump an old thread, but for anyone who comes searching, the most likely culprit is needing root access to listen on a port less than 1024, assuming you're running Node-RED on a Linux device.

[quarfie]

Thanks - that explains it.

While I see options there to get around the permissions issue, it seems like it makes more sense to use NGINX reverse proxy to solve this issue. Then, I think, I can also do things like redirect requests on port 80 to 443, or perhaps accept requests both ways. Neither of which I believe I can do with Node-RED alone.

I found this guide. Do you think this would put me on a better track? Node-red server with nginx reverse proxy howto guide

[meeki007]

@quarfie wrote: ".....or perhaps accept requests both ways"

Redirect 80 to 443 - Accepting requests on port 80 for services exposed to external networks (the big bad internet) is a bad idea.

the guide - if you have questions just ask.

[quarfie]

Thanks, @meeki007

I run into trouble when I try to sudo apt install nginx

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nginx : Depends: libssl1.0.0 (>= 1.0.2~beta3) but it is not installable
E: Unable to correct problems, you have held broken packages.

I'm unsure if it's related, but when I sudo apt update, I get a couple 404s:

Hit:1 http://ca-central-1.ec2.ports.ubuntu.com/ubuntu-ports focal InRelease
Hit:2 http://ca-central-1.ec2.ports.ubuntu.com/ubuntu-ports focal-updates InRelease                                        
Hit:3 http://ca-central-1.ec2.ports.ubuntu.com/ubuntu-ports focal-backports InRelease                                      
Hit:4 https://deb.nodesource.com/node_12.x focal InRelease                                                                 
Ign:5 http://ppa.launchpad.net/certbot/certbot/ubuntu focal InRelease                                                      
Get:6 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]                                                
Hit:7 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease                                                        
Hit:8 http://nginx.org/packages/ubuntu xenial InRelease                                                                    
Err:9 http://ppa.launchpad.net/certbot/certbot/ubuntu focal Release             
  404  Not Found [IP: 91.189.95.85 80]
Ign:10 http://security.ubuntu.com/ubuntu bionic-security/main arm64 Packages
Get:11 http://security.ubuntu.com/ubuntu bionic-security/main Translation-en [310 kB]
Ign:10 http://security.ubuntu.com/ubuntu bionic-security/main arm64 Packages
Ign:10 http://security.ubuntu.com/ubuntu bionic-security/main arm64 Packages
Ign:10 http://security.ubuntu.com/ubuntu bionic-security/main arm64 Packages
Ign:10 http://security.ubuntu.com/ubuntu bionic-security/main arm64 Packages
Err:10 http://security.ubuntu.com/ubuntu bionic-security/main arm64 Packages
  404  Not Found [IP: 91.189.88.152 80]
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/certbot/certbot/ubuntu focal Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

[Colin]

Try
sudo apt full-upgrade
And if that doesn't help then
sudo apt install -f

[quarfie]

Thanks, but there was no change after running these.

[Colin]

I am at my PC now and looked at your output more carefully. Your sources list is a complete mess. You are running Ubuntu 20.04 (which is focal), but you have a xenial (16.04) source for nginx (that is no doubt the primary reason for the nginx install problem) and a whole set of bionic ones (18.04). Finally the certbot ppa you have specified does not support 20.04. I suggest you edit your sources list and start by getting rid of all the xenial and bionic ones and then try
sudo apt update
sudo apt full-upgrade
and then see where that gets you.
Once everything else is sorted then you can look at the certbot ppa. Why are you using that?

[quarfie]

Good questions. Although I don't know the answers you inspired me to blow it up and start over using @meeki007's tutorial, which is really excellent and way better than the resources I was trying to follow the first time.

And everything is working perfectly.

Thank you!

[meeki007]

Awesome! glad its working. Thanks Colin for stepping in when i was away.

Hey Breaking things "blow it up and start over" is how I learn 90% of the stuff I'm working on. Now and again I think back to times before and the amount of resources/time lost because you could not just delete a line or reinstall.

Well I'll just throw away 10,000 copies of that pamphlet because it was printed on green paper stock instead of red.

[quarfie]

One issue with Nginx... the value of msg.req.ip is 127.0.0.1... can Nginx pass through the original IP?

[meeki007]

yes! that is what:

#Forwards the real visitor remote IP address to the proxied server
		        proxy_set_header X-Real-IP $remote_addr;

in the nginx hosts is for.

node-red, dashboard, and worldmap all support this. using the stock node-red look in the msg.[somting?].headers section to see the ip of the user connected.

as for other nodes they may or may not handle proxy correctly.

Update:
msg.req.headers["x-real-ip"] is what your looking for.

[quarfie]

Amazing. Thanks again.