openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

LDAP - Samba
by Terry Haley 31 Dec '08

31 Dec '08

Ok, I'm trying to wrangle this under control with this setup I've inherited and have run across a few speed bumps. Here's the state of things as is. I've made a few changes to the setup thinking that I've fixed an issue or two and have in fact only confused myself and possibly my configuration. The downside is that I don't know a few key passwords that was used in the original setup. (yay no overlap with my predecessor). I have a samba server acting as my PDC with an LDAP server used for authentication. Question #1: the password contained within the LDAP directory for my 'admin' account should = the 'rootpw' entry in slapd.conf correct? Question #2: the 'ldap admin dn' entry in my smb.conf file should equal the 'rootdn' entry in my slapd.conf file, afterwhich, this should be updated to samba using smbpasswd -w correct? Question #3: the 'admin users' entry within the smb.conf are the users that allow access to the domain correct? Currently, what I'm working with here is that I don't know the 'admin, samba or the samba-admin' passwords. The samba-admin account is just an LDAP admin account but Not the root account. This should be fixed to the above question 2 yes? I would like to change all of these passwords but am fearful that I could make things worse. Also, regarding the components on my network (machines specifically), will there be an issue if I change the 'samba' account (domain account) password with their ability to connect to the domain? Thank you in advance for any help and advice! The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.

4 3

Constant corruptions
by Jason Voorhees 30 Dec '08

30 Dec '08

Hi there: I'm still having problems with my OpenLDAP 2.3.27 from CentOS 5. I know that index directive in slapd.conf causes the creation of .bdb files in /var/lib/ldap, right? If I have this in slapd.conf: index uid,smtpAuth eq,pres ... so in some moment uid.bdb and smtpAuth.bdb will be created in /var/lib/ldap, right? When I create my ldap tree using slapadd and an LDIF file then several .bdb files get created under /var/lib/ldap, but some other no because of there are no attributes of that type in LDIF file. But when OpenLDAP is already running thanks to a simple search like "(smtpAuth=TRUE)" then slapd tries to create smtpAuth.bdb but that's when it fails. I get this message: slapd[11954]: bdb(dc=redtube,dc=com): /var/lib/ldap/smtpAuth.bdb: Permission denied slapd[11954]: bdb_db_cache: db_open(smtpAuth) failed: Permission denied (13) Does anybody know why slapd isn't able to create new index files? Permissions and ownership are totally correct. Any help? :( P.D.: I'm running openldap in a centos paravirtualized with Xen. It could be this the problem?

1 0

Re: Re: TLS config causes Object class violation
by forumuser＠online.de 30 Dec '08

30 Dec '08

Thanks!!! That's it! Like you said, I changed my TLSconfiguration.ldif file to point to "dn: cn=config" and it worked. I've once already seen the olcTLS* in the olcGlobal, however, I am new to LDAP backend database configuration, only used slapd.conf before. Thank you very much for the solution! I wish you a happy new year Belem ----- Ursprüngliche Nachricht ----- Von: Pierangelo Masarati Gesendet: 28.12.08 21:35 Uhr An: forumuser(a)online.de Betreff: Re: TLS config causes Object class violation olcTLSCACertificateFile belongs to olcGlobal, while you're trying to add it to a database object. Add it to cn=config instead. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

TLS config causes Object class violation
by forumuser＠online.de 28 Dec '08

28 Dec '08

Recently I upgraded my Ubuntu Server 8.04 to 8.10 and had to reconfigure OpenLDAP (installed by apt-get) through slapd backend database (I used slapd.config before). I have reconfigured OpenLDAP by "sudo dpkg-reconfigure slapd" and confirmed all prior settings, however the old database was moved to /var/backup/ and a fresh one was generated (please see config tree at the end). The problem is, I get following error message..: ldap_modify: Object class violation (65) additional info: attribute 'olcTLSCACertificateFile' not allowed (even olcTLSCertificateFile, if I leave out olcTLSCACertificateFile... olcTLS* seems "not allowed") ..when I try to configure TLS by ldapmodify: ldapmodify -D cn=admin,cn=config -W -x by entering this: dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/servercert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/serverkey.pem The config tree is as follows (I will change "mydomain" and ACL later): dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=mydomain,dc=org olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=mydomain,dc=org" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=admin,dc=mydomain,dc=org" write by * read olcLastMod: TRUE olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq Here's my "sudo apt-cache show slapd" packet information: Package: slapd Priority: optional Section: net Installed-Size: 3872 Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Architecture: i386 Source: openldap Version: 2.4.11-0ubuntu6 Replaces: apparmor-profiles (<< 2.1+1075-0ubuntu4), ldap-utils (<< 2.2.23-3), libldap2 Provides: ldap-server, libslapi-2.4-2 Depends: libc6 (>= 2.4), libdb4.2, libgcrypt11 (>= 1.4.0), libgnutls26 (>= 2.4.0-0), libldap-2.4-2 (= 2.4.11-0ubuntu6), libltdl7 (>= 2.2.4), libperl5.10 (>= 5.10.0), libsasl2-2, libslp1, libtasn1-3 (>= 0.3.4), libwrap0 (>= 7.6-4~), unixodbc (>= 2.2.11-1), zlib1g (>= 1:1.1.4), coreutils (>= 4.5.1-1), psmisc, perl (>> 5.8.0) | libmime-base64-perl, adduser Pre-Depends: debconf (>= 0.5) | debconf-2.0 Recommends: libsasl2-modules, apparmor (>= 2.1+1075-0ubuntu6) Suggests: ldap-utils Conflicts: apparmor-profiles (<< 2.1+1075-0ubuntu4), ldap-server, libltdl3 (= 1.5.4-1), umich-ldapd Filename: pool/main/o/openldap/slapd_2.4.11-0ubuntu6_i386.deb Size: 1466528 MD5sum: 41047db9f250c0e73e2e3c43c5d90f5a SHA1: 4c23c98d55851fef7ec4ff5e4fa8d7cd1c885da9 SHA256: 107e5df3dea5a0571a2f99df1d7c919247a4223a991a99e8393b0915e39f1fc9 Description-de: OpenLDAP-Server (slapd) This is the OpenLDAP (Lightweight Directory Access Protocol) server (slapd). The server can be used to provide a standalone directory service. Homepage: http://www.openldap.org/ Bugs: mailto:ubuntu-users@lists.ubuntu.com Origin: Ubuntu (libgnutls26 is of version: 2.4.1-1build1) Can someone help me with this "Object class violation (65)" problem concerning TLS? Belem

2 1

Named pipe to local ldap slave fails when master is down.
by Jan Hugo Prins 27 Dec '08

27 Dec '08

Hi I've got a strange thing yesterday. The server that is doing my master ldap went down due to some software glitch. Al my MDA's are running there own slave ldap so they don't have to go to the master server, but what surprised me, the slaves didn't want to service anything on there named pipe while the master server was down. Why is this? The MTA's also use the ldap on the MDA's but they didn't have any problem during this master ldap outage. The only difference between the MDA's and the MTA's is that the MTA's connect to ldap with TCP/IP while the MDA's connect to ldap with a named pipe. I use syncrepl for replication. My master server is running version 2.4.12 on Fedora 10. My slave servers are running 2.3.43 on Fedora 7. In the near future I want to make this master server a dual master setup with a different server that I'm currently building. But for now I have just one master. This really breaks my whole anti SPOF setup. Can anyone tell me what is causing this? Greetings, Jan Hugo Prins

2 1

Check out my Facebook profile
by Rakesh Yadav 26 Dec '08

26 Dec '08

Hi openldap-technical, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Rakesh To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=682100664&k=64D665VZRWVM5CEDXA64U4&r

1 0

CSN too old, ignoring, N-way multi-master replication
by Adrien Futschik 24 Dec '08

24 Dec '08

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

1 0

Re: Re: CSN too old, ignoring - and therefore not syncing
by Adrien Futschik 24 Dec '08

24 Dec '08

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

2 1

Re: Fwd: CSN too old, ignoring - and therefore not syncing
by Adrien Futschik 24 Dec '08

24 Dec '08

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

2 1

Different shells ¿how to workaround?
by Jordi Espasa Clofent 24 Dec '08

24 Dec '08

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

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical