Trouble when upgrading from core 157 to core 158

Today I did (try) an upgrade from core 157 to core 158.
The upgrade partially worked. I still have internet connection :slightly_smiling_face:

However, I cannot log into the WebUI https://<ipfire_ip>:444 at the green or blue interface anymore.
In Firefox I get the error message:

Beim Verbinden mit <ipfire_ip>:444 trat ein Fehler auf. PR_CONNECT_RESET_ERROR

When I reboot with a connected null modem cable, I get an error that avahi failed.

> 
> Loading Sensor Modules:                                                [  OK  ]
> Starting Collection daemon...                                          [  OK  ]
> Starting DHCP Server...                                                [  OK  ]
> Starting Unbound DHCP Leases Bridge...                                 [  OK  ]
> Starting Apache daemon...                                              [  OK  ]
> Starting fcron...                                                      [  OK  ]
> Starting Guardian...                                                   [  OK  ]
> Starting nmbd...                                                       [  OK  ]
> Starting smbd...                                                       [  OK  ]
> Starting winbind...                                                    [  OK  ]
> Starting avahi...                                                      [ FAIL ]
> 
> IPFire v2.25 - www.ipfire.org
> ===============================

After login as root, I have no connection to internet from the root console.

ping www.google.de

fails: ping: www.google.de: Name or service not known

Starting avahi service from CLI results in

/etc/init.d/avahi start
Starting avahi… [ FAIL ]

/var/log/messages shows

Jul 20 10:52:54 IPFIRE1 avahi-daemon[17523]: Found user ‘avahi’ (UID 999) and group ‘avahi’ (GID 999).
Jul 20 10:52:54 IPFIRE1 avahi-daemon[17523]: Successfully dropped root privileges.
Jul 20 10:52:54 IPFIRE1 avahi-daemon[17523]: avahi-daemon 0.8 starting up.
Jul 20 10:52:54 IPFIRE1 avahi-daemon[17523]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
Jul 20 10:52:54 IPFIRE1 avahi-daemon[17523]: dbus_bus_get_private(): Failed to connect to socket /var/run/dbus/system_bus_socket: Permission denied
Jul 20 10:52:54 IPFIRE1 avahi-daemon[17523]: WARNING: Failed to contact D-Bus daemon.
Jul 20 10:52:54 IPFIRE1 avahi-daemon[17523]: avahi-daemon 0.8 exiting.

ls -la /var/run/dbus/system_bus_socket:

srwxrwxrwx 1 root root 0 Jul 20 10:42 /var/run/dbus/system_bus_socket

Can you help, please?

Thanks in advance.

Addendum: /var/log/messages also shows the message when trying to restart avahi:

WARNING: No NSS support for mDNS detected, consider installing nss-mdns!

However, nss-mdns cannot be installed by pakfire:

[root@IPFIRE1 ~]# pakfire install nss-mdns
packages_list.db 100.00% |=============================>| 4.34 KB

PAKFIRE WARN: The pak “nss-mdns” is not known. Please try running “pakfire update”.
PAKFIRE ERROR: No packages to install. Exiting…

Interestingly, a pakfire list shows that the addon mdns-repeater is installed:

[root@IPFIRE1 ~]# pakfire list | grep mdns
Name: mdns-repeater

However, I cannot remove it with pakfire:

[root@IPFIRE1 ~]# pakfire remove mdns-repeater
PAKFIRE WARN: mdns-repeater is not installed
PAKFIRE ERROR: No packages to remove. Exiting…

Hi @ewald

This is not showing the installed addons. This gives a list of the available addons. You can not remove it because it has not been installed.

This is just a warning. NSS suport is not needed for the use of avahi in IPFire. It is a dependency for cups.
I just installed cups and avahi was also installed but it would not start as you have found. That needs to be investigated because it might affect the cups operation. I will raise a bug report for this item.
Edit: bug raised - 12663 – Core Update 158 - avahi fails to start

The failure of avahi to start should not cause you a problem to access your webgui. I am able to access my webgui with avahi not installed or with it installed and failing to run.
There must be some other issue with your system.

What messages are in

/var/log/httpd/error_log

Hi,

Thanks for your initial answers.

The log file /var/log/httpd/error_log is flooded with these messages:

[Tue Jul 20 14:41:30.263750 2021] [core:notice] [pid 11779:tid 128406448878592] AH00052: child pid 30115 exit signal Abort (6)
libgcc_s.so.1 must be installed for pthread_cancel to work
[Tue Jul 20 14:41:32.267152 2021] [core:notice] [pid 11779:tid 128406448878592] AH00052: child pid 30136 exit signal Abort (6)
libgcc_s.so.1 must be installed for pthread_cancel to work
[Tue Jul 20 14:41:34.270512 2021] [core:notice] [pid 11779:tid 128406448878592] AH00052: child pid 30156 exit signal Abort (6)
libgcc_s.so.1 must be installed for pthread_cancel to work

Immediately after the upgrade I can see this error message:

[Tue Jul 20 09:18:48.662327 2021] [ssl:warn] [pid 24065:tid 125746173797376] AH0
1909: IPFIRE.IPFIRE1:444:0 server certificate does NOT include an ID which match
es the server name
[Tue Jul 20 09:18:48.680495 2021] [ssl:warn] [pid 24066:tid 125746173797376] AH0
1909: IPFIRE.IPFIRE1:444:0 server certificate does NOT include an ID which match
es the server name

Maybe this is related to a new generation of my OpenVPN certificates this week.
I may have deleted the X509 certificate accidentally. I remember that I pushed such a button on the openVPN set-up page.

Don’t worry about this. This is a warning because the certificate is a self signed one. That is why you will have had to accept it in the past.

This message is worrying. It suggests that either that library file is not present or it has the wrong permissions.

The file should be in

/usr/lib/

Have a look in that directory and see if that lib file is present and if it is what its permissions and owners are.
On my system the file is present and has the following permissions

-rw-r--r--   1 root root  589K Nov 14  2020 libgcc_s.so.1
1 Like

libgcc_s.so.1 is located at /usr/lib with the same permission as yours:

-rw-r–r-- 1 root root 603008 Dec 18 2020 libgcc_s.so.1

/usr/lib has these permissions:

drwx------ 50 root root 36864 May 4 13:20 lib

Hmmm. I don’t understand that then. As your httpd/error_log is full of those messages about libgcc_s and mine is not.

Hopefully someone else can help further. I don’t have any further thoughts about this at the present time but will come back if I think of anything.

I found a similar topic here:
https://community.ipfire.org/t/lost-access-to-wui-on-green-since-156-update/5378/7

Is the change of permissions described there the correct solution from security point of view?

Luca Polojake64

1 Jun

Just hit this bug today.

I solved it, together with other related bugs (HTTP 5xx errors, OpenVPN no longer working, etc.), simply by correcting several directory permissions, e.g. /usr/lib, /usr/sbin, /usr/lib/perl/* and some others I forgot to write down, silly me.

They all were with 700 permissions instead of 755, which prevented Apache, OpenVPN, Perl CGI scripts, etc., which run under “nobody” uid, to access needed files and libraries.

Hope this helps others to avoid reinstallation.

Luca.

Could you manually change this back to 755?

Done

chmod 755 lib

Can still not access the WebUI despite apache has been restarted.

How about /usr/bin? Do I also need to change the permissions to 755?

After changing the permissions of /usr and /usr/bin to 755 I get

[Tue Jul 20 15:40:22.693657 2021] [cgid:error] [pid 32612:tid 128405781583424] (13)Permission denied: [client 192.168.1.4:59456] AH01257: unable to connect to cgi daemon after multiple tries: /srv/web/ipfire/html/index.cgi

My /usr/bin has 755 so if yours has 700 then yes change that one also.

What are the permissions of /var?

I just inspected /usr/lib.
Some lib* files have only the -rw-r–r-- permission, but most of them have also a link pointing at them with the ‘right’ permissions. libgcc_s.so.1 lacks this.
Is this a possible reason for the error messages?

drwx------ 15 root root 4096 Jul 15 21:52 var

/var/ipfire permission look also strange:

drwx------ 52 root root 4096 Jul 15 21:52 ipfire

Yes, /var and /var/ipfire also look incorrect. Please change them to 755, too.

OK, after changing the permissions of /var and /var/ipfire to 755 I can log into the WebUI again :slight_smile:

Thanks for your great support!

However, what worries me is why were the permissions set all wrong? Any idea?

The necessary permission changes were as follows:

1003 chmod 755 lib (/usr/lib)
1004 chmod 755 bin (/usr/bin)
1013 chmod 755 /usr
1032 chmod 755 /var
1038 chmod 755 /var/ipfire

1 Like

I suspect a big in tar which we might have fixed with Core Update 158, however the update was installed with Pakfire from the previous version, so we will only know after the next update. Could you maybe upload /var/log/pakfire/upgrade-core-update-158.log? Maybe that will tell us something.

1 Like

Here we go
update-core-upgrade-158.zip (9.0 KB)

For me as a non expert, there is nothing suspicious inside …

Unfortunately, I found another issue that is now failing after the upgrade to core 158: openvpn

I am sure that the openvpn connection worked with core 157 since I updated the certificates newly a couple of days ago. Now I am getting the error message on my mobile phone ‘Authentication failed User authentication failed’.

Which incorrect permissions could cause this failure?

In /var/log/messages I can see this error message:

OPTIONS IMPORT: reading client specific options from: /var/ipfire/ovpn/ccd/(deleted here)
WARNING: Failed running command (–client-connect): external program exited with error status: 1

The openvpn issue could be fixed by manually setting the wrong permissions of

/usr/lib/samba
/usr/lib/python3.8
/usr/lib/cups

to 755. All three had the wrong permission 700.

Another positive effect of these corrections is that avahi is now starting properly :slight_smile: This was one of my initial observations (see above).

1 Like