Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

ACLCHECK runs although no changes were made by an Administrator

3 views
Skip to first unread message

Chris Premo

unread,
Jun 29, 2009, 1:13:33 PM6/29/09
to
Were could I look to determine why my server will cause this to happen
on its own. None of the Administrators have made changes to our Access
Rules???

*****************************************************************
6-28-2009 8:13:22 am: ACLCHECK-4.90-9
ACLCHECK.NLM is reading rules from NDS...


6-28-2009 8:13:27 am: ACLCHECK-4.90-1
ACLCHECK.NLM read 36 rules from NDS.

Loading Module PERL.NLM [ OK ]
Auto-Loading Module LIBPERL.NLM [ OK ]
Loading Module CONLOG.NLM [ OK ]
Loading Module PROXY.NLM [NOT MULTIPLE]
******************************************************************

I've look in the crontab file and I don't see anything that would cause
this.


CRONTAB
***********************************************************************
# Run perl script to rotate logs each midnight.
0 0 * * * perl sys:/apache2/rotate.pl sys:/apache2/rotate.ini --noscreen

# Load Console logger Mon-Fri at 9:29 PM (21:29)
29 21 * * 1-5 load SYS:\SYSTEM\conlog maximum=100 archive=YES

# Load CSP_LIST Mon-Fri at 9:30 PM (21:30)
30 21 * * 1-5 Unload SYS:\System\proxy

# Load CSP_LIST Mon-Fri at 9:30 PM (21:30)
33 21 * * 1-5 SYS:\System\proxy -cc

# Load CSP_LIST Mon-Fri at 9:30 PM (21:30)
45 21 * * 1-5 SYS:\ETC\CPFILTER\CSP_LIST

# Unload console logger
30 0 * * 1-5 unload conlog

# Load Console logger Mon-Fri at 9:29 PM (21:29)
59 05 * * 1-5 load SYS:\SYSTEM\conlog maximum=100 archive=YES

# Load CSP_LIST Mon-Fri at 6:00 AM (06:00)
00 06 * * 1-5 Unload SYS:\System\proxy

# Load CSP_LIST Mon-Fri at 6:03 AM (06:03)
03 06 * * 1-5 SYS:\System\proxy -cc

# Unload console logger
06 06 * * 1-5 unload conlog
**********************************************************************

This is what the CRONLOG shows for the past 3 days:

******************************************************
06/27-00:00:01 perl sys:/apache2/rotate.pl sys:/apache2/rotate.ini
--noscreen
06/28-00:00:01 perl sys:/apache2/rotate.pl sys:/apache2/rotate.ini
--noscreen
06/29-00:00:00 perl sys:/apache2/rotate.pl sys:/apache2/rotate.ini
--noscreen
06/29-00:30:01 unload conlog
06/29-05:59:00 load SYS:\SYSTEM\conlog maximum=100 archive=YES
06/29-06:00:01 Unload SYS:\System\proxy
06/29-06:03:01 SYS:\System\proxy -cc
06/29-06:06:00 unload conlog
******************************************************

--

Craig Johnson

unread,
Jun 29, 2009, 1:50:06 PM6/29/09
to
ACLCHECK automatically runs at least once per day to look for changes
to things like group memberships changing.

This became quite an issue recently in conjunction with SurfControl as:
a) until latest 3.9 patch (I think) rule refreshing with SurfControl
involved could be very slow - on the order of minutes, and
b) everyone is denied access while the rules are being refreshed.

I had set up a cron job to have my aclcheck unload and reload at 2am to
test a method for forcing this refresh not to happen in the middle of
the day. You might be seeing it happen each day at the same time
ACLCHECK was last loaded.

Craig Johnson
Novell Support Connection SysOp
*** For a current patch list, tips, handy files and books on
BorderManager, go to http://www.craigjconsulting.com ***


Chris Premo

unread,
Jun 29, 2009, 6:52:40 PM6/29/09
to
I mean


# Load CSP_LIST Mon-Fri at 6:00 AM (06:00)

00 02 * * 1-5 Unload SYS:\System\ACLCHECK



# Load CSP_LIST Mon-Fri at 6:00 AM (06:00)

03 02 * * 1-5 Load SYS:\System\ACLCHECK

--

Chris Premo

unread,
Jun 29, 2009, 6:50:54 PM6/29/09
to
So if I add the following to my crontab we shouldn't see this issue
during normal business hours?


# Load CSP_LIST Mon-Fri at 6:00 AM (06:00)

03 01 * * 1-5 Unload SYS:\System\ACLCHECK

# Load CSP_LIST Mon-Fri at 6:00 AM (06:00)

03 05 * * 1-5 Load SYS:\System\ACLCHECK


--

Craig Johnson

unread,
Jun 30, 2009, 4:11:06 AM6/30/09
to
Basically, yes. Though I have to admit I also had some abends for a
while doing this until I got the latest 3.9 patch on. I also had real
problems because of clustering as I could not find a way to identify
which node was active on the cluster. I ended up with a system that
always ended up restarting one particular node, instead of one that
ended up restarting the active node.

Chris Premo

unread,
Jun 30, 2009, 12:12:56 PM6/30/09
to
Found out that Proxy must be unloaded before ACLCHECK can be unloaded.
So I changed my crontab file to read as follows:

#***********************************************
#This section Unloads and Load the PROXY.NLM
#and the ACLCHECK.NLM.
# Load Console logger Mon-Fri at 4:59 PM (04:59)
59 04 * * 1-5 load SYS:\SYSTEM\conlog maximum=100 archive=YES

# Load PROXY Mon-Fri at 5:00 AM (05:00)
00 05 * * 1-5 Unload SYS:\System\proxy

# Unloads ACLCHECK Mon-Fri at 5:01 AM (05:01)
01 05 * * 1-5 Unload SYS:\System\ACLCHECK

# Load ACLCHECK Mon-Fri at 5:02 AM (05:02)
02 05 * * 1-5 Load SYS:\System\ACLCHECK

# Load PROXY Mon-Fri at 5:03 AM (05:03)
03 05 * * 1-5 SYS:\System\proxy -cc

# Unload console logger
05 05 * * 1-5 unload conlog
#***********************************************

--

Craig Johnson

unread,
Jun 30, 2009, 2:44:49 PM6/30/09
to
In article <cQq2m.1174$_B1....@kovat.provo.novell.com>, Chris Premo
wrote:

> Found out that Proxy must be unloaded before ACLCHECK can be unloaded.
> So I changed my crontab file to read as follows:
>
Yes, should work. There is also a switch to tell aclcheck how often to
refresh (I think in 1 to 24 hours), but as the default seems to be once
every 24 hours, that switch shouldn't be needed.

Also, if aclcheck is initially loaded at 2am and never unloaded, it
should continue to refresh at that time, and so shouldn't need to be
unloaded daily. Perhaps weekly is less risky.

Chris Premo

unread,
Jun 30, 2009, 4:06:42 PM6/30/09
to
OK that sounds reasonable. I change it to run only tonight and if it
doesn't "Re-Check" during business hours thru Monday, I'll comment out
the Unload/Load of ACLCHECK and unload/Load CRON on the server.

--

0 new messages