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.
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.
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.
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 https://192.168.60.1:444
where 192.168.60.1 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?
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 192.xxx.xxx.xxx
with your green0 ip address used.
Do you get 4 sets of ping times with 0% packet loss similar to this
ping -c4 192.168.xxx.xxx
PING 192.168.xxx.xxx (192.168.xxx.xxx) 56(84) bytes of data.
64 bytes from 192.168.xxx.xxx: icmp_seq=1 ttl=64 time=3.42 ms
64 bytes from 192.168.xxx.xxx: icmp_seq=2 ttl=64 time=3.29 ms
64 bytes from 192.168.xxx.xxx: icmp_seq=3 ttl=64 time=3.66 ms
64 bytes from 192.168.xxx.xxx: icmp_seq=4 ttl=64 time=2.82 ms
— 192.168.xxx.xxx 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.
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.
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)
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 :-))
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.
