December 2008 - openldap-technical

CSN too old, ignoring, N-way multi-master replication

by Adrien Futschik

I'm starting a new thread to make it easier to understand my problem. I'm testing N-way multimaster replication with OpenLDAP 2.4.13. I'm able to successfully import data into an instance and have my two masters to sync correctly but then when I try to add a new entry in one of the two masters, I'm getting strange messages : let's say we have m1 & m2 (m1 & m2 are on the same server): I initial import data into m1, it is successfully imported into m2 (at least it looks like it). Then I'm trying to add an entry on m2 (cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr). I'm getting strange message on m1 & m2 : m1 log :(repetitively) [...] Entry ou=administrateurs,o=gazdefrance,c=fr CSN 20081224125950.481561Z#000000#001#000000 older or equal to ctx 20081224125950.481561Z#000000#001#000000 Entry cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr changed by peer, ignored syncprov_search_response: cookie=rid=004,sid=002,csn=20081224125950.481561Z#000000#001#000000;20081224130148.522455Z#000000#002#000000 do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT [...] m2 log : (repetitively) [...] master where I added an entry : do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: cookie=rid=004,sid=002,csn=20081224125950.481561Z#000000#001#000000;20081224130148.522455Z#000000#002#000000 [...] Is this a bug ? Am-I doing something wrong ? If I add the same entry to m1 and not m2 I get the following messages : on m2 : syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=004 be_search (0) syncrepl_entry: rid=004 cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr <= bdb_equality_candidates: (entryCSN) not indexed <= bdb_inequality_candidates: (entryCSN) not indexed <= bdb_inequality_candidates: (entryCSN) not indexed syncprov_search_response: cookie=rid=005,sid=001,csn=20081224132158.749532Z#000000#001#000000 syncrepl_entry: rid=004 be_add (0) do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: cookie=rid=004,sid=002,csn=20081224132238.790862Z#000000#001#000000 <= bdb_inequality_candidates: (entryCSN) not indexed nonpresent_callback: rid=004 present UUID 96268508-6609-102d-9d8e-9742e72db399, dn c=fr nonpresent_callback: rid=004 present UUID 962af700-6609-102d-9d8f-9742e72db399, dn o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962bd698-6609-102d-9d90-9742e72db399, dn ou=personnes,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962c00b4-6609-102d-9d91-9742e72db399, dn ou=appli,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962c2634-6609-102d-9d92-9742e72db399, dn ou=groupes,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962ca492-6609-102d-9d93-9742e72db399, dn ou=administrateurs,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962cce90-6609-102d-9d94-9742e72db399, dn o=edf,c=fr nonpresent_callback: rid=004 present UUID 962d7138-6609-102d-9d95-9742e72db399, dn ou=personnes,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962d96f4-6609-102d-9d96-9742e72db399, dn ou=appli,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962deafa-6609-102d-9d97-9742e72db399, dn ou=groupes,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962ef026-6609-102d-9d98-9742e72db399, dn ou=administrateurs,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962f156a-6609-102d-9d99-9742e72db399, dn o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 962fca8c-6609-102d-9d9a-9742e72db399, dn ou=personnes,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 962fef76-6609-102d-9d9b-9742e72db399, dn ou=appli,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 9630106e-6609-102d-9d9c-9742e72db399, dn ou=groupes,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 9630bfa0-6609-102d-9d9d-9742e72db399, dn ou=administrateurs,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID ae0e93d6-6609-102d-9d9e-9742e72db399, dn cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr slap_queue_csn: queing 0x843fef0 20081224132238.790862Z#000000#001#000000 slap_graduate_commit_csn: removing 0x83d6410 20081224132238.790862Z#000000#001#000000 on m1 : slap_queue_csn: queing 0x1df3860 20081224132238.790862Z#000000#001#000000 slap_graduate_commit_csn: removing 0x9703700 20081224132238.790862Z#000000#001#000000 <= bdb_equality_candidates: (entryCSN) not indexed <= bdb_inequality_candidates: (entryCSN) not indexed Entry ou=administrateurs,o=gazdefrance,c=fr CSN 20081224132158.749532Z#000000#001#000000 older or equal to ctx 20081224132158.749532Z#000000#001#000000 syncprov_search_response: cookie=rid=004,sid=002,csn=20081224132238.790862Z#000000#001#000000 do_syncrep2: rid=005 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT do_syncrep2: cookie=rid=005,sid=001,csn=20081224132158.749532Z#000000#001#000000 Here is the entry I'm adding : dn: cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf, c=fr objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgPerson objectclass: ditPerson cn: adrien-externe.futschik(a)edfgdf.fr sn: Futschik givenName: Adrien uid: adrien-externe.futschik(a)edfgdf.fr mail: adrien-externe.futschik(a)edfgdf.fr telephonenumber: 0123456789 userpassword: {SSHA}GuU6CMRoOxp9EA1ANafzuRUXADKlBA0r allowedServices: appli20 pretty simple isn't it ? What's going wrong ? You'll find in attachment the script I'm using to set up the replication (modified version of test050-syncrepl-multimaster). Here is the config : initialization of m1 : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: ${PASSWD} initialization of m2 : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: ${PASSWD} syncprov overlay on m1 : dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE syncrepl on m2: dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE schema on m1: include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif include: file://$ABS_SCHEMADIR/corba.ldif include: file://$ABS_SCHEMADIR/java.ldif include: file://$ABS_SCHEMADIR/misc.ldif include: file://$ABS_SCHEMADIR/nds.ldif include: file://$ABS_SCHEMADIR/dit.ldif database en m1: dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./openldap-data olcRootDN: $MANAGERDN olcRootPW: ${PASSWD} olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,seeAlso,entryUUID eq olcDbIndex: mail,givenName,uid pres,eq,sub olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=secret searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=secret searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov After that I populate m1 with attached arbre.ldif. Thanks in advance. Adrien

14 years, 9 months

1
0
0 / 0

Re: Re: CSN too old, ignoring - and therefore not syncing

by Adrien Futschik

You're right I might have forgotten the most essential :) You'll find in attachment the script I'm using to set up the replication (modified version of test050-syncrepl-multimaster). Here is the config : initialization of m1 : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: ${PASSWD} initialization of m2 : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: ${PASSWD} syncprov overlay on m1 : dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE syncrepl on m2: dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE schema on m1: include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif include: file://$ABS_SCHEMADIR/corba.ldif include: file://$ABS_SCHEMADIR/java.ldif include: file://$ABS_SCHEMADIR/misc.ldif include: file://$ABS_SCHEMADIR/nds.ldif include: file://$ABS_SCHEMADIR/dit.ldif database en m1: dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./openldap-data olcRootDN: $MANAGERDN olcRootPW: ${PASSWD} olcDbIndex: default pres,eq olcDbIndex: cn,sn pres,eq,sub olcDbIndex: objectClass,seeAlso,entryUUID eq olcDbIndex: mail,givenName,uid pres,eq,sub olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=secret searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=secret searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov After that I populate m1 with attached arbre.ldif. Thanks in advance. Adrien ======================================== Message date : Dec 24 2008, 03:23 PM From : "Gavin Henry" <gavin.henry(a)gmail.com> To : adrien.futschik(a)atosorigin.com, openldap-technical(a)openldap.org Copy to : Subject : Re: CSN too old, ignoring - and therefore not syncing Config? On 24/12/2008, Adrien Futschik <adrien.futschik(a)atosorigin.com> wrote: > I'm facing a similar problem. > I'm testing N-way multimaster replication with OpenLDAP 2.4.13. > > I'm able to successfully import data into an instance and have my two > masters to sync correctly but then when I try to add a new entry in one of > the two masters, I'm getting strange messages : > > let's say we have m1 & m2 (m1 & m2 are on the same server): > I initial import data into m1, it is successfully imported into m2 (at least > it looks like it). > Then I'm trying to add an entry on m2 > (cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr). I'm > getting strange message on m1 & m2 : > > m1 log :(repetitively) > [...] > Entry ou=administrateurs,o=gazdefrance,c=fr CSN > 20081224125950.481561Z#000000#001#000000 older or equal to ctx > 20081224125950.481561Z#000000#001#000000 > Entry cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr > changed by peer, ignored > syncprov_search_response: > cookie=rid=004,sid=002,csn=20081224125950.481561Z#000000#001#000000;20081224130148.522455Z#000000#002#000000 > do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT > [...] > > > m2 log : (repetitively) > [...] > master where I added an entry : > do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT > do_syncrep2: > cookie=rid=004,sid=002,csn=20081224125950.481561Z#000000#001#000000;20081224130148.522455Z#000000#002#000000 > [...] > > Is this a bug ? Am-I doing something wrong ? > > If I add the same entry to m1 and not m2 I get the following messages : > > on m2 : > syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > syncrepl_entry: rid=004 be_search (0) > syncrepl_entry: rid=004 > cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr > <= bdb_equality_candidates: (entryCSN) not indexed > <= bdb_inequality_candidates: (entryCSN) not indexed > <= bdb_inequality_candidates: (entryCSN) not indexed > syncprov_search_response: > cookie=rid=005,sid=001,csn=20081224132158.749532Z#000000#001#000000 > syncrepl_entry: rid=004 be_add (0) > do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT > do_syncrep2: > cookie=rid=004,sid=002,csn=20081224132238.790862Z#000000#001#000000 > <= bdb_inequality_candidates: (entryCSN) not indexed > nonpresent_callback: rid=004 present UUID > 96268508-6609-102d-9d8e-9742e72db399, dn c=fr > nonpresent_callback: rid=004 present UUID > 962af700-6609-102d-9d8f-9742e72db399, dn o=edfgdf,c=fr > nonpresent_callback: rid=004 present UUID > 962bd698-6609-102d-9d90-9742e72db399, dn ou=personnes,o=edfgdf,c=fr > nonpresent_callback: rid=004 present UUID > 962c00b4-6609-102d-9d91-9742e72db399, dn ou=appli,o=edfgdf,c=fr > nonpresent_callback: rid=004 present UUID > 962c2634-6609-102d-9d92-9742e72db399, dn ou=groupes,o=edfgdf,c=fr > nonpresent_callback: rid=004 present UUID > 962ca492-6609-102d-9d93-9742e72db399, dn ou=administrateurs,o=edfgdf,c=fr > nonpresent_callback: rid=004 present UUID > 962cce90-6609-102d-9d94-9742e72db399, dn o=edf,c=fr > nonpresent_callback: rid=004 present UUID > 962d7138-6609-102d-9d95-9742e72db399, dn ou=personnes,o=edf,c=fr > nonpresent_callback: rid=004 present UUID > 962d96f4-6609-102d-9d96-9742e72db399, dn ou=appli,o=edf,c=fr > nonpresent_callback: rid=004 present UUID > 962deafa-6609-102d-9d97-9742e72db399, dn ou=groupes,o=edf,c=fr > nonpresent_callback: rid=004 present UUID > 962ef026-6609-102d-9d98-9742e72db399, dn ou=administrateurs,o=edf,c=fr > nonpresent_callback: rid=004 present UUID > 962f156a-6609-102d-9d99-9742e72db399, dn o=gazdefrance,c=fr > nonpresent_callback: rid=004 present UUID > 962fca8c-6609-102d-9d9a-9742e72db399, dn ou=personnes,o=gazdefrance,c=fr > nonpresent_callback: rid=004 present UUID > 962fef76-6609-102d-9d9b-9742e72db399, dn ou=appli,o=gazdefrance,c=fr > nonpresent_callback: rid=004 present UUID > 9630106e-6609-102d-9d9c-9742e72db399, dn ou=groupes,o=gazdefrance,c=fr > nonpresent_callback: rid=004 present UUID > 9630bfa0-6609-102d-9d9d-9742e72db399, dn > ou=administrateurs,o=gazdefrance,c=fr > nonpresent_callback: rid=004 present UUID > ae0e93d6-6609-102d-9d9e-9742e72db399, dn > cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr > slap_queue_csn: queing 0x843fef0 20081224132238.790862Z#000000#001#000000 > slap_graduate_commit_csn: removing 0x83d6410 > 20081224132238.790862Z#000000#001#000000 > > on m1 : > slap_queue_csn: queing 0x1df3860 20081224132238.790862Z#000000#001#000000 > slap_graduate_commit_csn: removing 0x9703700 > 20081224132238.790862Z#000000#001#000000 > <= bdb_equality_candidates: (entryCSN) not indexed > <= bdb_inequality_candidates: (entryCSN) not indexed > Entry ou=administrateurs,o=gazdefrance,c=fr CSN > 20081224132158.749532Z#000000#001#000000 older or equal to ctx > 20081224132158.749532Z#000000#001#000000 > syncprov_search_response: > cookie=rid=004,sid=002,csn=20081224132238.790862Z#000000#001#000000 > do_syncrep2: rid=005 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT > do_syncrep2: > cookie=rid=005,sid=001,csn=20081224132158.749532Z#000000#001#000000 > > Here is the entry I'm adding : > > dn: cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf, c=fr > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetorgPerson > objectclass: ditPerson > cn: adrien-externe.futschik(a)edfgdf.fr > sn: Futschik > givenName: Adrien > uid: adrien-externe.futschik(a)edfgdf.fr > mail: adrien-externe.futschik(a)edfgdf.fr > telephonenumber: 0123456789 > userpassword: {SSHA}GuU6CMRoOxp9EA1ANafzuRUXADKlBA0r > allowedServices: appli20 > > pretty simple isn't it ? What's going wrong ? > > Adrien > > ======================================== > Message date : Dec 23 2008, 07:39 PM > From : "Gavin Henry" <gavin.henry(a)gmail.com> > To : openldap-technical(a)openldap.org > Copy to : > Subject : Fwd: CSN too old, ignoring - and therefore not syncing > > ---------- Forwarded message ---------- > From: Pat Riehecky <prieheck(a)iwu.edu> > Date: Tue, 23 Dec 2008 12:34:33 -0600 > Subject: Re: CSN too old, ignoring - and therefore not syncing > To: Gavin Henry <gavin.henry(a)gmail.com> > > On Tue, 2008-12-23 at 18:28 +0000, Gavin Henry wrote: > > Where did you read that those were needed anyway? If it was the admin > > guide then I need to fix it ;-) > > > > Gavin. > > I have no idea where I found those at... I know it wasn't the (recent) > admin guide. It may have been from around the 2.4.8 release, but that > is long gone... > > Pat > > > > > On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > > > On Tue, 2008-12-23 at 15:55 +0000, Gavin Henry wrote: > > >> Try dropping nopresent and reloadhint relating to ITS5669. You only > > >> need these two syncprov settings on an accesslog db. > > >> > > >> Gavin. > > > > > > Thanks, that did the job! > > > > > > Pat > > > > > >> > > >> On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > > >> > On Tue, 2008-12-23 at 11:45 +0000, Gavin Henry wrote: > > >> >> Can you post your config somewhere? > > >> > > > >> > > > >> > allow bind_v2 > > >> > > > >> > include /etc/ldap/schema/core.schema > > >> > include /etc/ldap/schema/cosine.schema > > >> > include /etc/ldap/schema/nis.schema > > >> > include /etc/ldap/schema/inetorgperson.schema > > >> > include /etc/ldap/schema/samba.schema > > >> > include /etc/ldap/schema/eduperson-200412.schema > > >> > include /etc/ldap/schema/hdb.schema > > >> > include /etc/ldap/schema/IWU.schema > > >> > > > >> > pidfile /var/run/slapd/slapd.pid > > >> > argsfile /var/run/slapd/slapd.args > > >> > > > >> > modulepath /usr/lib/ldap > > >> > moduleload back_hdb > > >> > moduleload back_monitor > > >> > moduleload memberof > > >> > moduleload syncprov > > >> > moduleload smbk5pwd > > >> > > > >> > tool-threads 2 > > >> > sizelimit 500 > > >> > idletimeout 7200 > > >> > > > >> > TLSCACertificateFile /etc/ldap/ssl/IWU.crt > > >> > TLSCertificateFile /etc/ldap/ssl/ldap.iwu.edu.crt > > >> > TLSCertificateKeyFile /etc/ldap/ssl/ldap.iwu.edu.key > > >> > TLSVerifyClient allow > > >> > > > >> > localSSF 160 > > >> > security ssf=1 update_ssf=128 simple_bind=112 > > >> > sasl-secprops noanonymous > > >> > > > >> > access to dn.base="" by * read > > >> > access to dn.base="cn=Subschema" by * read > > >> > > > >> > backend hdb > > >> > database hdb > > >> > > > >> > overlay memberof > > >> > overlay smbk5pwd > > >> > overlay syncprov > > >> > > > >> > smbk5pwd-enable samba > > >> > smbk5pwd-enable krb5 > > >> > smbk5pwd-must-change 0 > > >> > > > >> > syncprov-checkpoint 100 10 > > >> > syncprov-sessionlog 200 > > >> > syncprov-nopresent TRUE > > >> > syncprov-reloadhint TRUE > > >> > > > >> > suffix "dc=iwu,dc=edu" > > >> > > > >> > rootdn "cn=admin,dc=iwu,dc=edu" > > >> > rootpw {redacted} > > >> > > > >> > authz-regexp "uidNumber=0\\\ > > >> > +gidNumber=.*,cn=peercred,cn=external,cn=auth" > > >> > "cn=ldapi,dc=iwu,dc=edu" > > >> > authz-regexp "gidNumber=.*\\\ > > >> > +uidNumber=0,cn=peercred,cn=external,cn=auth" > > >> > "cn=ldapi,dc=iwu,dc=edu" > > >> > > > >> > authz-regexp "uid=(.+),cn=.+,cn=auth" > "uid=$1,ou=People,dc=iwu,dc=edu" > > >> > > > >> > directory "/var/lib/ldap/" > > >> > > > >> > dbconfig set_cachesize 0 62914560 0 > > >> > dbconfig set_lk_max_objects 1500 > > >> > dbconfig set_lk_max_locks 1500 > > >> > dbconfig set_lk_max_lockers 1500 > > >> > > > >> > # Make sure to do a nightly slapcat > > >> > dbconfig set_flags DB_LOG_AUTOREMOVE > > >> > > > >> > index objectClass eq,pres > > >> > index default eq,sub,pres > > >> > index mail eq,sub,pres > > >> > index sn eq,sub,pres > > >> > index cn eq,sub,pres > > >> > index displayName eq,sub,pres > > >> > index gecos eq,sub,pres > > >> > index uid eq,sub,pres > > >> > index memberUid eq,sub,pres > > >> > index uidNumber eq,pres > > >> > index gidNumber eq,pres > > >> > index entryCSN eq,pres > > >> > index entryUUID eq,pres > > >> > index uniqueMember eq,pres > > >> > index userPassword eq,pres > > >> > index krb5PrincipalName eq,pres > > >> > index krb5PrincipalRealm eq,pres > > >> > index sambaDomainName eq,pres > > >> > index sambaSID eq,pres > > >> > index sambaPrimaryGroupSID eq,pres > > >> > index sambaSIDList eq,pres > > >> > > > >> > lastmod on > > >> > > > >> > checkpoint 256 15 > > >> > > > >> > password-hash {SSHA} > > >> > > > >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited > > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > > >> > limits dn.exact="cn=ldapi,dc=iwu,dc=edu" size.hard=unlimited > > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > > >> > limits dn.exact="cn=sambaadmin,dc=iwu,dc=edu" size.hard=unlimited > > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > > >> > limits dn.exact="cn=mirror,dc=iwu,dc=edu" size.hard=unlimited > > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > > >> > limits dn.exact="cn=freeradius,dc=iwu,dc=edu" size.hard=unlimited > > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > > >> > > > >> > access to dn.sub="dc=iwu,dc=edu" > > >> > by dn.exact="cn=ldapi,dc=iwu,dc=edu" write > > >> > by dn.exact="cn=sambaadmin,dc=iwu,dc=edu" write > > >> > by dn.exact="cn=mirror,dc=iwu,dc=edu" read > > >> > by dn.exact="cn=freeradius,dc=iwu,dc=edu" read > > >> > by * break > > >> > > > >> > access to dn.sub="dc=iwu,dc=edu" > > >> > > attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword,krb5Key > > >> > by anonymous auth > > >> > by self write > > >> > by dn.exact="cn=passwordmanager,dc=iwu,dc=edu" write > > >> > by users auth > > >> > by * break > > >> > > > >> > access to dn.exact="cn=ldapi,dc=iwu,dc=edu" by * none > > >> > access to dn.exact="cn=sambaadmin,dc=iwu,dc=edu" by * none > > >> > access to dn.exact="cn=mirror,dc=iwu,dc=edu" by * none > > >> > access to dn.exact="cn=freeradius,dc=iwu,dc=edu" by * none > > >> > access to dn.exact="cn=passwordmanager,dc=iwu,dc=edu" by * none > > >> > access to dn.exact="cn=admin,dc=iwu,dc=edu" by * none > > >> > > > >> > access to dn.regex="uid=.*\$,ou=People,dc=iwu,dc=edu" by self read > by * > > >> > none > > >> > access to dn.sub="ou=Computers,dc=iwu,dc=edu" by self read by * none > > >> > access to dn.sub="ou=Idmap,dc=iwu,dc=edu" by self read by * none > > >> > access to dn.exact="sambaDomainName=IWU.EDU,dc=iwu,dc=edu" by self > read > > >> > by * none > > >> > access to dn.exact="uid=Administrator,ou=People,dc=iwu,dc=edu" by > self > > >> > read by * none > > >> > access to dn.exact="uid=root,ou=People,dc=iwu,dc=edu" by self read > by * > > >> > none > > >> > > > >> > access to > > >> > dn.regex="krb5PrincipalName=.*(a)IWU.EDU,ou=People,dc=iwu,dc=edu" by > self > > >> > read by * none > > >> > > > >> > access to dn.sub="dc=iwu,dc=edu" > > >> > > attrs=telephoneNumber,mobileTelephoneNumber,homePostalAddress,streetAddress,physicalDeliveryOfficeName,roomNumber,preferredLanguage,localityName,postOfficeBox,postalCode,stateOrProvinceName > > >> > by self write > > >> > by users read > > >> > by anonymous none > > >> > by * break > > >> > > > >> > access to dn.sub="dc=iwu,dc=edu" > > >> > > attrs=krb5PrincipalName,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,krb5KeyVersionNumber > > >> > by self read > > >> > by anonymous none > > >> > by * break > > >> > > > >> > access to dn.sub="dc=iwu,dc=edu" > > >> > > attrs=sambaPrimaryGroupSID,sambaSID,sambaAlgorithmicRidBase,sambaNextRid > > >> > by * none > > >> > > > >> > access to dn.sub="dc=iwu,dc=edu" > > >> > > attrs=sambaPwdCanChange,sambaLogonTime,sambaLogoffTime,sambaAcctFlags,sambaPasswordHistory,sambaPwdLastSet,sambaGroupType,sambaPwdMustChange,sambaKickoffTime,sambaLockoutThreshold,sambaForceLogoff,sambaRefuseMachinePwdChange,sambaLockoutObservationWindow,sambaLockoutDuration,sambaMinPwdAge,sambaMaxPwdAge,sambaLogonToChgPwd,sambaPwdHistoryLength,sambaMinPwdLength > > >> > by self read > > >> > by anonymous none > > >> > by * break > > >> > > > >> > access to dn.sub="dc=iwu,dc=edu" by * read > > >> > > > >> > serverID 1 > > >> > > > >> > syncrepl rid=2 > > >> > provider=ldap://ldap2.iwu.edu/ > > >> > schemachecking=off > > >> > searchbase="dc=iwu,dc=edu" > > >> > scope=sub > > >> > type=refreshAndPersist > > >> > binddn="cn=mirror,dc=iwu,dc=edu" > > >> > credentials={redacted} > > >> > bindmethod=simple > > >> > starttls=yes > > >> > tls_cert=/etc/ldap/ssl/ldap.iwu.edu.crt > > >> > tls_key=/etc/ldap/ssl/ldap.iwu.edu.key > > >> > tls_cacert=/etc/ldap/ssl/IWU.crt > > >> > tls_reqcert=try > > >> > interval=00:00:00:30 > > >> > retry="15 +" > > >> > timeout=1 > > >> > timelimit=unlimited > > >> > sizelimit=unlimited > > >> > > > >> > mirrormode on > > >> > > > >> > ############################### > > >> > database monitor > > >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited > > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > > >> > > > >> > access to dn.exact="cn=Monitor" > > >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read > > >> > by * none > > >> > > > >> > access to dn.subtree="cn=Monitor" > > >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read > > >> > by * none > > >> > > > >> > > > >> >> > > >> >> On 22/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > > >> >> > Here is the quick and dirty what I am trying to do: > > >> >> > > > >> >> > ldap1 and ldap2 are supposed to be in MultiMaster. They are time > > >> >> > synced > > >> >> > to pool.ntp.org and each other (if they drift I would rather they > > >> >> > sorta > > >> >> > drift together, but pool should be keeping that in check). > > >> >> > > > >> >> > Right now I am just beating them up to see how 2.4.13 performs. > (So > > >> >> > far > > >> >> > VERY well, minus this little problem) > > >> >> > > > >> >> > I have a rather small ldif (41 entries) that just wont sync (I'm > > >> >> > starting small). Debug gives me > > >> >> > > > >> >> > ber_scanf fmt (m}) ber: > > >> >> > ber_dump: buf=0xb806f120 ptr=0xb806f137 end=0xb806f175 len=62 > > >> >> > 0000: 00 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 > > >> >> > 30 .<rid=001,sid=00 > > >> >> > 0010: 32 2c 63 73 6e 3d 32 30 30 38 31 32 32 32 31 37 > > >> >> > 2,csn=2008122217 > > >> >> > 0020: 34 37 32 31 2e 38 35 35 39 30 34 5a 23 30 30 30 > > >> >> > 4721.855904Z#000 > > >> >> > 0030: 30 30 30 23 30 30 31 23 30 30 30 30 30 30 > > >> >> > 000#001#000000 > > >> >> > do_syncrep2: > > >> >> > > cookie=rid=001,sid=002,csn=20081222174721.855904Z#000000#001#000000 > > >> >> > do_syncrep2: rid=001 CSN too old, ignoring > > >> >> > 20081222174721.855904Z#000000#001#000000 > > >> >> > ldap_msgfree > > >> >> > > > >> >> > I am not exactly sure how it gotten to be "too old." The ldif I > am > > >> >> > importing is not the result of a slapcat or anything that would > > >> >> > preserve > > >> >> > the CSN or UUID attributes (not that syncrepl uses UUID). I am > > >> >> > loading > > >> >> > one single file with ldapadd which, in my understanding, sets up > the > > >> >> > CSN > > >> >> > and wouldn't let me import one anyway. > > >> >> > > > >> >> > Each server has no entries until I load the one, so there > shouldn't > > >> >> > be > > >> >> > any weird stale CSNs causing this. They are "sync'ed" almost > > >> >> > instantly > > >> >> > after the one system is loaded - I just don't have everything. > > >> >> > > > >> >> > After a sync: > > >> >> > ldap1 - slapcat |grep dn: |wc -l = 41 > > >> >> > ldap2 - slapcat |grep dn: |wc -l = 18 > > >> >> > > > >> >> > Right now I can get them in sync with a slapcat/slapadd, but when > the > > >> >> > go > > >> >> > into production I wont be able to say for certain which one is > > >> >> > authoritative. That is the purpose of multi-master.... > > >> >> > > > >> >> > OpenLDAP 2.4.13, built by me (passed all tests) on Ubuntu Linux > 32 > > >> >> > bit > > >> >> > > > >> >> > Any ideas as to what I can do to stop this from happening? > > >> >> > > > >> >> > Pat > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> > > > >> > > > >> > > > > > > > > > > > -- > Sent from my mobile device > > http://www.suretecsystems.com/services/openldap/ > > > > > Adrien Futschik > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ Adrien Futschik

14 years, 9 months

2
1
0 / 0

Re: Fwd: CSN too old, ignoring - and therefore not syncing

by Adrien Futschik

I'm facing a similar problem. I'm testing N-way multimaster replication with OpenLDAP 2.4.13. I'm able to successfully import data into an instance and have my two masters to sync correctly but then when I try to add a new entry in one of the two masters, I'm getting strange messages : let's say we have m1 & m2 (m1 & m2 are on the same server): I initial import data into m1, it is successfully imported into m2 (at least it looks like it). Then I'm trying to add an entry on m2 (cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr). I'm getting strange message on m1 & m2 : m1 log :(repetitively) [...] Entry ou=administrateurs,o=gazdefrance,c=fr CSN 20081224125950.481561Z#000000#001#000000 older or equal to ctx 20081224125950.481561Z#000000#001#000000 Entry cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr changed by peer, ignored syncprov_search_response: cookie=rid=004,sid=002,csn=20081224125950.481561Z#000000#001#000000;20081224130148.522455Z#000000#002#000000 do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT [...] m2 log : (repetitively) [...] master where I added an entry : do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: cookie=rid=004,sid=002,csn=20081224125950.481561Z#000000#001#000000;20081224130148.522455Z#000000#002#000000 [...] Is this a bug ? Am-I doing something wrong ? If I add the same entry to m1 and not m2 I get the following messages : on m2 : syncrepl_entry: rid=004 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=004 be_search (0) syncrepl_entry: rid=004 cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr <= bdb_equality_candidates: (entryCSN) not indexed <= bdb_inequality_candidates: (entryCSN) not indexed <= bdb_inequality_candidates: (entryCSN) not indexed syncprov_search_response: cookie=rid=005,sid=001,csn=20081224132158.749532Z#000000#001#000000 syncrepl_entry: rid=004 be_add (0) do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: cookie=rid=004,sid=002,csn=20081224132238.790862Z#000000#001#000000 <= bdb_inequality_candidates: (entryCSN) not indexed nonpresent_callback: rid=004 present UUID 96268508-6609-102d-9d8e-9742e72db399, dn c=fr nonpresent_callback: rid=004 present UUID 962af700-6609-102d-9d8f-9742e72db399, dn o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962bd698-6609-102d-9d90-9742e72db399, dn ou=personnes,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962c00b4-6609-102d-9d91-9742e72db399, dn ou=appli,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962c2634-6609-102d-9d92-9742e72db399, dn ou=groupes,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962ca492-6609-102d-9d93-9742e72db399, dn ou=administrateurs,o=edfgdf,c=fr nonpresent_callback: rid=004 present UUID 962cce90-6609-102d-9d94-9742e72db399, dn o=edf,c=fr nonpresent_callback: rid=004 present UUID 962d7138-6609-102d-9d95-9742e72db399, dn ou=personnes,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962d96f4-6609-102d-9d96-9742e72db399, dn ou=appli,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962deafa-6609-102d-9d97-9742e72db399, dn ou=groupes,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962ef026-6609-102d-9d98-9742e72db399, dn ou=administrateurs,o=edf,c=fr nonpresent_callback: rid=004 present UUID 962f156a-6609-102d-9d99-9742e72db399, dn o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 962fca8c-6609-102d-9d9a-9742e72db399, dn ou=personnes,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 962fef76-6609-102d-9d9b-9742e72db399, dn ou=appli,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 9630106e-6609-102d-9d9c-9742e72db399, dn ou=groupes,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID 9630bfa0-6609-102d-9d9d-9742e72db399, dn ou=administrateurs,o=gazdefrance,c=fr nonpresent_callback: rid=004 present UUID ae0e93d6-6609-102d-9d9e-9742e72db399, dn cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf,c=fr slap_queue_csn: queing 0x843fef0 20081224132238.790862Z#000000#001#000000 slap_graduate_commit_csn: removing 0x83d6410 20081224132238.790862Z#000000#001#000000 on m1 : slap_queue_csn: queing 0x1df3860 20081224132238.790862Z#000000#001#000000 slap_graduate_commit_csn: removing 0x9703700 20081224132238.790862Z#000000#001#000000 <= bdb_equality_candidates: (entryCSN) not indexed <= bdb_inequality_candidates: (entryCSN) not indexed Entry ou=administrateurs,o=gazdefrance,c=fr CSN 20081224132158.749532Z#000000#001#000000 older or equal to ctx 20081224132158.749532Z#000000#001#000000 syncprov_search_response: cookie=rid=004,sid=002,csn=20081224132238.790862Z#000000#001#000000 do_syncrep2: rid=005 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT do_syncrep2: cookie=rid=005,sid=001,csn=20081224132158.749532Z#000000#001#000000 Here is the entry I'm adding : dn: cn=adrien-externe.futschik(a)edfgdf.fr,ou=personnes,o=edfgdf, c=fr objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgPerson objectclass: ditPerson cn: adrien-externe.futschik(a)edfgdf.fr sn: Futschik givenName: Adrien uid: adrien-externe.futschik(a)edfgdf.fr mail: adrien-externe.futschik(a)edfgdf.fr telephonenumber: 0123456789 userpassword: {SSHA}GuU6CMRoOxp9EA1ANafzuRUXADKlBA0r allowedServices: appli20 pretty simple isn't it ? What's going wrong ? Adrien ======================================== Message date : Dec 23 2008, 07:39 PM From : "Gavin Henry" <gavin.henry(a)gmail.com> To : openldap-technical(a)openldap.org Copy to : Subject : Fwd: CSN too old, ignoring - and therefore not syncing ---------- Forwarded message ---------- From: Pat Riehecky <prieheck(a)iwu.edu> Date: Tue, 23 Dec 2008 12:34:33 -0600 Subject: Re: CSN too old, ignoring - and therefore not syncing To: Gavin Henry <gavin.henry(a)gmail.com> On Tue, 2008-12-23 at 18:28 +0000, Gavin Henry wrote: > Where did you read that those were needed anyway? If it was the admin > guide then I need to fix it ;-) > > Gavin. I have no idea where I found those at... I know it wasn't the (recent) admin guide. It may have been from around the 2.4.8 release, but that is long gone... Pat > > On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > > On Tue, 2008-12-23 at 15:55 +0000, Gavin Henry wrote: > >> Try dropping nopresent and reloadhint relating to ITS5669. You only > >> need these two syncprov settings on an accesslog db. > >> > >> Gavin. > > > > Thanks, that did the job! > > > > Pat > > > >> > >> On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > >> > On Tue, 2008-12-23 at 11:45 +0000, Gavin Henry wrote: > >> >> Can you post your config somewhere? > >> > > >> > > >> > allow bind_v2 > >> > > >> > include /etc/ldap/schema/core.schema > >> > include /etc/ldap/schema/cosine.schema > >> > include /etc/ldap/schema/nis.schema > >> > include /etc/ldap/schema/inetorgperson.schema > >> > include /etc/ldap/schema/samba.schema > >> > include /etc/ldap/schema/eduperson-200412.schema > >> > include /etc/ldap/schema/hdb.schema > >> > include /etc/ldap/schema/IWU.schema > >> > > >> > pidfile /var/run/slapd/slapd.pid > >> > argsfile /var/run/slapd/slapd.args > >> > > >> > modulepath /usr/lib/ldap > >> > moduleload back_hdb > >> > moduleload back_monitor > >> > moduleload memberof > >> > moduleload syncprov > >> > moduleload smbk5pwd > >> > > >> > tool-threads 2 > >> > sizelimit 500 > >> > idletimeout 7200 > >> > > >> > TLSCACertificateFile /etc/ldap/ssl/IWU.crt > >> > TLSCertificateFile /etc/ldap/ssl/ldap.iwu.edu.crt > >> > TLSCertificateKeyFile /etc/ldap/ssl/ldap.iwu.edu.key > >> > TLSVerifyClient allow > >> > > >> > localSSF 160 > >> > security ssf=1 update_ssf=128 simple_bind=112 > >> > sasl-secprops noanonymous > >> > > >> > access to dn.base="" by * read > >> > access to dn.base="cn=Subschema" by * read > >> > > >> > backend hdb > >> > database hdb > >> > > >> > overlay memberof > >> > overlay smbk5pwd > >> > overlay syncprov > >> > > >> > smbk5pwd-enable samba > >> > smbk5pwd-enable krb5 > >> > smbk5pwd-must-change 0 > >> > > >> > syncprov-checkpoint 100 10 > >> > syncprov-sessionlog 200 > >> > syncprov-nopresent TRUE > >> > syncprov-reloadhint TRUE > >> > > >> > suffix "dc=iwu,dc=edu" > >> > > >> > rootdn "cn=admin,dc=iwu,dc=edu" > >> > rootpw {redacted} > >> > > >> > authz-regexp "uidNumber=0\\\ > >> > +gidNumber=.*,cn=peercred,cn=external,cn=auth" > >> > "cn=ldapi,dc=iwu,dc=edu" > >> > authz-regexp "gidNumber=.*\\\ > >> > +uidNumber=0,cn=peercred,cn=external,cn=auth" > >> > "cn=ldapi,dc=iwu,dc=edu" > >> > > >> > authz-regexp "uid=(.+),cn=.+,cn=auth" "uid=$1,ou=People,dc=iwu,dc=edu" > >> > > >> > directory "/var/lib/ldap/" > >> > > >> > dbconfig set_cachesize 0 62914560 0 > >> > dbconfig set_lk_max_objects 1500 > >> > dbconfig set_lk_max_locks 1500 > >> > dbconfig set_lk_max_lockers 1500 > >> > > >> > # Make sure to do a nightly slapcat > >> > dbconfig set_flags DB_LOG_AUTOREMOVE > >> > > >> > index objectClass eq,pres > >> > index default eq,sub,pres > >> > index mail eq,sub,pres > >> > index sn eq,sub,pres > >> > index cn eq,sub,pres > >> > index displayName eq,sub,pres > >> > index gecos eq,sub,pres > >> > index uid eq,sub,pres > >> > index memberUid eq,sub,pres > >> > index uidNumber eq,pres > >> > index gidNumber eq,pres > >> > index entryCSN eq,pres > >> > index entryUUID eq,pres > >> > index uniqueMember eq,pres > >> > index userPassword eq,pres > >> > index krb5PrincipalName eq,pres > >> > index krb5PrincipalRealm eq,pres > >> > index sambaDomainName eq,pres > >> > index sambaSID eq,pres > >> > index sambaPrimaryGroupSID eq,pres > >> > index sambaSIDList eq,pres > >> > > >> > lastmod on > >> > > >> > checkpoint 256 15 > >> > > >> > password-hash {SSHA} > >> > > >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=ldapi,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=sambaadmin,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=mirror,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=freeradius,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > by dn.exact="cn=ldapi,dc=iwu,dc=edu" write > >> > by dn.exact="cn=sambaadmin,dc=iwu,dc=edu" write > >> > by dn.exact="cn=mirror,dc=iwu,dc=edu" read > >> > by dn.exact="cn=freeradius,dc=iwu,dc=edu" read > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword,krb5Key > >> > by anonymous auth > >> > by self write > >> > by dn.exact="cn=passwordmanager,dc=iwu,dc=edu" write > >> > by users auth > >> > by * break > >> > > >> > access to dn.exact="cn=ldapi,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=sambaadmin,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=mirror,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=freeradius,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=passwordmanager,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=admin,dc=iwu,dc=edu" by * none > >> > > >> > access to dn.regex="uid=.*\$,ou=People,dc=iwu,dc=edu" by self read by * > >> > none > >> > access to dn.sub="ou=Computers,dc=iwu,dc=edu" by self read by * none > >> > access to dn.sub="ou=Idmap,dc=iwu,dc=edu" by self read by * none > >> > access to dn.exact="sambaDomainName=IWU.EDU,dc=iwu,dc=edu" by self read > >> > by * none > >> > access to dn.exact="uid=Administrator,ou=People,dc=iwu,dc=edu" by self > >> > read by * none > >> > access to dn.exact="uid=root,ou=People,dc=iwu,dc=edu" by self read by * > >> > none > >> > > >> > access to > >> > dn.regex="krb5PrincipalName=.*(a)IWU.EDU,ou=People,dc=iwu,dc=edu" by self > >> > read by * none > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=telephoneNumber,mobileTelephoneNumber,homePostalAddress,streetAddress,physicalDeliveryOfficeName,roomNumber,preferredLanguage,localityName,postOfficeBox,postalCode,stateOrProvinceName > >> > by self write > >> > by users read > >> > by anonymous none > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=krb5PrincipalName,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,krb5KeyVersionNumber > >> > by self read > >> > by anonymous none > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=sambaPrimaryGroupSID,sambaSID,sambaAlgorithmicRidBase,sambaNextRid > >> > by * none > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=sambaPwdCanChange,sambaLogonTime,sambaLogoffTime,sambaAcctFlags,sambaPasswordHistory,sambaPwdLastSet,sambaGroupType,sambaPwdMustChange,sambaKickoffTime,sambaLockoutThreshold,sambaForceLogoff,sambaRefuseMachinePwdChange,sambaLockoutObservationWindow,sambaLockoutDuration,sambaMinPwdAge,sambaMaxPwdAge,sambaLogonToChgPwd,sambaPwdHistoryLength,sambaMinPwdLength > >> > by self read > >> > by anonymous none > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" by * read > >> > > >> > serverID 1 > >> > > >> > syncrepl rid=2 > >> > provider=ldap://ldap2.iwu.edu/ > >> > schemachecking=off > >> > searchbase="dc=iwu,dc=edu" > >> > scope=sub > >> > type=refreshAndPersist > >> > binddn="cn=mirror,dc=iwu,dc=edu" > >> > credentials={redacted} > >> > bindmethod=simple > >> > starttls=yes > >> > tls_cert=/etc/ldap/ssl/ldap.iwu.edu.crt > >> > tls_key=/etc/ldap/ssl/ldap.iwu.edu.key > >> > tls_cacert=/etc/ldap/ssl/IWU.crt > >> > tls_reqcert=try > >> > interval=00:00:00:30 > >> > retry="15 +" > >> > timeout=1 > >> > timelimit=unlimited > >> > sizelimit=unlimited > >> > > >> > mirrormode on > >> > > >> > ############################### > >> > database monitor > >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > > >> > access to dn.exact="cn=Monitor" > >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read > >> > by * none > >> > > >> > access to dn.subtree="cn=Monitor" > >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read > >> > by * none > >> > > >> > > >> >> > >> >> On 22/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > >> >> > Here is the quick and dirty what I am trying to do: > >> >> > > >> >> > ldap1 and ldap2 are supposed to be in MultiMaster. They are time > >> >> > synced > >> >> > to pool.ntp.org and each other (if they drift I would rather they > >> >> > sorta > >> >> > drift together, but pool should be keeping that in check). > >> >> > > >> >> > Right now I am just beating them up to see how 2.4.13 performs. (So > >> >> > far > >> >> > VERY well, minus this little problem) > >> >> > > >> >> > I have a rather small ldif (41 entries) that just wont sync (I'm > >> >> > starting small). Debug gives me > >> >> > > >> >> > ber_scanf fmt (m}) ber: > >> >> > ber_dump: buf=0xb806f120 ptr=0xb806f137 end=0xb806f175 len=62 > >> >> > 0000: 00 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 > >> >> > 30 .<rid=001,sid=00 > >> >> > 0010: 32 2c 63 73 6e 3d 32 30 30 38 31 32 32 32 31 37 > >> >> > 2,csn=2008122217 > >> >> > 0020: 34 37 32 31 2e 38 35 35 39 30 34 5a 23 30 30 30 > >> >> > 4721.855904Z#000 > >> >> > 0030: 30 30 30 23 30 30 31 23 30 30 30 30 30 30 > >> >> > 000#001#000000 > >> >> > do_syncrep2: > >> >> > cookie=rid=001,sid=002,csn=20081222174721.855904Z#000000#001#000000 > >> >> > do_syncrep2: rid=001 CSN too old, ignoring > >> >> > 20081222174721.855904Z#000000#001#000000 > >> >> > ldap_msgfree > >> >> > > >> >> > I am not exactly sure how it gotten to be "too old." The ldif I am > >> >> > importing is not the result of a slapcat or anything that would > >> >> > preserve > >> >> > the CSN or UUID attributes (not that syncrepl uses UUID). I am > >> >> > loading > >> >> > one single file with ldapadd which, in my understanding, sets up the > >> >> > CSN > >> >> > and wouldn't let me import one anyway. > >> >> > > >> >> > Each server has no entries until I load the one, so there shouldn't > >> >> > be > >> >> > any weird stale CSNs causing this. They are "sync'ed" almost > >> >> > instantly > >> >> > after the one system is loaded - I just don't have everything. > >> >> > > >> >> > After a sync: > >> >> > ldap1 - slapcat |grep dn: |wc -l = 41 > >> >> > ldap2 - slapcat |grep dn: |wc -l = 18 > >> >> > > >> >> > Right now I can get them in sync with a slapcat/slapadd, but when the > >> >> > go > >> >> > into production I wont be able to say for certain which one is > >> >> > authoritative. That is the purpose of multi-master.... > >> >> > > >> >> > OpenLDAP 2.4.13, built by me (passed all tests) on Ubuntu Linux 32 > >> >> > bit > >> >> > > >> >> > Any ideas as to what I can do to stop this from happening? > >> >> > > >> >> > Pat > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ Adrien Futschik

14 years, 9 months

2
1
0 / 0

Different shells ¿how to workaround?

by Jordi Espasa Clofent

Hi all, I'm just learning OpenLDAP; I'm hope it isn't a silly question. I've mounted a OpenLDAP (version 2.4 in a FreeBSD 7.x platform) as account authentication server and all works fine. The clients are FreeBSD and GNU/Linux Debian. One problem I've found is related to loginShell field in posixAccount schema. It's because of when I was setting up the servers, I've configured /bin/csh as the default shell for the users It's ok in FreeBSD clients (csh exists in default instalation), but you get an error when you try to authenticate a Debian client. ¿Why? Simple, the default shell in Debian is /bin/bash, not the defined /bin/csh. Currently, do you have two options to workaround this issue: * install csh in Debian clients and assure that the binary path is /bin/csh * make a symlink /bin/csh which point to /bin/bash At present, I've chosen the second option. ¿Is correct this workaround or maybe I don't know some other obvious method to get it? -- Thanks, Jordi Espasa Clofent

14 years, 9 months

2
1
0 / 0

Fwd: CSN too old, ignoring - and therefore not syncing

by Gavin Henry

---------- Forwarded message ---------- From: Pat Riehecky <prieheck(a)iwu.edu> Date: Tue, 23 Dec 2008 12:34:33 -0600 Subject: Re: CSN too old, ignoring - and therefore not syncing To: Gavin Henry <gavin.henry(a)gmail.com> On Tue, 2008-12-23 at 18:28 +0000, Gavin Henry wrote: > Where did you read that those were needed anyway? If it was the admin > guide then I need to fix it ;-) > > Gavin. I have no idea where I found those at... I know it wasn't the (recent) admin guide. It may have been from around the 2.4.8 release, but that is long gone... Pat > > On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > > On Tue, 2008-12-23 at 15:55 +0000, Gavin Henry wrote: > >> Try dropping nopresent and reloadhint relating to ITS5669. You only > >> need these two syncprov settings on an accesslog db. > >> > >> Gavin. > > > > Thanks, that did the job! > > > > Pat > > > >> > >> On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > >> > On Tue, 2008-12-23 at 11:45 +0000, Gavin Henry wrote: > >> >> Can you post your config somewhere? > >> > > >> > > >> > allow bind_v2 > >> > > >> > include /etc/ldap/schema/core.schema > >> > include /etc/ldap/schema/cosine.schema > >> > include /etc/ldap/schema/nis.schema > >> > include /etc/ldap/schema/inetorgperson.schema > >> > include /etc/ldap/schema/samba.schema > >> > include /etc/ldap/schema/eduperson-200412.schema > >> > include /etc/ldap/schema/hdb.schema > >> > include /etc/ldap/schema/IWU.schema > >> > > >> > pidfile /var/run/slapd/slapd.pid > >> > argsfile /var/run/slapd/slapd.args > >> > > >> > modulepath /usr/lib/ldap > >> > moduleload back_hdb > >> > moduleload back_monitor > >> > moduleload memberof > >> > moduleload syncprov > >> > moduleload smbk5pwd > >> > > >> > tool-threads 2 > >> > sizelimit 500 > >> > idletimeout 7200 > >> > > >> > TLSCACertificateFile /etc/ldap/ssl/IWU.crt > >> > TLSCertificateFile /etc/ldap/ssl/ldap.iwu.edu.crt > >> > TLSCertificateKeyFile /etc/ldap/ssl/ldap.iwu.edu.key > >> > TLSVerifyClient allow > >> > > >> > localSSF 160 > >> > security ssf=1 update_ssf=128 simple_bind=112 > >> > sasl-secprops noanonymous > >> > > >> > access to dn.base="" by * read > >> > access to dn.base="cn=Subschema" by * read > >> > > >> > backend hdb > >> > database hdb > >> > > >> > overlay memberof > >> > overlay smbk5pwd > >> > overlay syncprov > >> > > >> > smbk5pwd-enable samba > >> > smbk5pwd-enable krb5 > >> > smbk5pwd-must-change 0 > >> > > >> > syncprov-checkpoint 100 10 > >> > syncprov-sessionlog 200 > >> > syncprov-nopresent TRUE > >> > syncprov-reloadhint TRUE > >> > > >> > suffix "dc=iwu,dc=edu" > >> > > >> > rootdn "cn=admin,dc=iwu,dc=edu" > >> > rootpw {redacted} > >> > > >> > authz-regexp "uidNumber=0\\\ > >> > +gidNumber=.*,cn=peercred,cn=external,cn=auth" > >> > "cn=ldapi,dc=iwu,dc=edu" > >> > authz-regexp "gidNumber=.*\\\ > >> > +uidNumber=0,cn=peercred,cn=external,cn=auth" > >> > "cn=ldapi,dc=iwu,dc=edu" > >> > > >> > authz-regexp "uid=(.+),cn=.+,cn=auth" "uid=$1,ou=People,dc=iwu,dc=edu" > >> > > >> > directory "/var/lib/ldap/" > >> > > >> > dbconfig set_cachesize 0 62914560 0 > >> > dbconfig set_lk_max_objects 1500 > >> > dbconfig set_lk_max_locks 1500 > >> > dbconfig set_lk_max_lockers 1500 > >> > > >> > # Make sure to do a nightly slapcat > >> > dbconfig set_flags DB_LOG_AUTOREMOVE > >> > > >> > index objectClass eq,pres > >> > index default eq,sub,pres > >> > index mail eq,sub,pres > >> > index sn eq,sub,pres > >> > index cn eq,sub,pres > >> > index displayName eq,sub,pres > >> > index gecos eq,sub,pres > >> > index uid eq,sub,pres > >> > index memberUid eq,sub,pres > >> > index uidNumber eq,pres > >> > index gidNumber eq,pres > >> > index entryCSN eq,pres > >> > index entryUUID eq,pres > >> > index uniqueMember eq,pres > >> > index userPassword eq,pres > >> > index krb5PrincipalName eq,pres > >> > index krb5PrincipalRealm eq,pres > >> > index sambaDomainName eq,pres > >> > index sambaSID eq,pres > >> > index sambaPrimaryGroupSID eq,pres > >> > index sambaSIDList eq,pres > >> > > >> > lastmod on > >> > > >> > checkpoint 256 15 > >> > > >> > password-hash {SSHA} > >> > > >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=ldapi,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=sambaadmin,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=mirror,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > limits dn.exact="cn=freeradius,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > by dn.exact="cn=ldapi,dc=iwu,dc=edu" write > >> > by dn.exact="cn=sambaadmin,dc=iwu,dc=edu" write > >> > by dn.exact="cn=mirror,dc=iwu,dc=edu" read > >> > by dn.exact="cn=freeradius,dc=iwu,dc=edu" read > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword,krb5Key > >> > by anonymous auth > >> > by self write > >> > by dn.exact="cn=passwordmanager,dc=iwu,dc=edu" write > >> > by users auth > >> > by * break > >> > > >> > access to dn.exact="cn=ldapi,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=sambaadmin,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=mirror,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=freeradius,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=passwordmanager,dc=iwu,dc=edu" by * none > >> > access to dn.exact="cn=admin,dc=iwu,dc=edu" by * none > >> > > >> > access to dn.regex="uid=.*\$,ou=People,dc=iwu,dc=edu" by self read by * > >> > none > >> > access to dn.sub="ou=Computers,dc=iwu,dc=edu" by self read by * none > >> > access to dn.sub="ou=Idmap,dc=iwu,dc=edu" by self read by * none > >> > access to dn.exact="sambaDomainName=IWU.EDU,dc=iwu,dc=edu" by self read > >> > by * none > >> > access to dn.exact="uid=Administrator,ou=People,dc=iwu,dc=edu" by self > >> > read by * none > >> > access to dn.exact="uid=root,ou=People,dc=iwu,dc=edu" by self read by * > >> > none > >> > > >> > access to > >> > dn.regex="krb5PrincipalName=.*(a)IWU.EDU,ou=People,dc=iwu,dc=edu" by self > >> > read by * none > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=telephoneNumber,mobileTelephoneNumber,homePostalAddress,streetAddress,physicalDeliveryOfficeName,roomNumber,preferredLanguage,localityName,postOfficeBox,postalCode,stateOrProvinceName > >> > by self write > >> > by users read > >> > by anonymous none > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=krb5PrincipalName,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,krb5KeyVersionNumber > >> > by self read > >> > by anonymous none > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=sambaPrimaryGroupSID,sambaSID,sambaAlgorithmicRidBase,sambaNextRid > >> > by * none > >> > > >> > access to dn.sub="dc=iwu,dc=edu" > >> > attrs=sambaPwdCanChange,sambaLogonTime,sambaLogoffTime,sambaAcctFlags,sambaPasswordHistory,sambaPwdLastSet,sambaGroupType,sambaPwdMustChange,sambaKickoffTime,sambaLockoutThreshold,sambaForceLogoff,sambaRefuseMachinePwdChange,sambaLockoutObservationWindow,sambaLockoutDuration,sambaMinPwdAge,sambaMaxPwdAge,sambaLogonToChgPwd,sambaPwdHistoryLength,sambaMinPwdLength > >> > by self read > >> > by anonymous none > >> > by * break > >> > > >> > access to dn.sub="dc=iwu,dc=edu" by * read > >> > > >> > serverID 1 > >> > > >> > syncrepl rid=2 > >> > provider=ldap://ldap2.iwu.edu/ > >> > schemachecking=off > >> > searchbase="dc=iwu,dc=edu" > >> > scope=sub > >> > type=refreshAndPersist > >> > binddn="cn=mirror,dc=iwu,dc=edu" > >> > credentials={redacted} > >> > bindmethod=simple > >> > starttls=yes > >> > tls_cert=/etc/ldap/ssl/ldap.iwu.edu.crt > >> > tls_key=/etc/ldap/ssl/ldap.iwu.edu.key > >> > tls_cacert=/etc/ldap/ssl/IWU.crt > >> > tls_reqcert=try > >> > interval=00:00:00:30 > >> > retry="15 +" > >> > timeout=1 > >> > timelimit=unlimited > >> > sizelimit=unlimited > >> > > >> > mirrormode on > >> > > >> > ############################### > >> > database monitor > >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited > >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited > >> > > >> > access to dn.exact="cn=Monitor" > >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read > >> > by * none > >> > > >> > access to dn.subtree="cn=Monitor" > >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read > >> > by * none > >> > > >> > > >> >> > >> >> On 22/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > >> >> > Here is the quick and dirty what I am trying to do: > >> >> > > >> >> > ldap1 and ldap2 are supposed to be in MultiMaster. They are time > >> >> > synced > >> >> > to pool.ntp.org and each other (if they drift I would rather they > >> >> > sorta > >> >> > drift together, but pool should be keeping that in check). > >> >> > > >> >> > Right now I am just beating them up to see how 2.4.13 performs. (So > >> >> > far > >> >> > VERY well, minus this little problem) > >> >> > > >> >> > I have a rather small ldif (41 entries) that just wont sync (I'm > >> >> > starting small). Debug gives me > >> >> > > >> >> > ber_scanf fmt (m}) ber: > >> >> > ber_dump: buf=0xb806f120 ptr=0xb806f137 end=0xb806f175 len=62 > >> >> > 0000: 00 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 > >> >> > 30 .<rid=001,sid=00 > >> >> > 0010: 32 2c 63 73 6e 3d 32 30 30 38 31 32 32 32 31 37 > >> >> > 2,csn=2008122217 > >> >> > 0020: 34 37 32 31 2e 38 35 35 39 30 34 5a 23 30 30 30 > >> >> > 4721.855904Z#000 > >> >> > 0030: 30 30 30 23 30 30 31 23 30 30 30 30 30 30 > >> >> > 000#001#000000 > >> >> > do_syncrep2: > >> >> > cookie=rid=001,sid=002,csn=20081222174721.855904Z#000000#001#000000 > >> >> > do_syncrep2: rid=001 CSN too old, ignoring > >> >> > 20081222174721.855904Z#000000#001#000000 > >> >> > ldap_msgfree > >> >> > > >> >> > I am not exactly sure how it gotten to be "too old." The ldif I am > >> >> > importing is not the result of a slapcat or anything that would > >> >> > preserve > >> >> > the CSN or UUID attributes (not that syncrepl uses UUID). I am > >> >> > loading > >> >> > one single file with ldapadd which, in my understanding, sets up the > >> >> > CSN > >> >> > and wouldn't let me import one anyway. > >> >> > > >> >> > Each server has no entries until I load the one, so there shouldn't > >> >> > be > >> >> > any weird stale CSNs causing this. They are "sync'ed" almost > >> >> > instantly > >> >> > after the one system is loaded - I just don't have everything. > >> >> > > >> >> > After a sync: > >> >> > ldap1 - slapcat |grep dn: |wc -l = 41 > >> >> > ldap2 - slapcat |grep dn: |wc -l = 18 > >> >> > > >> >> > Right now I can get them in sync with a slapcat/slapadd, but when the > >> >> > go > >> >> > into production I wont be able to say for certain which one is > >> >> > authoritative. That is the purpose of multi-master.... > >> >> > > >> >> > OpenLDAP 2.4.13, built by me (passed all tests) on Ubuntu Linux 32 > >> >> > bit > >> >> > > >> >> > Any ideas as to what I can do to stop this from happening? > >> >> > > >> >> > Pat > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

14 years, 9 months

1
0
0 / 0

Re: CSN too old, ignoring - and therefore not syncing

by Gavin Henry

Ok, thanks. On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: > On Tue, 2008-12-23 at 18:28 +0000, Gavin Henry wrote: >> Where did you read that those were needed anyway? If it was the admin >> guide then I need to fix it ;-) >> >> Gavin. > > I have no idea where I found those at... I know it wasn't the (recent) > admin guide. It may have been from around the 2.4.8 release, but that > is long gone... > > Pat > >> >> On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: >> > On Tue, 2008-12-23 at 15:55 +0000, Gavin Henry wrote: >> >> Try dropping nopresent and reloadhint relating to ITS5669. You only >> >> need these two syncprov settings on an accesslog db. >> >> >> >> Gavin. >> > >> > Thanks, that did the job! >> > >> > Pat >> > >> >> >> >> On 23/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: >> >> > On Tue, 2008-12-23 at 11:45 +0000, Gavin Henry wrote: >> >> >> Can you post your config somewhere? >> >> > >> >> > >> >> > allow bind_v2 >> >> > >> >> > include /etc/ldap/schema/core.schema >> >> > include /etc/ldap/schema/cosine.schema >> >> > include /etc/ldap/schema/nis.schema >> >> > include /etc/ldap/schema/inetorgperson.schema >> >> > include /etc/ldap/schema/samba.schema >> >> > include /etc/ldap/schema/eduperson-200412.schema >> >> > include /etc/ldap/schema/hdb.schema >> >> > include /etc/ldap/schema/IWU.schema >> >> > >> >> > pidfile /var/run/slapd/slapd.pid >> >> > argsfile /var/run/slapd/slapd.args >> >> > >> >> > modulepath /usr/lib/ldap >> >> > moduleload back_hdb >> >> > moduleload back_monitor >> >> > moduleload memberof >> >> > moduleload syncprov >> >> > moduleload smbk5pwd >> >> > >> >> > tool-threads 2 >> >> > sizelimit 500 >> >> > idletimeout 7200 >> >> > >> >> > TLSCACertificateFile /etc/ldap/ssl/IWU.crt >> >> > TLSCertificateFile /etc/ldap/ssl/ldap.iwu.edu.crt >> >> > TLSCertificateKeyFile /etc/ldap/ssl/ldap.iwu.edu.key >> >> > TLSVerifyClient allow >> >> > >> >> > localSSF 160 >> >> > security ssf=1 update_ssf=128 simple_bind=112 >> >> > sasl-secprops noanonymous >> >> > >> >> > access to dn.base="" by * read >> >> > access to dn.base="cn=Subschema" by * read >> >> > >> >> > backend hdb >> >> > database hdb >> >> > >> >> > overlay memberof >> >> > overlay smbk5pwd >> >> > overlay syncprov >> >> > >> >> > smbk5pwd-enable samba >> >> > smbk5pwd-enable krb5 >> >> > smbk5pwd-must-change 0 >> >> > >> >> > syncprov-checkpoint 100 10 >> >> > syncprov-sessionlog 200 >> >> > syncprov-nopresent TRUE >> >> > syncprov-reloadhint TRUE >> >> > >> >> > suffix "dc=iwu,dc=edu" >> >> > >> >> > rootdn "cn=admin,dc=iwu,dc=edu" >> >> > rootpw {redacted} >> >> > >> >> > authz-regexp "uidNumber=0\\\ >> >> > +gidNumber=.*,cn=peercred,cn=external,cn=auth" >> >> > "cn=ldapi,dc=iwu,dc=edu" >> >> > authz-regexp "gidNumber=.*\\\ >> >> > +uidNumber=0,cn=peercred,cn=external,cn=auth" >> >> > "cn=ldapi,dc=iwu,dc=edu" >> >> > >> >> > authz-regexp "uid=(.+),cn=.+,cn=auth" >> >> > "uid=$1,ou=People,dc=iwu,dc=edu" >> >> > >> >> > directory "/var/lib/ldap/" >> >> > >> >> > dbconfig set_cachesize 0 62914560 0 >> >> > dbconfig set_lk_max_objects 1500 >> >> > dbconfig set_lk_max_locks 1500 >> >> > dbconfig set_lk_max_lockers 1500 >> >> > >> >> > # Make sure to do a nightly slapcat >> >> > dbconfig set_flags DB_LOG_AUTOREMOVE >> >> > >> >> > index objectClass eq,pres >> >> > index default eq,sub,pres >> >> > index mail eq,sub,pres >> >> > index sn eq,sub,pres >> >> > index cn eq,sub,pres >> >> > index displayName eq,sub,pres >> >> > index gecos eq,sub,pres >> >> > index uid eq,sub,pres >> >> > index memberUid eq,sub,pres >> >> > index uidNumber eq,pres >> >> > index gidNumber eq,pres >> >> > index entryCSN eq,pres >> >> > index entryUUID eq,pres >> >> > index uniqueMember eq,pres >> >> > index userPassword eq,pres >> >> > index krb5PrincipalName eq,pres >> >> > index krb5PrincipalRealm eq,pres >> >> > index sambaDomainName eq,pres >> >> > index sambaSID eq,pres >> >> > index sambaPrimaryGroupSID eq,pres >> >> > index sambaSIDList eq,pres >> >> > >> >> > lastmod on >> >> > >> >> > checkpoint 256 15 >> >> > >> >> > password-hash {SSHA} >> >> > >> >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited >> >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited >> >> > limits dn.exact="cn=ldapi,dc=iwu,dc=edu" size.hard=unlimited >> >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited >> >> > limits dn.exact="cn=sambaadmin,dc=iwu,dc=edu" size.hard=unlimited >> >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited >> >> > limits dn.exact="cn=mirror,dc=iwu,dc=edu" size.hard=unlimited >> >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited >> >> > limits dn.exact="cn=freeradius,dc=iwu,dc=edu" size.hard=unlimited >> >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited >> >> > >> >> > access to dn.sub="dc=iwu,dc=edu" >> >> > by dn.exact="cn=ldapi,dc=iwu,dc=edu" write >> >> > by dn.exact="cn=sambaadmin,dc=iwu,dc=edu" write >> >> > by dn.exact="cn=mirror,dc=iwu,dc=edu" read >> >> > by dn.exact="cn=freeradius,dc=iwu,dc=edu" read >> >> > by * break >> >> > >> >> > access to dn.sub="dc=iwu,dc=edu" >> >> > attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword,krb5Key >> >> > by anonymous auth >> >> > by self write >> >> > by dn.exact="cn=passwordmanager,dc=iwu,dc=edu" write >> >> > by users auth >> >> > by * break >> >> > >> >> > access to dn.exact="cn=ldapi,dc=iwu,dc=edu" by * none >> >> > access to dn.exact="cn=sambaadmin,dc=iwu,dc=edu" by * none >> >> > access to dn.exact="cn=mirror,dc=iwu,dc=edu" by * none >> >> > access to dn.exact="cn=freeradius,dc=iwu,dc=edu" by * none >> >> > access to dn.exact="cn=passwordmanager,dc=iwu,dc=edu" by * none >> >> > access to dn.exact="cn=admin,dc=iwu,dc=edu" by * none >> >> > >> >> > access to dn.regex="uid=.*\$,ou=People,dc=iwu,dc=edu" by self read by >> >> > * >> >> > none >> >> > access to dn.sub="ou=Computers,dc=iwu,dc=edu" by self read by * none >> >> > access to dn.sub="ou=Idmap,dc=iwu,dc=edu" by self read by * none >> >> > access to dn.exact="sambaDomainName=IWU.EDU,dc=iwu,dc=edu" by self >> >> > read >> >> > by * none >> >> > access to dn.exact="uid=Administrator,ou=People,dc=iwu,dc=edu" by >> >> > self >> >> > read by * none >> >> > access to dn.exact="uid=root,ou=People,dc=iwu,dc=edu" by self read by >> >> > * >> >> > none >> >> > >> >> > access to >> >> > dn.regex="krb5PrincipalName=.*(a)IWU.EDU,ou=People,dc=iwu,dc=edu" by >> >> > self >> >> > read by * none >> >> > >> >> > access to dn.sub="dc=iwu,dc=edu" >> >> > attrs=telephoneNumber,mobileTelephoneNumber,homePostalAddress,streetAddress,physicalDeliveryOfficeName,roomNumber,preferredLanguage,localityName,postOfficeBox,postalCode,stateOrProvinceName >> >> > by self write >> >> > by users read >> >> > by anonymous none >> >> > by * break >> >> > >> >> > access to dn.sub="dc=iwu,dc=edu" >> >> > attrs=krb5PrincipalName,krb5MaxLife,krb5MaxRenew,krb5KDCFlags,krb5KeyVersionNumber >> >> > by self read >> >> > by anonymous none >> >> > by * break >> >> > >> >> > access to dn.sub="dc=iwu,dc=edu" >> >> > attrs=sambaPrimaryGroupSID,sambaSID,sambaAlgorithmicRidBase,sambaNextRid >> >> > by * none >> >> > >> >> > access to dn.sub="dc=iwu,dc=edu" >> >> > attrs=sambaPwdCanChange,sambaLogonTime,sambaLogoffTime,sambaAcctFlags,sambaPasswordHistory,sambaPwdLastSet,sambaGroupType,sambaPwdMustChange,sambaKickoffTime,sambaLockoutThreshold,sambaForceLogoff,sambaRefuseMachinePwdChange,sambaLockoutObservationWindow,sambaLockoutDuration,sambaMinPwdAge,sambaMaxPwdAge,sambaLogonToChgPwd,sambaPwdHistoryLength,sambaMinPwdLength >> >> > by self read >> >> > by anonymous none >> >> > by * break >> >> > >> >> > access to dn.sub="dc=iwu,dc=edu" by * read >> >> > >> >> > serverID 1 >> >> > >> >> > syncrepl rid=2 >> >> > provider=ldap://ldap2.iwu.edu/ >> >> > schemachecking=off >> >> > searchbase="dc=iwu,dc=edu" >> >> > scope=sub >> >> > type=refreshAndPersist >> >> > binddn="cn=mirror,dc=iwu,dc=edu" >> >> > credentials={redacted} >> >> > bindmethod=simple >> >> > starttls=yes >> >> > tls_cert=/etc/ldap/ssl/ldap.iwu.edu.crt >> >> > tls_key=/etc/ldap/ssl/ldap.iwu.edu.key >> >> > tls_cacert=/etc/ldap/ssl/IWU.crt >> >> > tls_reqcert=try >> >> > interval=00:00:00:30 >> >> > retry="15 +" >> >> > timeout=1 >> >> > timelimit=unlimited >> >> > sizelimit=unlimited >> >> > >> >> > mirrormode on >> >> > >> >> > ############################### >> >> > database monitor >> >> > limits dn.exact="cn=admin,dc=iwu,dc=edu" size.hard=unlimited >> >> > time.hard=unlimited size.soft=unlimited time.soft=unlimited >> >> > >> >> > access to dn.exact="cn=Monitor" >> >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read >> >> > by * none >> >> > >> >> > access to dn.subtree="cn=Monitor" >> >> > by dn.exact="cn=admin,dc=iwu,dc=edu" read >> >> > by * none >> >> > >> >> > >> >> >> >> >> >> On 22/12/2008, Pat Riehecky <prieheck(a)iwu.edu> wrote: >> >> >> > Here is the quick and dirty what I am trying to do: >> >> >> > >> >> >> > ldap1 and ldap2 are supposed to be in MultiMaster. They are time >> >> >> > synced >> >> >> > to pool.ntp.org and each other (if they drift I would rather they >> >> >> > sorta >> >> >> > drift together, but pool should be keeping that in check). >> >> >> > >> >> >> > Right now I am just beating them up to see how 2.4.13 performs. >> >> >> > (So >> >> >> > far >> >> >> > VERY well, minus this little problem) >> >> >> > >> >> >> > I have a rather small ldif (41 entries) that just wont sync (I'm >> >> >> > starting small). Debug gives me >> >> >> > >> >> >> > ber_scanf fmt (m}) ber: >> >> >> > ber_dump: buf=0xb806f120 ptr=0xb806f137 end=0xb806f175 len=62 >> >> >> > 0000: 00 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 >> >> >> > 30 .<rid=001,sid=00 >> >> >> > 0010: 32 2c 63 73 6e 3d 32 30 30 38 31 32 32 32 31 37 >> >> >> > 2,csn=2008122217 >> >> >> > 0020: 34 37 32 31 2e 38 35 35 39 30 34 5a 23 30 30 30 >> >> >> > 4721.855904Z#000 >> >> >> > 0030: 30 30 30 23 30 30 31 23 30 30 30 30 30 30 >> >> >> > 000#001#000000 >> >> >> > do_syncrep2: >> >> >> > cookie=rid=001,sid=002,csn=20081222174721.855904Z#000000#001#000000 >> >> >> > do_syncrep2: rid=001 CSN too old, ignoring >> >> >> > 20081222174721.855904Z#000000#001#000000 >> >> >> > ldap_msgfree >> >> >> > >> >> >> > I am not exactly sure how it gotten to be "too old." The ldif I >> >> >> > am >> >> >> > importing is not the result of a slapcat or anything that would >> >> >> > preserve >> >> >> > the CSN or UUID attributes (not that syncrepl uses UUID). I am >> >> >> > loading >> >> >> > one single file with ldapadd which, in my understanding, sets up >> >> >> > the >> >> >> > CSN >> >> >> > and wouldn't let me import one anyway. >> >> >> > >> >> >> > Each server has no entries until I load the one, so there >> >> >> > shouldn't >> >> >> > be >> >> >> > any weird stale CSNs causing this. They are "sync'ed" almost >> >> >> > instantly >> >> >> > after the one system is loaded - I just don't have everything. >> >> >> > >> >> >> > After a sync: >> >> >> > ldap1 - slapcat |grep dn: |wc -l = 41 >> >> >> > ldap2 - slapcat |grep dn: |wc -l = 18 >> >> >> > >> >> >> > Right now I can get them in sync with a slapcat/slapadd, but when >> >> >> > the >> >> >> > go >> >> >> > into production I wont be able to say for certain which one is >> >> >> > authoritative. That is the purpose of multi-master.... >> >> >> > >> >> >> > OpenLDAP 2.4.13, built by me (passed all tests) on Ubuntu Linux 32 >> >> >> > bit >> >> >> > >> >> >> > Any ideas as to what I can do to stop this from happening? >> >> >> > >> >> >> > Pat >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> > >> >> > >> >> >> > >> > >> > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

14 years, 9 months

1
0
0 / 0

CSN too old, ignoring - and therefore not syncing

by Pat Riehecky

Here is the quick and dirty what I am trying to do: ldap1 and ldap2 are supposed to be in MultiMaster. They are time synced to pool.ntp.org and each other (if they drift I would rather they sorta drift together, but pool should be keeping that in check). Right now I am just beating them up to see how 2.4.13 performs. (So far VERY well, minus this little problem) I have a rather small ldif (41 entries) that just wont sync (I'm starting small). Debug gives me ber_scanf fmt (m}) ber: ber_dump: buf=0xb806f120 ptr=0xb806f137 end=0xb806f175 len=62 0000: 00 3c 72 69 64 3d 30 30 31 2c 73 69 64 3d 30 30 .<rid=001,sid=00 0010: 32 2c 63 73 6e 3d 32 30 30 38 31 32 32 32 31 37 2,csn=2008122217 0020: 34 37 32 31 2e 38 35 35 39 30 34 5a 23 30 30 30 4721.855904Z#000 0030: 30 30 30 23 30 30 31 23 30 30 30 30 30 30 000#001#000000 do_syncrep2: cookie=rid=001,sid=002,csn=20081222174721.855904Z#000000#001#000000 do_syncrep2: rid=001 CSN too old, ignoring 20081222174721.855904Z#000000#001#000000 ldap_msgfree I am not exactly sure how it gotten to be "too old." The ldif I am importing is not the result of a slapcat or anything that would preserve the CSN or UUID attributes (not that syncrepl uses UUID). I am loading one single file with ldapadd which, in my understanding, sets up the CSN and wouldn't let me import one anyway. Each server has no entries until I load the one, so there shouldn't be any weird stale CSNs causing this. They are "sync'ed" almost instantly after the one system is loaded - I just don't have everything. After a sync: ldap1 - slapcat |grep dn: |wc -l = 41 ldap2 - slapcat |grep dn: |wc -l = 18 Right now I can get them in sync with a slapcat/slapadd, but when the go into production I wont be able to say for certain which one is authoritative. That is the purpose of multi-master.... OpenLDAP 2.4.13, built by me (passed all tests) on Ubuntu Linux 32 bit Any ideas as to what I can do to stop this from happening? Pat

14 years, 9 months

4
11
0 / 0

restricting ldap unix groups to groups of hosts.

by Martin Suehowicz

I am new to openldap. I am trying to restrict groups of users to groups hosts on centos machines. Netgroups or pam_access seem to get me part of the way there. However I do not want to touch the clients very much and would like them to have a uniform configuration. I would like ldap to hold the host groups, user groups and acl's for them. Is there a way do this? Thank You for any help you can provide. Martin

14 years, 9 months

1
0
0 / 0

N-Way Multi-Master replication - delete problem

by Adrien Futschik

OK, But then what did I do wrong ? delete an entry shouldn't be a problem with N-Way Multi-Master replication ? should it ? Here is how I have setup-ed my masters : m1 -config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m2 - config : dn: cn=config objectClass: olcGlobal cn: config olcServerID: 2 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW:< file://$CONFIGPWF m1 - syncprov : dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m2 - syncrepl : dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=3 - add: olcMirrorMode olcMirrorMode: TRUE m1 - schema : include: file://$ABS_SCHEMADIR/core.ldif include: file://$ABS_SCHEMADIR/cosine.ldif include: file://$ABS_SCHEMADIR/inetorgperson.ldif include: file://$ABS_SCHEMADIR/openldap.ldif include: file://$ABS_SCHEMADIR/nis.ldif m1 - backend : dn: olcDatabase={1}$BACKEND,cn=config objectClass: olcDatabaseConfig objectClass: olc${BACKEND}Config olcDatabase: {1}$BACKEND olcSuffix: $BASEDN olcDbDirectory: ./openldap-data olcRootDN: $MANAGERDN olcRootPW: $PASSWD olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=$INTERVAL retry="5 5 300 5" timeout=3 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov Did I miss something ? Has anyone tested N-way Multi-master replication & encountered the same problem as me ? Adrien ======================================== Message date : Dec 19 2008, 07:11 PM From : "Quanah Gibson-Mount" <quanah(a)zimbra.com> To : adrien.futschik(a)atosorigin.com, openldap-technical(a)openldap.org Copy to : "Miguel Jinez" <miguel.jinez(a)gmail.com> Subject : Re: Re: N-Way Multi-Master replication - delete problem --On December 19, 2008 9:28:41 AM +0100 Adrien Futschik <adrien.futschik(a)atosorigin.com> wrote: > Hy everyone, > > I have just tested the same procedure with OpenLDAP 2.4.13. The problem > remains the same. > > Did I miss something ? Is this supposed to be like this ? > > I'm joining the modified script I'm using to setup both masters and the > LDIF files I'm using to add and remove an entry (+ attributes). > > I did not use access-log, is this supposed to work with N-Way > Multi-Master replication ? I thought it was only used in case of Delta > Synchronization/Replication. Correct, delta-syncrepl and MMR are not currently supported together (that may change in the future). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration Adrien Futschik

14 years, 9 months

1
0
0 / 0

remove the /var/lib/ldap directory mistake !!!

by franck dufau

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hye all, i have remove the /var/lib/ldap directory by mistake ! darkness.... how rebuild the ldap database ? i can not find information about this ! i do not have backup....arfff.. tks by advance... Franck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklOfFoACgkQrKIazktK/hJ8SACfR2+IFx6HwaB77zrryWbaoEby T9YAoJ4YzJTsZdCiwXFWVAUL+I6CMDHH =ih79 -----END PGP SIGNATURE-----

14 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2008