public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: p27m <p27m@orange.fr>
Cc: development@lists.ipfire.org
Subject: Re: [PATCH] urlfilter: Remove bundled Toulouse blacklist
Date: Tue, 29 Sep 2026 16:10:45 +0100	[thread overview]
Message-ID: <4FD17803-1E9B-41C4-A51B-CCE5F3BC92D1@ipfire.org> (raw)
In-Reply-To: <706ad76b-d06e-4a85-975a-b53a2e39bf46@orange.fr>

Hello Philippe,

Thanks for getting back so quickly.

I suppose we will just have to clear the directory before the lists are being restored. That should eliminate any problems after extraction.

Where the list should be backed up at all is a completely different story. We have been talking about this many times. Some people expect only the configuration to be included in the backup and others expect a full snapshot of the system. There is also the question of when the backup is going to be restored: A couple of days later you will be okay with a slightly out-of-date list; a couple of months later you will be carrying a lot of data that is basically worthless. But we are doing the same with the IPS rulesets and so on, so we should at least be consistent.

Best,
-Michael

> On 29 Sep 2026, at 16:07, p27m <p27m@orange.fr> wrote:
> 
> Hi Michael,
> 
> Yes, I think this is a good functional solution, although it would require a different implementation.
> However, it does not address the original problem that led me to propose this patch: the failure of a backup restore on fresh install when the backup contains a recent Toulouse blacklist.
> 
> In fact, the IPFire DBL list also contains the following directories:
> - ads
> - porn
> - violence
> 
> These are symlinks in the current Toulouse `blacklists.tar.gz`:
> - ads -> publicite
> - porn -> adult
> - violence -> agressif
> 
> Therefore, if IPFire DBL is installed by default in new IPFire system, restoring a backup containing a recent Toulouse blacklist could still result in exactly the same directory/symlink conflict during the untar restoration.
> 
> Regards,
> --
> Philippe
> 
> Le 29/09/2026 à 15:19, Michael Tremer a écrit :
>> Hello,
>> 
>> I generally do agree with dropping the old data. It is more than obsolete, but that leaves us with some new problems:
>> 
>> * No data is available immediately. Users would have to go down to the section of the page where they can select a list, enable the updates and trigger a manual update. Only then they will be able to start the URL Filter. This is a very convoluted process to enable a feature that should be very easy to configure.
>> 
>> * If we shipped IPFire DBL by default, that would be a very sensible solution actually. But then there is a danger that people will enable the categories they want, enable URL Filter, but never enable the automatic updates. If we enable the automatic updates ourselves, we would run into the problem that a lot of IPFire instances all over the world would be updating their blacklists although they are never being used which will simply waste disk space and bandwidth.
>> 
>> So I think we need a change which is to ship IPFire DBL for new installations, enable the auto-updates by default, but then only make them actually work if URL filter is enabled at the top. That will solve the problem in the latter case.
>> 
>> Does that sound good to you, too?
>> 
>> -Michael
> 



  reply	other threads:[~2026-09-29 15:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27  9:16 Philippe SCARSELLI
2026-08-29 15:31 ` Michael Tremer
2026-08-29 15:56   ` p27m
2026-09-07 15:22     ` Michael Tremer
2026-09-07 16:51       ` p27m
2026-09-27 10:44         ` Adolf Belka
2026-09-27 12:17           ` p27m
2026-09-29 13:19             ` Michael Tremer
2026-09-29 15:07               ` p27m
2026-09-29 15:10                 ` Michael Tremer [this message]
2026-09-29 15:37                   ` p27m

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD17803-1E9B-41C4-A51B-CCE5F3BC92D1@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    --cc=p27m@orange.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox