Bug 12484

Summary: config/cron/crontab: error in location database hourly update
Product: IPFire Reporter: bitbanger <cmascott>
Component: ---Assignee: Arne.F <arne.fitzenreiter>
Status: CLOSED FIXED QA Contact:
Severity: - Unknown -    
Priority: - Unknown - CC: michael.tremer, opensysman, peter.mueller
Version: 2   
Hardware: all   
OS: Linux   

Description bitbanger 2020-09-07 22:44:27 UTC
Error source: commit eaba273a5f3e4455dccd31306443cacdc92ae29b
Location database update frequency

Change from monthly update to hourly update was not made correctly.
Whenever crontab is modified and saved, a warning is generated:

Warning line xx : Shell command beginning by '*'

Monthly requires 3 time fields; hourly requires 1 time field.
Line should read:

%hourly,random * [ -f "/var/ipfire/red/active" ] && /usr/local/bin/update-location-database >/dev/null 2>&1

This eliminates the warning described above.

Also, the comment was not updated; it still reads:

# Update GeoIP database once a month.

It should read:

# Update GeoIP database once an hour.
Comment 2 bitbanger 2020-09-24 14:19:42 UTC
(In reply to Michael Tremer from comment #1)
> https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;
> h=c40fa8a0c5f6fc117ca5a2c322396e83e06ed56e

crontab:
Code looks correct.
Comment still reads "once a month", should read "once an hour".
See original bug description.
Comment 3 Michael Tremer 2020-09-24 15:26:36 UTC
Hello,

I have removed the time in the comment, because we actually still only update once a week. But we will (re-)try once an hour.

https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=commitdiff;h=f5b04bfd4cf2541dd90e7e59442df7578d93a15c
Comment 4 Bug Mann 2020-09-30 10:08:14 UTC
I disagree with hourly updates for geo-location. We need stability with firewall rules, not random changes throughout the day that might impact users. Thanks.
Comment 5 Michael Tremer 2020-09-30 10:10:24 UTC
As I stated in my previous comment, the database is *NOT* being updated once an hour. The cronjob is called once an hour, but it might not update the database.
Comment 6 Bug Mann 2020-10-05 17:46:58 UTC
I the location database is only being amended once a week/month, then no point in a cron job checking hourly. Just seems risky & a waste of resource (even if small). Once a week or once a day safer. Having had all my location rules broken by the new database, I want to see stability please.
Comment 7 Michael Tremer 2020-10-06 11:53:56 UTC
(In reply to Bug Mann from comment #6)
> I the location database is only being amended once a week/month, then no
> point in a cron job checking hourly.

The database is being updated daily.

> Just seems risky & a waste of resource (even if small). Once a week or once a day safer. Having had all my location rules broken by the new database, I want to see stability please.

We built this whole system to distribute updates very quickly and that is why we decided to go this way. If you want this to be changed you need to bring us arguments why you think that this is a bad idea and not just express your wish that you would like things to be different.
Comment 8 Bug Mann 2020-10-15 18:08:24 UTC
ALL my firewalls that I manage were made kaput last night by a bad location database update (all running 2.25 150). (https://bugzilla.ipfire.org/show_bug.cgi?id=12499)

This is EXACTLY why I don't think hourly checking for location database changes is a good idea. My day has been wasted traveling around disabling GeoIP at the sites I support.

I have been using GeoIP in IPFire since first implemented, and had been happy with the stability and accuracy. However I have had more problems with your new implementation, and now have left disabled. I have lost trust in the reliability. We all want stable as well as secure.

I would go as far as to suggest having a manual update option via the Firewall > Location Block admin page, instead of auto update. So we can test in advance with no surprises.

It is all very well stating the virtue of libloc (https://blog.ipfire.org/post/libloc-or-what-is-working-inside-it), which is a great feat by the way, but if the actual database keeps going bad, then a regression from first GeoIP implementation.
Comment 9 Michael Tremer 2020-10-15 19:23:13 UTC
I understand your concern, but that problem has nothing to do with this bug report.
Comment 10 Peter Müller 2022-03-21 21:58:33 UTC
Closing this bug as being FIXED. Please reopen, if necessary.