Core Update 181 - WUI not accessible but apache is running

After upgrade to 181 I lost the GUI.
Tried to restart but still no GUI when goint to https:my.gateway.ip:444
Just get a ERR_TIMED_OUT
(And generated by Squid)

Hitting for instance http://my.gateway.ip I do get the IPfire “Error the requested URL could not be retrieved”

Assume this might be related? Newbie so appreaciate any clues to get the GUI back
The system returned: (111) Connection refused
The remote host or network may be down. Please try the request again.

So apparently something is running

Go to a shell ( using PuTTY for example ) and try
ps -e | grep httpd
This should show whether apache is running.
If not, try
grep httpd /var/log/messages
This should show errors for the start of the web server.

1 Like

There is some issues with that. SSH is not enabled (nor setup if thats needed)
Did hook up a screen and rebooted (as it was not possible to get anything on the screen without reboot)
It is starting up but almost impossible to input the commands as the screen is flooded with DROP_NEWNOTSYNC, DROP_CTINVALID and DROP_INPUT messages.

but managed to login and:
grep httpd /var/log/messages gives nothing.

ps -e | grep httpd gives the following 3 lines
2991 ? 00:00:00 httpd
2992 ? 00:00:00 httpd
2996 ? 00:00:00 httpd

Tried to enable ssh from command line but get a pubkey error when trying to log in.
Also tried the other consoled with Alt+Fxx but all flooded with the messages

Thanks, will enable the ssh for the future, but right now I feel kind of stuck and a newbie with Ipfire. (Believe I need some sort of key from IPfire but unsure how to grab that from command line.) See bottom output from ssh.

Believe from my previous that apache is running but I still dont have any gui
I do get ERR_TIMED_OUT when trying to access the webGUI, but connection refused when trying to hit the ipfire with any other url/port it gives connection refused so something is alive.

Is there any way I can stop the output flooding the screen to be able to loook around?

When accessing ssh

debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tortho/.ssh/id_rsa
debug3: no such identity: /home/tortho/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/tortho/.ssh/id_ecdsa
debug3: no such identity: /home/tortho/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/tortho/.ssh/id_ecdsa_sk
debug3: no such identity: /home/tortho/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/tortho/.ssh/id_ed25519
debug3: no such identity: /home/tortho/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/tortho/.ssh/id_ed25519_sk
debug3: no such identity: /home/tortho/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/tortho/.ssh/id_xmss
debug3: no such identity: /home/tortho/.ssh/id_xmss: No such file or directory
debug1: Trying private key: /home/tortho/.ssh/id_dsa
debug3: no such identity: /home/tortho/.ssh/id_dsa: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
root@ipfire: Permission denied (publickey).

Btw. running /etc/init.d/apache restart ends with an OK but still no gui.
Any other ways of removing/reinstalling apache, forcing another upgrade or running post upgrade scripts or other to see what did go wrong?

This indicates that your apache is actually running so you have a different problem in terms of the cause than the previous thread so I moved all the posts to a new thread.

You can confirm that apache is running bt running the command
/etc/rc.d/init.d/apache status

You will get something like
httpd is running with Process ID(s) 16117 4203 4191.

The pid numbers you have will be different. This tells you that apache is running.

When you have tried to access the WUI have you just tried with the Fully Qualified Domain Name or have you also tried with the IP address? That would make sure that there is no problem related to the resolving of the FQDN.

In your browser run
where is replaced with the IP Address you have defined for your IPFire green nic.

Can you also confirm that the WUI access worked before you tried the upgrade to CU181?

Thanks Adolf,

Confirm httpd is running and got the same output with different pid numbers.

Have tried both to access on https://ipfire:444 and https://192.xxxx:444 Both off which reverts after some time with ERR_TIMED_OUT

Pinging the IP or ipfire reverts asap.
Trying for instance with IP adr or https://ipfire reverts asap with ERR_CONNECTION_REFUSED
Trying the same with only http reverts asap with connection refused with the IPfire logo and red background.

GUI has worked perfectly since my original install without any issues and survived several reboots as well. (No issues at all with anything prior to this update)

For the record, everything seems to work fine except the GUI.
DHCP server serves ip’s and network works fine

Let’s try some simple checks to make sure everything stayed set up as you originally defined it.

If you run
ip address show dev green0
you will get the information on the ip address that is defined for your green0 interface.

Can you confirm that this shows the same IP address that you are trying to use for the WUI access.

If yes then try running from your pc with the browser the following command
ping -c4
with your green0 ip address used.

Do you get 4 sets of ping times with 0% packet loss similar to this

ping -c4
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=3.42 ms
64 bytes from icmp_seq=2 ttl=64 time=3.29 ms
64 bytes from icmp_seq=3 ttl=64 time=3.66 ms
64 bytes from icmp_seq=4 ttl=64 time=2.82 ms

— ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.818/3.297/3.660/0.307 ms

The (111) connection refused can be due to proxy issues.

Do you normally have the proxy running on your ipfire.

If yes, then it might be that during the update the proxy got stopped. This is a problem that some people experience from time to time and a bug has been raised on it but none of the devs have yet been able to reproduce the effect on their machines, which makes it difficult to fault find.

If you normally have the IPFire Web Proxy running then change your browser settings to use the system proxy. Then see if your WUI access works again or not.

If it does then check the status of the proxy on the WUI menu Status - Services page.

Here you mention the urls as being https

However in the picture of the error it mentions http at the top of the window and in the first line of the error message starting “The following error was encountered…”

Can you confirm that you are using https in the url.

green interface set correctly and samer ip as I try to connect to.

Ping works fine:
ping ipfire
PING ipfire.localdomain (192.xxxxx) 56(84) bytes of data.
64 bytes from ipfire.localdomain (192.xxxxx): icmp_seq=1 ttl=64 time=0.560 ms
64 bytes from ipfire.localdomain (192.xxxxx): icmp_seq=2 ttl=64 time=0.687 ms
64 bytes from ipfire.localdomain (192.xxxxx): icmp_seq=3 ttl=64 time=0.580 ms
64 bytes from ipfire.localdomain (192.xxxxx): icmp_seq=4 ttl=64 time=0.499 ms
64 bytes from ipfire.localdomain (192.xxxxx): icmp_seq=5 ttl=64 time=0.730 ms
— ipfire.localdomain ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.499/0.611/0.730/0.084 ms

1 Like

On the pictures you will see one with https and one with http (was meant to illustrate that I get different errors and that http replies instantly with connection refused whilst the gui on https takes a while before it comes back with timed out)

Okay, then I understand now.

http will always fail very fast as apache on IPFire is set up to only work with https and so will fail with http.

What about the question on the web proxy. This may cause timeouts if it is not running but the browser is set up to use a proxy.

A bit more searching says that if the proxy was the problem then you would get a The Proxy Server is Refusing Connections message so it looks not to be related to the web proxy.

Transparent proxy is set up from the begining.
Tried to add proxy settings in debian now but it fails with the same error.
As I do not have the WUI I cannot check the status in the service page. Anything I can do from the console? (and is there a way to stop the flooding of the console with the DROP_INPUT messages as it is really hard to see anything there :-))

did check /etc/init.d/squid status and got the following
squid is running with Process ID(s) 2545 2542
/usr/lib/squid/unlinkd is not running

Unfortunately not. There is a bug report raised on this since July this year when someone found the effect after upgrading to CU 176 and one other person flagged up the same problem.

Unfortunately it has not been able to be reproduced by the devs so it is difficult to figure out what is causing it and stop it.

I have not experienced that on any of my systems (physical or virtual machines) at any time.

They are welcome to get full access to my system to look into it :slight_smile:

I get the same responses on my production system but the WUI is fully accessible to me so not related to your problem.

Running out of ideas. I will come back if I think of anything further to test.

You may need to take a backup, save it off of the IPFire machine, do a fresh installation of CU181 and then restore from your backup.

You can run the backup from the console.

and then save the backup file to a usb stick.

Thanks a lot for your effort so far Adolf, will let it hang a little longer to see if any other clues pops up before I go down the backup road :slight_smile:

1 Like