[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4375) MOD operations not being logged




--On Thursday, February 09, 2006 4:24 PM -0800 Quanah Gibson-Mount 
<quanah@stanford.edu> wrote:

>
>
> --On Thursday, February 09, 2006 12:50 AM +0000 quanah@stanford.edu wrote:
>
>> On Wednesday 08 February 2006 16:25, you wrote:
>>
>>> The *only* thing that has changed is the version of OpenLDAP software
>>> being used.  We haven't updated the process that writes to the account
>>> tree of the directory server in almost a year.
>>
>> Looking at my past logs where I audit the errors nightly, the correct
>> logging  of MOD operations broke between 2.2.27 (the release I was
>> running in  December) and 2.3.x.
>
> Adding some debugging statements, the path taken for MOD operations
> between 2.2 and 2.3 has changed significantly.
>
> Clearly, in 2.2, the do_modify function (now replaced by fe_op_modify)
> was called *before* slap_mods_check.  Now in 2.3, it is called *after*
> slap_mods_check, which has broken the logging.  This sequence apparently
> needs to be reversed back to the 2.2 behavior.

And of course, ADD's still log correctly, so this out-of-order logic path 
is specific to MODs:

Feb 11 01:57:39 ldap0.Stanford.EDU slapd[1153]: [ID 585459 local4.debug] 
conn=5476 op=5 ADD 
dn="suRegID=87d7de02f61311d2ae662436000baa77,cn=People,dc=Stanfo\
rd,dc=edu"
Feb 11 01:57:39 ldap0.Stanford.EDU slapd[1153]: [ID 588225 local4.debug] 
conn=5476 op=5 RESULT tag=105 err=19 text=some attributes not unique

Or, applying your earlier comments:

"I don't see any processing error here. The mod operation is rejected
before the Statslog statement is reached. The same can occur for all of
the operation types if input validation fails before reaching the
Statslog. In other words, Statslog only records properly formatted 
requests."


the DN of the ADD shouldn't be logged, either, which I think would be just 
as broken.

The point here is that what is being logged is:

(a) Not consistent between operations
(b) A major change over previous releases
(c) Not following the documented behavior for the stats loglevel in 
slapd.conf

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html