Hi list, I found some entries in my OL logs about searches for attribute "1.1". I've seen that the requester is the user used for the replication (syncrepl).
Can anyone explain to me what this kind of attribute is this?
*conn=0 op=3 SRCH attr=1.1 *
Thanks in advance Marco
Marco Pizzoli marco.pizzoli@gmail.com writes:
Hi list, I found some entries in my OL logs about searches for attribute "1.1". I've seen that the requester is the user used for the replication (syncrepl).
Can anyone explain to me what this kind of attribute is this?
conn=0 op=3 SRCH attr=1.1
oid 1.1 is just 'no attributes'
-Dieter
Hi Dieter, thanks for your answer.
I came to this evidence in investigating an anomaly that I'm having with my accesslog database. Symptom I was having was continuous high cpu spot. I suspected it was due to my accesslog database.
- I made a slapcat of my entire log database. - I erased my log database - I tried a slapadd of my log database
I had this problem:
/usr/sbin/slapadd -b "cn=log,dc=mycorp.it" -l /srv/bck/dump_db_log.ldif.20100916 . 0.00% eta 08h35m elapsed spd 90.2 k/s str2entry: invalid value for attributeType reqControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=4907) - 0.01% eta 05h58m elapsed spd 205.7 k/s Closing DB...
I went to that line and found this entry:
dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it objectClass: auditSearch structuralObjectClass: auditSearch reqStart: 20100913065628.000008Z reqEnd: 20100913065628.000009Z reqType: search reqSession: 1129 reqAuthzID: cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc= mycorp.it reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue "30440K0103043M7269643N 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 330303030303023303033233030303030300001PP"} reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} reqDN: dc=mycorp.it reqResult: 0 reqScope: base reqDerefAliases: never reqAttrsOnly: TRUE reqFilter: (objectclass=*) reqAttr: 1.1 reqEntries: 0 reqTimeLimit: -1 reqSizeLimit: 1 entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913065628Z entryCSN: 20100913065628.167225Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913065628Z
Can someone tell me why this entry result not accepted to my openldap system? I'm using OL 2.4.23 with password policy overlay defined. The entry I posted is related to an access made by a specific syncrepl-user. Replica configured in mirror-mode.
Other OL systems are 2.4.22.
Deleting this entry and re-slapadding I had another similar problem.
/usr/sbin/slapadd2.4 -b "cn=log,dc=mycorp.it" -l /tmp/dump_db_log.ldif.20100916_Corrected " 4.69% eta 01h07m elapsed 03m19s spd 542.3 k/s str2entry: invalid value for attributeType reqRespControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1) slapadd2.4: could not parse entry (line=3099715) * 4.70% eta 01h07m elapsed 03m20s spd 979.8 k/s Closing DB...
The entry affected is this one:
dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it objectClass: auditBind structuralObjectClass: auditBind reqStart: 20100913093021.000000Z reqEnd: 20100913093021.000001Z reqType: bind reqSession: 2746 reqAuthzID: reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} reqDN: uid=pe1597,ou=People,dc=mycorp.it reqResult: 0 reqVersion: 3 reqMethod: SIMPLE entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be creatorsName: cn=Manager,cn=log,dc=mycorp.it createTimestamp: 20100913093021Z entryCSN: 20100913093021.411398Z#000000#003#000000 modifiersName: cn=Manager,cn=log,dc=mycorp.it modifyTimestamp: 20100913093021Z
Any help is appreciated. Thanks Marco
On Thu, Sep 16, 2010 at 12:27 PM, Dieter Kluenter dieter@dkluenter.dewrote:
Marco Pizzoli marco.pizzoli@gmail.com writes:
Hi list, I found some entries in my OL logs about searches for attribute "1.1".
I've
seen that the requester is the user used for the replication (syncrepl).
Can anyone explain to me what this kind of attribute is this?
conn=0 op=3 SRCH attr=1.1
oid 1.1 is just 'no attributes'
-Dieter
-- Dieter Klünter | Systemberatung sip: 7770535@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
Marco Pizzoli writes:
Can anyone explain to me what this kind of attribute is this?
*conn=0 op=3 SRCH attr=1.1
It's the LDAP way to suppress the default that a search returns all user attributes, as if you asked for attribute "*". If you ask only for attribute 1.1, the search returns only DNs and no attributes.
Actually it's just an object identifier chosen arbitrarily by the LDAP standard as one which "does not and cannot correspond to any attribute in use" (RFC 4511). Any other nonexistent attribute would have served as well.
Hi Marco,
Le 16/09/2010 13:07, Marco Pizzoli a écrit :
I came to this evidence in investigating an anomaly that I'm having with my accesslog database. Symptom I was having was continuous high cpu spot. I suspected it was due to my accesslog database.
- I made a slapcat of my entire log database.
- I erased my log database
- I tried a slapadd of my log database
I had this problem:
...
90.2 k/s str2entry: invalid value for attributeType reqControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1)
...
I went to that line and found this entry:
dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it http://mycorp.it
...
reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue "30440K0103043M7269643N 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 330303030303023303033233030303030300001PP"} reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE}
...
Can someone tell me why this entry result not accepted to my openldap system? I'm using OL 2.4.23 with password policy overlay defined. The entry I posted is related to an access made by a specific syncrepl-user. Replica configured in mirror-mode.
Other OL systems are 2.4.22.
Deleting this entry and re-slapadding I had another similar problem.
...
542.3 k/s str2entry: invalid value for attributeType reqRespControls #0 (syntax 1.3.6.1.4.1.4203.666.11.5.3.1)
...
The entry affected is this one: dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it http://mycorp.it
...
reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"}
Both errors seem to indicate that slapd doesn't recognize a LDAP control OID - in the first case the LDAP Content Sync control (syncrepl) (1.3.6.1.4.1.4203.1.9.1.1) and in the second the password policy (1.3.6.1.4.1.42.2.27.8.5.1).
Could it be that the system you encounter this on does not have the syncprov and ppolicy overlays enabled, whereas your others do?
Hope this helps, Jonathan
Hi Jonathan,
no, all my 4 systems are configured equally, same configuration file (except for little specifications of every single instance) on all of them. The only difference is OL version which is 2.4.23 on this one, and 2.4.22 on others.
Could it be due to the order of directives in my configuration file? This is the order of inclusion of my overlay directives:
- overlay_password_policy - overlay_syncprov - overlay_auditlog - overlay_accesslog - overlay_sssvlv - overlay_memberof
Thanks again Marco
On Tue, Sep 21, 2010 at 8:18 PM, Jonathan CLARKE < jonathan.clarke@normation.com> wrote:
Hi Marco,
Le 16/09/2010 13:07, Marco Pizzoli a écrit :
I came to this evidence in investigating an anomaly that I'm having with
my accesslog database. Symptom I was having was continuous high cpu spot. I suspected it was due to my accesslog database.
- I made a slapcat of my entire log database.
- I erased my log database
- I tried a slapadd of my log database
I had this problem:
...
90.2 k/s str2entry: invalid value for attributeType reqControls #0
(syntax 1.3.6.1.4.1.4203.666.11.5.3.1)
...
I went to that line and found this entry:
dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it <http://mycorp.it
...
reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue "30440K0103043M7269643N
3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 330303030303023303033233030303030300001PP"} reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE}
...
Can someone tell me why this entry result not accepted to my openldap system? I'm using OL 2.4.23 with password policy overlay defined. The entry I posted is related to an access made by a specific syncrepl-user. Replica configured in mirror-mode.
Other OL systems are 2.4.22.
Deleting this entry and re-slapadding I had another similar problem.
...
542.3 k/s str2entry: invalid value for attributeType reqRespControls #0
(syntax 1.3.6.1.4.1.4203.666.11.5.3.1)
...
The entry affected is this one: dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it <http://mycorp.it
...
reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"}
Both errors seem to indicate that slapd doesn't recognize a LDAP control OID - in the first case the LDAP Content Sync control (syncrepl) (1.3.6.1.4.1.4203.1.9.1.1) and in the second the password policy (1.3.6.1.4.1.42.2.27.8.5.1).
Could it be that the system you encounter this on does not have the syncprov and ppolicy overlays enabled, whereas your others do?
Hope this helps, Jonathan
--
Jonathan CLARKE
Normation 44 rue Cauchy, 94110 Arcueil, France
Telephone: +33 (0)1 83 62 26 96
Web: http://www.normation.com/
On 22/09/2010 09:10, Marco Pizzoli wrote:
Hi Jonathan,
no, all my 4 systems are configured equally, same configuration file (except for little specifications of every single instance) on all of them. The only difference is OL version which is 2.4.23 on this one, and 2.4.22 on others.
Could it be due to the order of directives in my configuration file? This is the order of inclusion of my overlay directives:
- overlay_password_policy
- overlay_syncprov
- overlay_auditlog
- overlay_accesslog
- overlay_sssvlv
- overlay_memberof
Could be - I'm not sure at this point. Make sure they're all in the same order on all servers.
I see no changes between 2.4.22 and 2.4.23 that could lead to this specific error occuring, but of course it may be more complicated than it looks.
Jonathan
Today I tried to change the order of overlays inclusion and I had the same problem. If the module was not loaded, I couldn't save that data in the accesslog db.
Someone could suggest a possible solution or an alternative trial?
Thanks in advance Marco
On Wed, Sep 22, 2010 at 10:16 AM, Jonathan CLARKE < jonathan.clarke@normation.com> wrote:
On 22/09/2010 09:10, Marco Pizzoli wrote:
Hi Jonathan,
no, all my 4 systems are configured equally, same configuration file (except for little specifications of every single instance) on all of them. The only difference is OL version which is 2.4.23 on this one, and 2.4.22 on others.
Could it be due to the order of directives in my configuration file? This is the order of inclusion of my overlay directives:
- overlay_password_policy
- overlay_syncprov
- overlay_auditlog
- overlay_accesslog
- overlay_sssvlv
- overlay_memberof
Could be - I'm not sure at this point. Make sure they're all in the same order on all servers.
I see no changes between 2.4.22 and 2.4.23 that could lead to this specific error occuring, but of course it may be more complicated than it looks.
Jonathan
--
Jonathan CLARKE
Normation 44 rue Cauchy, 94110 Arcueil, France
Telephone: +33 (0)1 83 62 26 96
Web: http://www.normation.com/
--On Tuesday, September 28, 2010 2:37 PM +0200 Marco Pizzoli marco.pizzoli@gmail.com wrote:
Today I tried to change the order of overlays inclusion and I had the same problem. If the module was not loaded, I couldn't save that data in the accesslog db.
Someone could suggest a possible solution or an alternative trial?
Do you use static or dynamic modules?
Your directives are not in OpenLDAP's loading format, so if that's a direct copy from your slapd.conf/cn=config db, then none of those statements makes sense.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
Dieter Kluenter -
Hallvard B Furuseth -
Jonathan CLARKE -
Marco Pizzoli -
Quanah Gibson-Mount