SquidGuard - time based ACL not working reliably
Got a bit of a problem with SquidGuard 1.4_2 pkg v.1.9.1 on PFSense 2.0.1-RELEASE (i386)
Only other package installed is Squid
I have an ACL to block certain websites between 9-6 (youtube etc.)
This has worked perfectly for a long time with PFSense 1.2 and more recently 2.0 BETA
After I upgraded to PFSense 2.0 Final the times based redirector became very unreliable, sometimes completely failing to work at all.
I recentely did a complete reinstall with PFSense 2.0.1-Release, and now SquidGuard is working fine BUT I have to hit the 'Apply' button on the SquidGuard webconfig page at 9 in the morning and 6PM in the afternoon.
If I don't press 'Apply' the changes to the ACL which are meant to happen at 9 and 6 do not take effect.
Anyone have an clues as to how I can get it working properly again?
Yes, others have this problem, including myself on multiple systems running 2.0.1. There is some discussion at http://forum.pfsense.org/index.php/topic,41747.msg247614.html#msg247614 - other sort-of-related issues are also discussed in that post, including the issue of getting the browser not to cache the error pages during off times.
It seems better in 2.1-DEVELOPMENT but I will double-check some testing with a recent 2.1 build today and post some results in 24 hours.
Your workaround is the way we do it - restart Squid at the relevant times. You can automate that using Cron as documented in the post above.
I still can not find the reason for such behavior. Maybe a bug in the squidGuard
I looked at this today on 2 fresh nanobsd test systems. On one I installed 2.0.1-RELEASE and the other 2.1-DEVELOPMENT (from 29March). On both Squid is installed with all defaults then just select transparent proxy and save - nothing fancy. Then add a Times entry with a list of a couple of times like 14:00-14:10 14:20-14:30 14:40-14:50. Make a Target Category with just 1 entry in the domains list. Add a groups ACL with the local LAN subnet 192.168.1.0/24 in Client, pick the time and deny during those times. In Common ACL allow everything and put a message in Proxy Denied Error. Save everything, select Enable and Apply in General Settings. This should be a very basic configuration that blocks access to 1 domain during the given times.
In /var/squidGuard/log/squidGuard.log all looks good at first:
2012-04-03 17:12:13  squidGuard 1.4 started (1333452433.354) 2012-04-03 17:12:13  Info: recalculating alarm in 167 seconds 2012-04-03 17:12:13  squidGuard ready for requests (1333452433.370) 2012-04-03 17:12:13  squidGuard 1.4 started (1333452433.364) 2012-04-03 17:12:13  Info: recalculating alarm in 167 seconds 2012-04-03 17:12:13  squidGuard ready for requests (1333452433.400) 2012-04-03 17:12:13  squidGuard 1.4 started (1333452433.393) 2012-04-03 17:12:13  Info: recalculating alarm in 167 seconds 2012-04-03 17:12:13  squidGuard ready for requests (1333452433.410)
But then there are no more "recalculating alarm" messages. The rules at the time it starts apply forever.
I tried running squidGuard interactively from root just to see what it does:
/usr/local/bin/squidGuard -d -c /usr/local/etc/squidGuard/squidGuard.conf 2012-04-03 16:59:01  New setting: logdir: /var/squidGuard/log 2012-04-03 16:59:01  New setting: dbhome: /var/db/squidGuard 2012-04-03 16:59:01  init domainlist /var/db/squidGuard/DinnerSites/domains 2012-04-03 16:59:01  loading dbfile /var/db/squidGuard/DinnerSites/domains.db 2012-04-03 16:59:01  squidGuard 1.4 started (1333451641.391) 2012-04-03 16:59:01  Info: recalculating alarm in 59 seconds 2012-04-03 16:59:01  squidGuard ready for requests (1333451641.398) 2012-04-03 17:00:00  Info: recalculating alarm in 30 seconds 2012-04-03 17:00:30  Info: recalculating alarm in 30 seconds 2012-04-03 17:01:01  Info: recalculating alarm in 239 seconds 2012-04-03 17:05:01  Info: recalculating alarm in 30 seconds 2012-04-03 17:05:31  Info: recalculating alarm in 30 seconds 2012-04-03 17:06:01  Info: recalculating alarm in 239 seconds 2012-04-03 17:10:01  Info: recalculating alarm in 30 seconds 2012-04-03 17:10:31  Info: recalculating alarm in 30 seconds 2012-04-03 17:11:02  Info: recalculating alarm in 238 seconds 2012-04-03 17:15:01  Info: recalculating alarm in 30 seconds 2012-04-03 17:15:31  Info: recalculating alarm in 30 seconds 2012-04-03 17:16:01  Info: recalculating alarm in 239 seconds
This works as expected. I even looked in the squidGuard 1.4 source code. The code finds the next time there is a rule change in minutes, compared to the current time in minutes. It finds an equal or greater entry. Then it works out the time in seconds to when the rule change applies. If the time is negative or zero it waits 30 seconds. This is the cause of the "30 seconds" entries - good to know that these are harmless.
I even managed to modify the "proxy" account so I could login to it and then ran squidGuard interactively as above. It calculated times fine.
So there is no basic issue with the squidGuard source code's calculations.
There were some updated Squid configuration keywords in the Squid docs, so I replaced the default Squid Custom Options with:
url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/etc/squidGuard/squidGuard.conf;redirector_bypass off;url_rewrite_children 3
This made no difference, but anything is worth a try!
All the effects were the same on 2.0.1 or 2.1
So far, I have to conclude that there is something special about the way that Squid creates the 3 SquidGuard processes, and somehow the alarm signal doesn't actually get delivered to the squidGuard process even though it sets one.
Anyone with good ideas speak up now!
Is there a squid in the logs the next line: "error execve: 2" ? ( need sigHUP patch )
There are no "execve" or other nasty messages in the squid, squidguard or system logs. SquidGuard somehow just seems to "forget" to respond to SIGALRM.
I looked in the Squid source ipc.c - ipcCreate function does the creation of helper processes like SquidGuard. It does ordinary fork() and execvp(prog,args) calls to make a child process and switch it to the required program. There's nothing special there that stands out to me that would prevent the child process from having SIGALRM work. But somehow it works interactively but not when a child process of Squid. I am still trying to work out what the difference could be in the process environment.