From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] update-ipblocklists: remove "<INFO> Skipping" log entries
Date: Thu, 06 Jun 2024 16:55:52 +0200 [thread overview]
Message-ID: <3b83f7cf-1d66-486c-b4fc-703247d036c6@ipfire.org> (raw)
In-Reply-To: <A472F1A4-A3AB-4E37-9445-4517A3C87C12@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3956 bytes --]
Hi All,
On 05/06/2024 18:47, jon wrote:
> Comments below...
>
>
> Jon
>
>
>> On Jun 5, 2024, at 4:55 AM, Adolf Belka <adolf.belka(a)ipfire.org <mailto:adolf.belka(a)ipfire.org>> wrote:
>>
>> Hi All,
>>
>> On 05/06/2024 11:28, Michael Tremer wrote:
>>> Hello Jon,
>>>
>>> Why should this not be logged?
>>>
>
> Michael - To me Line 89 `<INFO> Skipping $blocklist blocklist - Too frequent update attempts!` has little to no value since it is time based (i.e., it is not time to update).
> See: https://github.com/ipfire/ipfire-2.x/blob/master/src/scripts/update-ipblocklists#L89 <https://github.com/ipfire/ipfire-2.x/blob/master/src/scripts/update-ipblocklists#L89>
>
> And to me the Line 103 `<INFO> Skipping $blocklist blocklist - It has not been modified!` has little value.
> See: https://github.com/ipfire/ipfire-2.x/blob/master/src/scripts/update-ipblocklists#L103 <https://github.com/ipfire/ipfire-2.x/blob/master/src/scripts/update-ipblocklists#L103>
>
> If it is to be used for troubleshooting maybe the date of last modification be added to the log message (e.g., $last_modified):
> See: https://github.com/ipfire/ipfire-2.x/blob/master/config/cfgroot/ipblocklist-functions.pl#L167 <https://github.com/ipfire/ipfire-2.x/blob/master/config/cfgroot/ipblocklist-functions.pl#L167>
I will look at doing something like that.
Regards,
Adolf.
>
> Otherwise I would remove.
>
> Just my 2c,
>
>
>>> -Michael
>>>
>>>> On 4 Jun 2024, at 21:22, Jon Murphy <jon.murphy(a)ipfire.org <mailto:jon.murphy(a)ipfire.org>> wrote:
>>>>
>>>> - Remove two <INFO> log entries from message log.
>>>>
>>>> Signed-off-by: Jon Murphy <jon.murphy(a)ipfire.org <mailto:jon.murphy(a)ipfire.org>>
>>>> ---
>>>> src/scripts/update-ipblocklists | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/src/scripts/update-ipblocklists b/src/scripts/update-ipblocklists
>>>> index a17b47999..dddde8d27 100644
>>>> --- a/src/scripts/update-ipblocklists
>>>> +++ b/src/scripts/update-ipblocklists
>>>> @@ -86,7 +86,7 @@ foreach my $blocklist (@blocklists) {
>>>> # Check if enough time has passed since the last download of the list.
>>>> if ($time <= $holdoff_time) {
>>>> # To frequent updates, log to syslog.
>>>> - &_log_to_syslog("<INFO> Skipping $blocklist blocklist - Too frequent update attempts!");
>>>> + # &_log_to_syslog("<INFO> Skipping $blocklist blocklist - Too frequent update attempts!");
>>>>
>>>> # Skip this provider.
>>>> next;
>>>> @@ -100,7 +100,7 @@ foreach my $blocklist (@blocklists) {
>>>> # Handle different return codes.
>>>> if ($return eq "not_modified") {
>>>> # Log notice to syslog.
>>>> - &_log_to_syslog("<INFO> Skipping $blocklist blocklist - It has not been modified!");
>>>> + # &_log_to_syslog("<INFO> Skipping $blocklist blocklist - It has not been modified!");
>>>> } elsif ($return eq "dl_error") {
>>>> # Log error to the syslog.
>>>> &_log_to_syslog("<ERROR> Could not update $blocklist blocklist - Download error\!");
>> The log message about not being modified was what a forum user was able to use to identify that the Alien Vault list had not been updated for at least 17 months.
>> That information could not be found from the Alien Vault site as there is no timestamp on the file being downloaded to be able to be processed.
>>
>
> Adolf - I did not change the `<INFO> Successfully updated ...` so a user should be able make a determination something stopped.
>
>> I would not want to lose this information otherwise when another provider silently closes their list because they have been taken over or decide to concentrate on funded lists it will prove very hard to figure out if the lists are still active, even more so as more lists get added.
>>
>
> See my "troubleshooting" comment above.
>
>> Regards,
>> Adolf.
>>
>>
>>>> --
>>>> 2.30.2
>>>>
>>
>> --
>> Sent from my laptop
>>
>
next parent reply other threads:[~2024-06-06 14:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A472F1A4-A3AB-4E37-9445-4517A3C87C12@ipfire.org>
2024-06-06 14:55 ` Adolf Belka [this message]
[not found] <AAFFDC1D-9A3C-4CB3-8782-E4E608E0074B@ipfire.org>
2024-06-24 15:21 ` Adolf Belka
[not found] <9E099FC3-0DD0-4FDC-94D4-3E44CB093DC0@ipfire.org>
2024-06-07 10:40 ` Michael Tremer
[not found] <EFBA494A-FB26-4FA6-87E1-0BE7A3CA154B@ipfire.org>
2024-06-07 7:40 ` Adolf Belka
2024-06-04 20:22 Jon Murphy
2024-06-05 9:28 ` Michael Tremer
2024-06-05 9:55 ` Adolf Belka
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=3b83f7cf-1d66-486c-b4fc-703247d036c6@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
/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