I installed IPFire 2.29 Core Update 191, and enabled the proxy URL filter. At first the block categories looked more or less like those shown in the URL filter guide (https://www.ipfire.org/docs/configuration/network/proxy/url-filter). Then I followed the instructions under section "URL filter maintenance" to update them from the official University of Toulouse source, and I ended up with a merged mix of old/obsolete categories which do not exist anymore in the source (in particular: `ads`, `aggressive`, `drugs`, `mail`, `porn`, `proxy`, `violence`) and new categories (see: https://github.com/olbat/ut1-blacklists). This means that now for instance I have both the old out-of-date `mail` and the new `webmail` blacklists mixed up together. By logging in to the console, I confirmed that under `/var/ipfire/urlfilter/blacklists/` all current blacklist folders are updated, while all obsolete blacklist folders remained at their original state. To avoid this, upon successful blacklists update, all the blacklists which are not present in the source repository (apart from `custom`) should be deleted. If useful to anyone (although I do not see the reason) a flag `Keep obsolete blacklists` could be added, unset by default.
I would like to add some thoughts to my previous post. Maybe some users would like to keep blacklists from more than one source. To make this possible, URLFilter would need to be updated to support up to X sources (for instance X = 3). The WebGUI should then have 3 configuration fields available, each one supporting a source URL and an automatic update schedule. Then within `/var/ipfire/urlfilter/blacklists/` the following folders should be created: custom source1 source2 source3 Every time a source is updated, the relative folder should be synced with the upstream repository, deleting obsolete blacklists. This would be the most flexible and practical solution.
As this bug is related to IPFire-2.x then the component should always be --- as per the IPFire bug reporting documentation.
*** Bug 13944 has been marked as a duplicate of this bug. ***
At this point in time, we are not looking to support more than one provider at the same time. This would be a lot of work to implement and have too little benefit. We just need to cleanup everything in the directory except the custom directory. That can be implemented with a simple find command.
I agree, especially now that DBL is coming. So my second post should be neglected.
https://lists.ipfire.org/development/20260222190753.10632-1-stefan.schantl@ipfire.org/T/#t
Has been merged into CU200 Testing
https://www.ipfire.org/blog/ipfire-2-29-core-update-200-released
This seems so be working only for unselected lists. In other words, only disabled lists are deleted when the download source is changed, while the enabled lists are retained. Not sure if this was intended or not.
What is making you come to this conclusion?
I just tested out on my CU200 vm system that had the University of Toulouse list in it. I selected the gambling and porn categories and saved and restarted the URL Filter. I checked the domains file in the gambling, porn and dating sections (two selected and one unselected categories). All three files were the ones provided by Univ of Toulouse. I then changed to IPFire DBL. After the update was completed I refreshed the URL Filter WUI page and I had just the IPFire DBL categories, with the porn and gambling categories still selected. I then checked the contents of the domains file in the same three category directories. All three were the IPFire DBL file contents. I then changed back to Univ of Toulouse and after download completed and WUI page refreshed the domains files in the three categories were back to the ones from Univ of Toulouse. Then back to IPFire DBL again and the three domains files were again the ones from IPFire. So it all seems to be working correctly for me with no old versions left hanging around and I was able to go back and forwards between the two sources several times.
I made some further tests, actually I confirm that lists are deleted even if selected... However when selecting the University of Toulouse list, I see lists which are not part of the UT1 blacklists, such as "ads" (UT1 contains "pubblicite"), "aggressive" (UT1 contains "aggressif"), "drugs" (UT1 contains "drogue"), etc. This behavior misled me. Why is this happening? Sorry I would have liked to check the code myself, but I have very little spare time right now... and I'm more used to navigate within projects on GitHub / GitLab...
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=14fcc77abb2367deedaba96f0227c5ae12d15741 Please let me know if this fixes the problem for you.
Unfortunately this does not work for me, however I'm not sure if I edited the correct file. The only file named `autoupdate.pl` that I found on my system is `/var/ipfire/urlfilter/bin/autoupdate.pl`, so I edited that one and commented the line `next unless (-d "$abs_path");`. Then I was unable to update using the "Univ. Toulouse" source (I also tried to reboot), as I was getting an empty list (while I could update using the "IPFire DBL" source). Then I reverted back, rebooted again, but still I cannot update using the "Univ. Toulouse" source. Honestly I'm not sure what's happening... Then I set the "IPFire DBL" source and I updated with it successfully. Maybe my issue is related to the "Univ. Toulouse" source?
I just tested out Core-Update 201 Development Build: master/d3b06186 which has the fix in it. I had the IPFire DBL selected and in place. I then changed the source from IPFire DBL to Toulouse University. All the IPFire DBL entries were removed and the University of Toulouse entries added, including a number of soft links. I then changed the source back to IPFire DBL and updated and all the University of Toulouse entries, including all the soft links, were removed. So for me the fix is confirmed. @lucatrv please try out the latest CU201 Testing version of d3b06186.
https://www.ipfire.org/blog/ipfire-2-29-core-update-201-is-available-for-testing
I updated to the latest CU201 Testing version, and changed from "IPFire DBL" to "Univ. Toulouse". This time the blacklists update was successful, however I still see "ads", "aggressive", "drugs", etc which should not be part of UT1. In other words I'm now back to my message of 2026-03-26... @Adolf are you sure that you do not see those lists after updating?
Created attachment 1703 [details] Screenshot of UT1 tarball showing symlinks Then you are talking about something different. I also see those symlinks but they do come in with the UT1 blocklist in the package named all.tar.gz which has all the blacklists. University of Toulouse have created symlinks with English names to some of the lists that have a French name such as drugs => drogues aggressive => agressif ads => publicite etc All of these are symlinks and both names point to the same blocklist. This is not a bug with IPFire and the attached screenshot shows the symlink lines in the all.tar.gz UT1 tarball. They come as part of the UT1 blocklist tarball. Those symlinks were the things that were mentioned as not being removed after changing from UT1 to IPFire DBL. The latest fix ensures that those symlinks are also removed when changing from one list to another.
As long as you confirm that after changing from the UT1 list to the IPFire DBL list that the symlinks are not present in the blacklists directory then that last fix is also confirmed for you and you should change the Status of the bug to Verified.
Oh my bad... now everything is clear. I confirm that this issue was fixed with CU201 Testing so I'm marking this bug as Verified. Thanks!
https://www.ipfire.org/blog/ipfire-2-29-core-update-201-released-with-dns-firewall