Re: ACLcheck abend issues

[Craig Johnson]

In article <will7410...@no-mx.forums.novell.com>, Will74103 wrote:
> I have been working with someone at Novell and we seem to be close to a
> resolution.
>
Can you provide some more info on your situation?

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

[Craig Johnson]

In article <kelloggf...@no-mx.forums.novell.com>, Kellogg wrote:
> Can you please let me know why the ACLcheck.nlm reloads on a regular
> basis when no changes are being made to the rules? This has been
> reported and I am trying to clarify why this is happening. I thought
> ACLcheck only reloads when changes to the proxy access rules are made or
> am I mistaken?
>
ACLCheck abends have usually resulted from some corruption in a rule. At
least prior to BM39SP2. The cure for that was to track down the offending
rule, delete and recreate it. If there is a new issue with BM39Sp2, try
backrevving ACLCHECK and see if it loads without error.

ACLCHECK will periodically reread the rules if there are groups called
out, to see if there are any changes in group membership lists. This can
be adjusted somewhat by loading ACLCHECK with a /g parameter to tell it
how often to refresh its rules. But it should not be unloading and
reloading itself.

[Mysterious]

will74103 wrote:
> I originally posted on this in the proxy forum. The details are in that
> post. To recap:
>
> I recently upgraded two BM servers that had been running stable for
> quite some time on NW65SP5 and BM3.8.4. I loaded NW65SP7 and then
> upgraded BM to 3.9.1. Servers and proxy ran fine with this
> configuration. I then updated one server to 3.9.2 because we very much
> wanted acl rule hit logging that was added in 3.9.2.
>
> Once the 3.9.2 code was applied and I turned on the acl logging feature
> the server began to suffer abends and lockups. We then went thru the
> process of upgrading all firmware and then applied all available NW65SP7
> updates. None of these updates made a difference.
>
> I have received a new test file this morning, that seems to have
> resolved the problem. We obviously will need to test further, but so
> far it looks good.
>
> Server Hardware running BM: HP DL380 G4
>
>

just a clarification

The first abend after apply sp2 is documented on tid 7002823.
To solve this abend, i provided you with a new aclcheck. This new
aclcheck fixes the abend and the slowness when reading SF rules. After
you enabled hit logging on the rules, server abended. This time was a
buffer overflow. The new aclcheck.nlm i provided to you this morning has
the fix for this abend.

gonzalo

[Craig Johnson]

In article <tcEJl.4948$s8....@kovat.provo.novell.com>, Mysterious wrote:
> The first abend after apply sp2 is documented on tid 7002823.
> To solve this abend, i provided you with a new aclcheck. This new
> aclcheck fixes the abend and the slowness when reading SF rules. After
> you enabled hit logging on the rules, server abended. This time was a
> buffer overflow. The new aclcheck.nlm i provided to you this morning has
> the fix for this abend.
>

Is this bug likely to affect anyone using rule hit logging? Or just those
with some certain level of rule hits?

[mysterious]

Craig Johnson wrote:

>>
> Is this bug likely to affect anyone using rule hit logging? Or just those
> with some certain level of rule hits?

it is difficult to predict. I could not duplicate it even using Will
rules. WE found it when looking at the coredump. So it is not a general
issue.

[Craig Johnson]

In article <7DHJl.5007$s8....@kovat.provo.novell.com>, Mysterious wrote:
> it is difficult to predict. I could not duplicate it even using Will
> rules. WE found it when looking at the coredump. So it is not a general
> issue.
>

OK - I've not seen it myself yet. But I also don't see much rule logging
on 3.9 servers yet.