Buttons in web interface stop working

1

Hello,

core 197 - buttons in the web interface do not work properly. No idea when this happened, it worked in the past perfectly well.

e.g.

→ dhcp-server → add device from dynamic IP to fixed IP and hit the button on the right (German “hinzufügen”, English should be “add”) → the page goes white/ blank and nothing happens, it stays blank.

Checking the entries in /var/ipfire → nothing happened as well.

Same story to handle devices under firewall ie. “access on blue” → however, the button for editing an entry works (pencil sign) but not the one to “add” the device. The button to add the device for editing works (pencil + sign).

No error messages are shown. No idea where to look for possible log entries.

Tried various browsers although it worked in the past: chromium + firefox (both under debian trixie), chrome (ipad) → same behavior for every browser.

Added entries manually and restarted services, but that should not be.

???

Thanks and best

2

That is weird. I just tried it with my CU197 production system and one of my development vm systems and both worked as would be expected without any issues.

If there is some error in the cgi code then usually there is also a message shown on the screen that there has been an error.
It would be worth looking in

/var/log/httpd/error_log

Go to the end of the file and look for log lines after a line containing dhcp.cgi for the dhcp issue or wireless.cgi for the Blue Access issue.

Nothing was modified in the wireless.cgi or dhcp.cgi code for CU197 and not for a long time before that also.

1 Like
3

Thanks for the hint with the log file./var/log/httpd/error_log

Unable to open fixed leases file. at /srv/web/ipfire/cgi-bin/dhcp.cgi line 416.Unable to open fixed leases file. at /srv/web/ipfire/cgi-bin/dhcp.cgi line 416.Unable to open fixed leases file. at /srv/web/ipfire/cgi-bin/dhcp.cgi line 416.Unable to open fixed lease file. at /srv/web/ipfire/cgi-bin/dhcp.cgi line 1248.Unable to write file /var/ipfire/dhcp/settings at /var/ipfire/general-functions.pl line 351.Unable to write file /var/ipfire/dhcp/settings at /var/ipfire/general-functions.pl line 351.Unable to write file /var/ipfire/dhcp/settings at /var/ipfire/general-functions.pl line 351.Unable to open config file. at /srv/web/ipfire/cgi-bin/wireless.cgi line 122.Unable to open config file. at /srv/web/ipfire/cgi-bin/wireless.cgi line 122.Unable to open fixed lease file. at /srv/web/ipfire/cgi-bin/dhcp.cgi line 464.

Thus, looks like a permission problem although never touched any permissions (?):

#ls -la /var/ipfire/dhcp/settings
-rw-r--r-- 1 root root 948 May 26 09:57 /var/ipfire/dhcp/settings

and

#ls -la /var/ipfire/dhcp
total 36
drwxr-xr-x 2 nobody nobody 4096 Sep 21 15:33 .
drwxr-xr-x 51 root root 4096 Sep 17 03:58 ..
-rw-r--r-- 1 nobody nobody 0 Sep 6 2012 advoptions
-rw-r--r-- 1 nobody nobody 2504 Apr 26 2022 advoptions-list
-rw-r--r-- 1 root root 8324 Sep 21 15:26 dhcpd.conf
-rw-r--r-- 1 nobody nobody 0 Sep 6 2012 dhcpd.conf.local
-rw-r--r-- 1 nobody nobody 0 Jul 25 2024 enable_blue
-rw-r--r-- 1 nobody nobody 0 Jul 25 2024 enable_green
-rw-r--r-- 1 root root 4325 Sep 21 15:33 fixleases
-rw-r--r-- 1 root root 948 May 26 09:57 settings

and

# ls -la /var/ipfire/wireless/
total 12
drwxr-xr-x 2 nobody nobody 4096 Sep 21 15:37 .
drwxr-xr-x 51 root root 4096 Sep 17 03:58 ..
-rw-r–r-- 1 root root 1781 Sep 21 15:37 config
-rw-r–r-- 1 nobody nobody 0 Sep 6 2012 settings

So how should it be?

Thanks!

4

That looks like some sort of corruption or problem happened during the update because there are incorrect ownerships there.

The dhcp settings file should be nobody:nobody instead of root:root

Everything in /var/ipfire/dhcp/ should be nobody:nobody

Again with /var/ipfire/wireless/ everything should be nobody:nobody.

Because those files have become root:root then when the code accesses the files as nobody then write permission is not allowed.

I don’t know how or why that would have happened during the update for you.

I did 6 IPFire full release updates from CU196 to CU197 and none of them showed this problem and during testing I probably did more than 25 update evaluations for the openvpn changes and none of them showed that problem.

You can certainly change those settings but the only question mark I would have is whether there are other files with the wrong ownerships in them.

What you could do is restore from a backup as that also stores the ownerships for the files.

As part of the update IPFire first creates a backup, which you will find in the backup list in the backup WUI page. You could then download that backup file and examine the contents with an archive viewer. The file extension is .ipf but is is basically a tar file so can easily be viewed by any tar archive viewer program.
Then you could check the ownership values of those files in the backup. If those are all nobody:nobody then the change occurred as part oof the update process. If the backup has some files with root:root then some hiccup occurred before the update was started.

2 Likes
5

Thanks, will do that. So just ensure everything is owned by the httpd user:group nobody:nobody (checked with ‘ps aux’ to confirm that assumption).

Good to know that the backup file is just a tarball, will untar one and see how it looks. No big deal to change that, now all this makes sense.

How this happened → just did so many updates during the last 10 years but did not do much to devices during the last year so it came up only now, but may happened much earlier unnoticed.

Anyway, thanks for your help, very appreciated!

1 Like