Hi!
Just upgraded from core 159 to 167, I had to re-add an option to SARG configuration and would like to rebuild the daily SARG reports.
So far I’ve used this command:
/usr/sbin/update-sarg-reports daily
Right now, this does not work any more. I get this error instead:
sarg: error while loading shared libraries: libgd.so.2: cannot open shared object file: No such file or directory
Question: is a manual update/rebuild of the reports still possible and if so, how?
Michael
Hi @hellfire
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.
EDIT:
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.
I found that apcupsd, which I use, also suffers from this problem if you look at the upsimage.cgi page. Just uninstalling and re-installing does not change the library link.
I also found that icinga cgi pages will have the same problem.
I am submitting a patch to get these three addons incremented to force an update with Core Update 168.
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 
Exactly those steps did solve this issue!
Many thanks for your prompt and comprehensive help!
Hi,
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)!
Thanks, and best regards,
Peter Müller
Hi Peter!
Of course you can ask 
.
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!
Michael
I’d be curious in your list - only if you want to share.
I generally don’t have update issues and all works A-OK for me. No changes need to be made.
Once in a long while I do crash something and I need to do a restore & rebuild. For that case, I do have a check list of changes. But that happens maybe once every two years…
Glad you asked 
Here is my list:
Check /etc/httpd/conf/httpd.conf if MIME types are still present that I’ve been added
AddType application/x-ns-proxy-autoconfig .dat
AddType application/x-ns-proxy-autoconfig .pac
Redirect permanent /proxy.pac /wpad.dat
Check /etc/sarg/sarg.conf if resolve_ip is still set to dns, most of time it is set to no after a core update
Check if some white listed sites in /etc/squidclamav.conf are still available, that I need to get through the proxy without any issues
whitelist \.clamav\.net
whitelist gsak\.net
whitelist clydeengland\.com
whitelist \.groundspeak\.com
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 ^^
Michael
Which ones disappear after each core update? (I am guessing not every item disappears…)
No, not everyone of course and not every update is the same. It depends which components have been replaced, removed among others things.
While updating to core 167, the mentioned Python lib disappeared for example.
SARG config is another one that is constantly missing as it did after updating to core 167.
I remember my custom crontab entries to be removed a while ago, the last update did not touch it though.
This one bite me also. I now run your fcron backup program every night!
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.
FYI
Apr 26, 2022: NUT 2.8.0 released Network UPS Tools
Unsure if I have the “chops” to fix the addon.
You would be more than welcomed if you decided to provide an update patch for this addon.
@jon has successfully had a go at this recently with submissions of nano and pcengines-apu-firmware
If you decide not to, just let me know and I will pick it up.