Last September the gd program was updated and a new library was installed, libgd.so.3 and libgd.so.3.0.11
Unfortunately the old library file stayed in place and the old programs using the libgd library were not shipped to force them to use the new library. As the old library was still present then those programs continued to work with the old library. In Core Update 167 there were several old files removed as housekeeping and the libgd.so.2 libs were included in this. During the testing phase this was seen to have an effect on the Net-Traffic page where no images were to be seen. Therefore vnstat was added to the CU167 updater list to force it to change to the libgd.so.3 library.
It looks like sarg was another program linked to the libgd.so.2 library, so the removal in the updating caused it to stop working.
I will try and see if there is a command to get the sarg program to link to the new library. If this can’t be done then the only option would be to install CU166.
I will try and get sarg added to the CU168 updater list so it will be done in that update.
I will also try and see if I can find anything else that might still be trying to use the libgd.so.2 library.
I am not sure but as sarg is an addon then if you uninstall it and then re-install it, the library link may be connected to the new library.
I just installed sarg on my system and it is linked to the new library. So it looks like it is worth a try, although as you already had it installed I don’t know if it will keep the old library link or not.
Yes, uninstalling and installing SARG again, did not do the correction of the links, Just did that and still seeing the libgd.so.2 error.
Executing SARG without any parameters shows the same error. Right now the daily reports are missing after the uninstall/installing procedure.
FWIW, any manually generated report won’t finish and does not create any output file.
I think that the fact that it stays with the old library is because of the addon cache. I will have an experiment later on and see if i can solve it for my apcupsd situstion in which case i will let you kniw how i did it so you can try it with your sarg addon.
I have successfully got the updated version of apcupsd with the new libgd.so.3 link installed.
What I did was uninstall apcupsd first.
Then I renamed the file in the cache from apcupsd-3.14.14-7.ipfire to apcupsd-3.14.14-7.old
This has to be done after uninstalling. If you do it before then uninstalling will place the same version in the cache so that you don’t have to download if it is the same version that you are installing. In you case it will be the sarg cache file you will need to rename. Choose the most recent version of it as there might be multiple copies.
Then after renaming the cache file install sarg again and as there is no cache version of the file a new copy will be downloaded and then installed. It should then work.
Certainly my apcupsd upsimage.cgi page is now showing all the images and the linked lib file is the correct libgd.so.3
After successfully getting everything installed again you will be able to delete the .old version as a correct version will now be in the cache.
Ok, perfect! So, now what will I’ve to do for my SARG installation?
Don’t want to mess up my IPfire installation and rename anything that is still in use, you know ^^
I understand that I’ve first to uninstall SARG again. Now next step is to rename a certain file. Where will I find this one? Afterward reinstall SARG and I’m good to go?
Btw, I do not use, nor do I have apcupsd installed right now.
My apologies, I thought that I had listed the location of the files but I didn’t. Sorry.
I talked about apcupsd because I have that installed and it also suffered from the same issue with libgd.so.2
So i was able to test out the approach with my apcupsd installation.
Look in /var/cache/pakfire/ and you should find a file called sarg-2.4.0-5.ipfire
First uninstall sarg
Second rename sarg-2.4.0-5.ipfire to some other name. The easisest is to change the suffix.
Third install sarg again.
You should now find that a new sarg-2.4.0-5.ipfire is in /var/cache/pakfire because IPFire will have downloaded it from the IPFire addon server rather than taking it from the cache as it was no longer there.
You should then find that sarg now works again as it should now be linked to libgd.so.3
may I ask why you stayed on Core Update 159 for so long?
According to Fireinfo, 5,5 % of all IPFire installations currently still run on this update, so I wonder if Core Update 160 and beyond introduce any regressions that force people to stay on C159. Also, I would really like to have the general situation improved - currently, two third of all installations are more than two Core Updates behind (and I cannot recall any time where this was better)!
I’m constantly reading almost any forum posts, especially when getting a notification of a new (beta) release of IPfire. However, I always hestitate to instantly update my IPFire because soon after a release gets final, some bug posts hold me back from updating. Although those bugs might not affect me at all, but one never knows.
I’m running IPFire in a private environment, so a shutdown is not that critical. Annoyingly is however, when IPFire does not restart again and my house members will start complaining about a broken internet connection. I did not see any serious issues the last updates, though.
The last months this year and last year, I’ve frequently been in home office, so have my children for home schooling. Therefore we needed a stable internet connection and you know: never change a running system in this case.
Work has changed now and I took the chance of upgrading. This went smooth, nevertheless, with any uograde I’ve to do some housekeeping, check some custom settings and re-add some settings again that any update removes from my installation.
E.g. With last update had some troubles with a library from SARG addon, that has been fixed yesterday. I’m running a Python script to collect data from pmacct that gets saved into a remote database, the library INFLUXDB_CLIENT was removed by the installer and I had to reinstall it. And some more things to do which cannot be solved by using and user config settings, simply there are none. I already have a checklist in place for upgrading.
So, almost all steps from this list has to be performed for each update again and again. This is one reason why I skip some updates. The other reason, as told, above is waiting for positive feedback once an update was released from the forum.
I really appreciate the work that is done by the staff! Good job and great support!
Check USV configuration (nut in this case) if it still attached to the IPFire hardware and some NAS can still reach the USV server
Exclude some IP ranges in /var/ipfire/proxy/advanced/acls/include.acl
# Exclude Sonos from Caching
# Because of interrupts when max object size is reached
acl sonos src 192.168.7.0/24
no_cache deny sonos
Check /etc/snmpd.conf for SNMP configuration that is being monitored by Telegraf fro ma emote NAS
Check if client library INFLUXDB_CLIENT for a Python script is still available on IPFire and reinstall it if necessary. Some times this lib gets removed
Check crontab if my user scripts especially are still in place, those that monitor IPFire hardware, traffic and much more and move the data into a InfluxDB for some Grafana dashboards. crontab is not safe from any update, as some others already noticed…
Check if services are still running: haproxy, nut, pmacct, clamav, guardian, netsnmpd
Quite some steps to do
Before doing an update I backup all data using IPFire’s built-in tools.
Additionally the complete installation gets backed up with rsync from a remote NAS any day. This backup includes a bunch of Python scripts for monitoring, as mentioned above, some scripts for renewal of about six Let’s encrypt certs that are used by HAProxy and others things I do not remember ^^
sarg provides a predefined system so the default IPFire sarg.conf has this set to “resolve_ip no” so it is very likely it will be restored to this at an update.
The config of nut should stay as you set it. There is a backup of nut which backsup the /etc/nut/ directory which includes the configuration. If your nut configuration is being lost at an IPFire update then this is a bug.
If include.acl is being changed during a core update then I would consider this a bug. include.acl is specifically there to allow user configurations that are kept over core updates.
netsnmpd has a backup include file defined which backsup the snmpd.conf file. An update of netsnmpd should always maintain your copy of snmpd.conf and a Core Update should leave it alone. Last update of this addon was in June 2021.
If the snmpd.conf is getting lost or overwritten in a core update then this would be considered to be a bug.
This library is not a standard IPFire library so any time that there is a python update then the whole python directory will be deleted and replaced so yes you will lose that file.
This will happen if fcron is updated. I have overcome this by creating an fcron user and creating a fcontab for that user and adding that fcrontab to my include.user backup file. I have four fcron entries that don’t fit into any of the predefined fcron folders such as daily, weekly etc. It is a bit of work to get things set up but once in place it has run very smoothly for me.
You should be able to add those additional files/directories into the include.user file to have them backed up by the IPFire backup system.