I run a pfsense VM (172.30.12.1) which is connected to my modem (192.168.1.254) and all my devices get 172.30.12.xx addresses from pfsense, including unRAID which has a static 172.30.12.x IP address

 

Pre 6.4, when unRAID booted it would get in a bit of a muddle because it's looking for the 172.30.12.1 gateway via the VM which isn't available yet, but eventually it and dockers would 'give up' and then the pfsense VM would load and all would be fine after about 15 mins.

 

With 6.4, I don't think unRAID is happy with there being no internet connection and gets stuck at this step:

I waited over 30 mins, tried again and had the same problem so I've rolled back to 6.3.5.  Unless this is fixed, I don't think I can use 6.4 and pfsense at the same time - a lot of users seem to be using pfsense as well, so I think they'll have similar problems

Edited November 28, 20178 yr by DZMM

personally I read that log as something has already used port 443 prior to unraid UI attaching to it.

 

Do you access any services(plugins, dockers, VMs) on unraid using https on port 443.

Also if this really is a case of unraid wanting the IP set before the VM starts up, why not apply the static IP on unraid instead of a static DHCP lease?

 

see 

 

Edited June 6, 20179 yr by Tuftuf

Port 443 is used by nginx by default. You have a port collission and need to change either nginx (see go file) or your dockers.

 

Doing pfsense on unRAID in a VM can lead to a catch 22 situation, my personal preference is to use a separate appliance as firewall.

 

 

ahh thanks - I've got letsencrypt running on 443

Is there a case for requesting a feature to delay docker startup until VMs and\or nginx for the WebUI have started? this would fix:

 

• Port 443 collision with dockers assigned that IP (which could be a few!). Assuming the default docker behavior to check the port and not start the container if its already in use? I know docker does that across containers, but not sure if its smart enough to check outside of docker? better for the container startup to fail than the whole server.
• Extra networks being available from the get go without a docker restart for those of us with PfSesne in a VM handling DHCP.

 

I can see this being an issue when this gets rolled out as stable to less savvy users.

Edited June 6, 20179 yr by billington.mark

27 minutes ago, billington.mark said:

Is there a case for requesting a feature to delay docker startup until VMs and\or nginx for the WebUI have started? this would fix:

 

• Port 443 collision with dockers assigned that IP (which could be a few!). Assuming the default docker behavior to check the port and not start the container if its already in use? I know docker does that across containers, but not sure if its smart enough to check outside of docker? better for the container startup to fail than the whole server.
• Extra networks being available from the get go without a docker restart for those of us with PfSesne in a VM handling DHCP.

 

I can see this being an issue when this gets rolled out as stable to less savvy users.

 

I understand the reason of your request, though the simple solution is to NOT autostart the 'offending' container(s)

Port 443 collisions are going to be a big problem when everyone starts upgrading. Would it be possible for unRAID to detect that nginx couldn't start on 80 & 443 and try again on just 80?

Sent from my ONEPLUS A3000 using Tapatalk

Or start the nginx process before the docker process?  That way Unraid will come up and then at least sorting docker out is easy.

Either way, i think something needs to be in place... people will blind upgrade and ignore any warning in release notes about the port collision, even if its in big red flashing letters, people will scroll past for the download link and just upgrade

. 

Starting the docker process only once nginx has reported up and grabbed 80&443 seems the most logical solution.

Edited June 6, 20179 yr by billington.mark

35 minutes ago, billington.mark said:

Either way, i think something needs to be in place... people will blind upgrade and ignore any warning in release notes about the port collision, even if its in big red flashing letters, people will scroll past for the download link and just upgrade

. 

 

I am guilty of not looking at my own screenshot as I assumed the problem would be over my head and that the problem was pfsense, without actually seeing that the message mentioned port 443 which I could have worked out myself I think!  The 443 warning isn't in the release post (CHBMB added it in a separate post) - it definitely needs adding there.

 

+1 from me for changing the boot sequence if possible - I think having an option isn't the solution as people would have to know/remember the option is there.  

 

But, for now I'm going to just temporarily turn off auto-start for dockers if I need to reboot to shorten the time it takes my server to come online again

I thought there might be some issues in this area.  I think there are two separate issues, sequencing and use of port 443.

 

For sequencing, pre-6.4 works like this:

1. emhttp initialized (state valid)
2. emhttp accepts http connections on port 80 (or user-specified via 'go' script)
3. start docker - autostart containers start
4. start libvirt - autostart VMs start

Version 6.4 is this:

1. emhttpd initialized (state valid)
2. start docker - autostart containers start
3. start libvirt - autostart VMs start
4. nginx accepts http connections on ports 80,443 (or user-specified via 'go' script)

We could restore the pre-6.4 start order if we need to.  Probably that's the right thing to do right?

 

For use of port 443 - we could "disable" this by default, that is, have nginx only handle http requests.  In this case user would have to edit their 'go' file to enable https.  We were trying to avoid that, but maybe we could add webUI control for this.

 

 

When you start nginx before emhttp, it will make queries to a non-existing service, but at least it prevents port 443 from being taken by docker.

 

Perhaps another approach is a delayed start of the docker service?

 

What I meant was, we could change 6.4 start sequence to:

1. start emhttpd (state valid)
2. start nginx, accepts http connections on ports 80,443 (or user-specified via 'go' script)
3. start docker - autostart containers start
4. start libvirt - autostart VMs start

 

Edit: originally during 6.4 development we had nginx start first, but this results in problems when server reboots because javascript is still running in the browser waiting for server to come back up.

Yeah this sounds right

2 minutes ago, bonienl said:

Yeah this sounds right

 

What about disabling port 443 by default?  We would probably need a webUI page eventually to permit someone to turn on/off http/https.  We were planning something like this eventually anyway (post-6.4 release) to also let someone manage certificates.

I rather don't see this as option through the GUI, but more as something working transparantly for the user. I actually prefer an automatic redirection of http to https, which is quite common for web sites.

 

Just another thought: let docker start before nginx and check the availability of port 443 (or what has been set as https port), if free redirect to https if not stay on http for nginx.

 

Ps. There are free CA services to sign your certificate instead of the current self-signing, and get rid off the browser warning.

Edited June 6, 20179 yr by bonienl

17 minutes ago, bonienl said:

There are free CA services to sign your certificate instead of the current self-signing, and get rid off the browser warning.

 

The server would have to have a FQDN for this to work right?  For example consider a small office with an unRaid server named "tower" - they would need a certificate for "tower.my-small-company.com" right?  If this were a home behind a typical residential gateway, there is no high level domain right?  In this case they can set up their own local CA, but also I guess you can make the case that https is not needed.

Yes a FQDN is required. I have to stand corrected, because CAs are not allowed anymore to sign internal server names or private address space.

 

Here is some background information with possible solutions, but I doubt if these are free of charge.

10 minutes ago, bonienl said:

but I doubt if these are free of charge.

 

Yeah, I was thinking to set up your own local CA, eg:

https://robpol86.com/root_certificate_authority.html

I think to minimize disruption for the 6.3 to 6.4 transition it makes sense to change the startup order back to how it was in 6.3 AND disable listening on 443.. then have a GUI element for enabling https which would query docker to check 443 is in use before applying the ngix config change to listen on 443 again?

 

That way no user dockers are broken on upgrade and its up to them if they choose to have 443 used by the unraid GUI in the future.

45 minutes ago, billington.mark said:

I think to minimize disruption for the 6.3 to 6.4 transition it makes sense to change the startup order back to how it was in 6.3 AND disable listening on 443.. then have a GUI element for enabling https which would query docker to check 443 is in use before applying the ngix config change to listen on 443 again?

 

That way no user dockers are broken on upgrade and its up to them if they choose to have 443 used by the unraid GUI in the future.

 

I agree. If you can start nginx before dockers that would be best because it ensures dockers never prevent the gui from loading (assuming there is a good solution to the reboot problem that was mentioned)

 

And since there are drawbacks / configuration issues for any SSL configuration, it might as well be disabled by default.

 

But thank you very much for adding it as an option!

 

The local CA idea is interesting, but here is what I'm planning to do:

 

I have free DDNS for mydomain.com through dnsexit.com, and I just confirmed they allow me to point a FQDN (unraid.mydomain.com) to a local static ip. So I'm planning to have the LSIO Letsencrypt docker (running on its own IP address) add unraid.mydomain.com to my existing Let's Encrypt mydomain.com cert. Then I just need a way to configure unRAID to use the latest version of that cert whenever it is updated.

 

All of that is free except for the domain name registration (which is theoretically optional)

17 minutes ago, ljm42 said:

Then I just need a way to configure unRAID to use the latest version of that cert whenever it is updated

 

In the /etc/nginx/nginx.conf file it specifies:

    ssl_certificate          /etc/ssl/certs/unraid_cert.pem;
    ssl_certificate_key      /etc/ssl/certs/unraid_key.pem;

And in /etc/ssl/certs there is:

unraid_cert.pem -> /boot/config/ssl/certs/Tower_unraid_cert.pem*
unraid_key.pem -> /boot/config/ssl/certs/Tower_unraid_key.pem*

(symlinks to certificates stored on flash named after the server name)

 

Those are the files you would update.  Note that if you change the name of your server, those file names change as well.

3 hours ago, limetech said:

Those are the files you would update.

 

Good news / bad news...

 

The good news is that replacing the certs was easy and it works great. FYI, the name of the server (towervm in my case) does not have to be one of the names on the cert. You just need to make sure you are accessing the server through a FQDN that is in the cert (unraid.mydomain.com)

 

The bad news is that Let's Encrypt refuses to issue a cert when the dns to a subdomain points to an internal IP. That complicates things a bit.

31 minutes ago, ljm42 said:

The bad news is that Let's Encrypt refuses to issue a cert when the dns to a subdomain points to an internal IP.

 

6 hours ago, bonienl said:

CAs are not allowed anymore to sign internal server names or private address space.

 

1 hour ago, jonathanm said:

CAs are not allowed anymore to sign internal server names or private address space.

 

I took that to mean you couldn't make a cert for https://tower or https://192.168.10.1.  Didn't realize it meant that https://unraid.mydomain.com couldn't point to a private IP address at the time the cert was created.

Edited June 7, 20179 yr by ljm42