Locked out of server

[Boyturtle]

I turned off my unraid array this afternoon as Pihole wasn’t working properly and I had considered that it may have been conflicting with Privoxy somewhere down the line and just switching off both dockers didn’t seem to fix it.

When I switched off the array, I lost connectivity to the server and I have since been unable to connect via the browser. When I put in the local ip address of the browser, it resolves to https://$$tring.unraid.net but then can’t resolve any further, leaving me effectively locked out.

I am able to SSH into the server and have changed the ip address from *.*.*.170 to *.*.*.180, restarted the server and tried to access it via the browser again, hoping this time that it won’t resolve to the $$tring.unraid.net address, unfortunately, this did not work and it resolved to the same *.unraid.net.

I suspect the problem is probably caused by issues I had while trying to do Spaceinvader One's unRAID 6.4 Overview, How to upgrade, SSL, HTTPS and Disk Encryption video. Fortunately for me at this stage that I didn’t encrypt the drives!

I tried to force the resolution by adding the $$tring.unraid.net address to the /etc/hosts file, but that didn’t work either as it removed my changes after reboot.

I’m not sure if this is relevant, but, although I can ssh using root privileges, I am unable to get past the login screen when I plug a keyboard and monior into the server directly.

I’m a bit at my wits end at the minute and Mr Google has not been very helpful. Should I delete any of the certs in the /boot/config/ssl/certs folder? I’d appreciate any input.
 

[John_M]

Have you tried typing

https://IP.address.of.server

in your browser instead of

http://IP.address.of.server

as that will avoid the redirection and name resolution? The browser will complain about the certificate but if you accept the risk it should let you in, assuming you haven't messed about with the settings too much by editing them manually.

[Boyturtle]

13 hours ago, John_M said:

Have you tried typing

https://IP.address.of.server

in your browser instead of

http://IP.address.of.server

as that will avoid the redirection and name resolution? The browser will complain about the certificate but if you accept the risk it should let you in, assuming you haven't messed about with the settings too much by editing them manually.

I've tried both iterations and they both resolve  to the same address.

Very odd. I could not access the web interface from any of the household computers, laptops, ipads or Apple phones, but was able to do so from my android phone as it didn't resolve to the errant .unraid.net address, keeping it local instead for some reason. I have been able to start the array again and start all the VMs and dockers from within my humble android phone.

Initially, once started I still couldn't access the server management pages from any device other than my phone; but I was able to access pages with different ports and IP addresses that are served by unraid (Crashplan, Pihole, Plex) and was able to remote into the VMs to, using teamviewer. Fiddling about with the DNS settings seemed to allow me to view pages now. So I don't know if the issue is somehow DNS or even DHCP related?

For now, the problem is resolved, albeit in a roundabout and Heath Robinson fashion. I suspect that the problem will return if I stop the array again (so I've added the array autostart as a precaution). I'd like to avoid this in future, can anyone give me any pointers to what I should look at to resolve this?

[pwm]

46 minutes ago, Boyturtle said:

I've tried both iterations and they both resolve  to the same address.

 

Not sure what you mean with this. If you enter a name, then that name needs to be resolved to an IP number.

 

But if you enter an IP number, then no resolve needs to be done - there is no hostname or domain name involved when you have already specified an IP number.

[Boyturtle]

2 minutes ago, pwm said:

 

Not sure what you mean with this. If you enter a name, then that name needs to be resolved to an IP number.

 

But if you enter an IP number, then no resolve needs to be done - there is no hostname or domain name involved when you have already specified an IP number.

Local ip addresses  http://192.168.52.170 and https ://192.168.52.170 resolve to FQDN https://$$tring.unraid.net . Resolve in this instance may not be the correct term, but I'm not sure what else to call it

[pwm]

8 minutes ago, Boyturtle said:

Local ip addresses  http://192.168.52.170 and https ://192.168.52.170 resolve to FQDN https://$$tring.unraid.net . Resolve in this instance may not be the correct term, but I'm not sure what else to call it

In that case, it's the web server that accepts the IP-based connect and then does a redirect, i.e. sends back a new URL to the web browser.

 

But the web server shouldn't treat the Android client differently. "https://192.168.52.170/" should have given the same result for all clients.

[Boyturtle]

Hmm

2 hours ago, pwm said:

In that case, it's the web server that accepts the IP-based connect and then does a redirect, i.e. sends back a new URL to the web browser.

 

But the web server shouldn't treat the Android client differently. "https://192.168.52.170/" should have given the same result for all clients.

Hmm. I'm confused. In this instance, the redirect will happen at server end of 192.168.52.170, is that right? If so, how did the redirect happen because the array was down and non of the services would have been running? Does this mean that some services would still be running without the array being up (so, effectively baked into the boot usb and consequent RAM when loaded), or is it that the redirect is cached on the client machines?

[itimpi]

7 minutes ago, Boyturtle said:

Hmm

Hmm. I'm confused. In this instance, the redirect will happen at server end of 192.168.52.170, is that right? If so, how did the redirect happen because the array was down and non of the services would have been running? Does this mean that some services would still be running without the array being up (so, effectively baked into the boot usb and consequent RAM when loaded), or is it that the redirect is cached on the client machines?

UnRAID does not need the array to be started to have the network active, and the web server that supplies the unRAID GUI.  They are started as part of the unRAID booting process.

Edited August 17, 2018 by itimpi

[pwm]

1 minute ago, Boyturtle said:

Hmm. I'm confused. In this instance, the redirect will happen at server end of 192.168.52.170, is that right?

 

It's common to configure web servers so that if a user makes a http://xxx request, the server directly sends back a redirect to the web browser giving it a https://xxx request instead. An example of this is if you visit google by writing http://www.google.com/ then your web browser gets sent to the secure address instead.

 

But redirects means you first needs to get to the server. And if you get to the server with https://<ip>/ then you already are at the correct machine. But it is possible to configure a web server to make a redirect from https://<ip>/ to https://<name>/ - just that such a redirect should then affect all clients connecting using IP. The web server sees how you connects, because the client sends in not just the path of the URL to the server but also the server name. This is what allows one IP on a web hotel to serve many different web sites - the server sees the hostname "charlies-site" and knows that http://charlies-site/ is different from http://bennys-site/ even if the DNS translates the two addresses to the same IP.

[pwm]

1 minute ago, itimpi said:

UnRAID does not need the array to be started to have the network active, and the web server that supplies the unRAID GUI.

Exactly - it would be impossible to use the web pages to start/stop the array or administrate the machine if the web server isn't started directly when unRAID boots.

[Boyturtle]

18 hours ago, pwm said:

 

It's common to configure web servers so that if a user makes a http://xxx request, the server directly sends back a redirect to the web browser giving it a https://xxx request instead. An example of this is if you visit google by writing http://www.google.com/ then your web browser gets sent to the secure address instead.

 

But redirects means you first needs to get to the server. And if you get to the server with https://<ip>/ then you already are at the correct machine. But it is possible to configure a web server to make a redirect from https://<ip>/ to https://<name>/ - just that such a redirect should then affect all clients connecting using IP. The web server sees how you connects, because the client sends in not just the path of the URL to the server but also the server name. This is what allows one IP on a web hotel to serve many different web sites - the server sees the hostname "charlies-site" and knows that http://charlies-site/ is different from http://bennys-site/ even if the DNS translates the two addresses to the same IP.

Great. So, correct me if I've got the wrong end of the stick, with regard to my issue a couple of nights ago. I typed in https://ip/, the server (by default) redirected to https://name/ and because my router and DNS service were virtualised and not started at this point (because they are living on unraid), my query just went nowhere? So, if this is the case and it happens again, do I fire up my (as yet unconfigured, brand new) bare metal router and will this bypass the problem, or is there something else I should address?