openldap-software April 2010

openldap-software@openldap.org

47 participants
48 discussions

Empty suffix database vs. rootDSE
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

I've noticed that if a producer is rooted at the empty suffix, searches for the rootDSE (base="", scope="base"), return an entry consisting in the rootDSE entry plus the producer's contextCSN. I've tracked this down to backend_operational(): at some point, when the entry is almost ready, selects the database that serves the empty DN, and calls that database's be_operational() helper; here syncprov_operational() adds the contextCSN. Is this intended? I'm asking because indeed this is the only way we can get the contextCSN for that database; searches with base="" and scope other than "base" would return the database's entries but no entry with empty dn. p.

2 1

OpenLDAP ACLs Question
by Tim Gustafson 19 Apr '10

19 Apr '10

Hi, We have three OpenLDAP servers: 10.0.0.2, 10.0.0.3 and 10.0.0.4 and one web server 10.0.0.5. For a long time we've had two baseDN databases running on the OpenLDAP servers with ACLs configured so that anyone on the subnet can read anything in the system and our replication has been working well. Recently, we've added the third database with more restrictive ACLs that look like this: ============================================================ access to * by dn="uid=replicator,ou=People,dc=bar" read by * break access to attrs=userPassword,sambaNTPassword by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write by self write by anonymous auth by * none access to attrs=entry,uid,cn,sn,givenName,title,departmentNumber,mail,telephoneNumber,roomNumber by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write by users read by * none access to * by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write by * none ============================================================ With these ACLs, replication works when anyone in the ldap-admins group posts an update to the server. However, if a user updates their own password, replication does not take place. If we change the last access clause to this: ============================================================ access to * by group/groupOfNames/Member="cn=ldap-admins,ou=Group,dc=bar" write by peername.regex="10\.0\.0\.5" read by * none ============================================================ then the user self-updates are replicated properly. Note that 10.0.0.5 is the *web server*. The way I read this ACL, it means we're granting read access to the web server, and in so doing, the other two LDAP servers (10.0.0.3 and 10.0.0.4) are magically able to replicate data again. When replication is *not* working in this set-up, re-starting slapd on 10.0.0.3 and 10.0.0.4 (without changing any ACLs anywhere) causes them to suck down all the updates they missed before. Am I misunderstanding the way these ACLs work? Is there any way that giving READ access to the web server (which it already has by virtue of the user having bound themselves to the LDAP server) should cause replication for 10.0.0.3 and 10.0.0.4 to work again? Or is this perhaps a bug in the version of slapd (2.3.43; yes I know it's old; it's a vendor package and that's how we roll around here at the moment) that we're running? I'm not really asking anyone to fix the problem or to offer a solution to the problem...I just want to know if this sort of replication issue was a known problem in the past? Tim Gustafson Baskin School of Engineering UC Santa Cruz tjg(a)soe.ucsc.edu 831-459-5354

3 2

Help with openldap and starttls
by john espiro 16 Apr '10

16 Apr '10

I have read through all of the docs and am having trouble setting up openldap to use starttls. How do I configure OpenLDAP (command line tool) to use Start TLS? Thanks, John

3 6

Authenticating with multiple databases
by Ian Gillman 16 Apr '10

16 Apr '10

We have a situation where we have 2 OpenLDAP databases containing usernames, passwords etc... for two distinct entities. We would like to be able to send an authentication request to one of the databases and have it return yes or no based upon the information in both databases. In other words, database A (DBa) has user A's (Ua) credentials and database B (DBb) has user B's (Ub) credentials. We would like to be able to talk to either DBa or DBb and get back the user credentials and authentication for both Ua and Ub. Is there some way I can set up OpenLDAP to be able to try and authenticate a user request locally and then, if that fails, to authenticate the request remotely without the requestor having to know about the remote database? We do not want to replicate information between the databases. Thanks Ian Gillman Senior Network Administrator Monroe Clinic 608-324-1416 ian.gillman(a)monroeclinic.org CONFIDENTIALITY NOTICE: ------------------------ This message and any included attachments are from Monroe Clinic and are for the sole use of the intended recipient(s). This message may contain confidential and privileged information. Unauthorized review, use, disclosure or distribution is strictly prohibited and may be unlawful. If you are not the intended recipient, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Monroe Clinic at (608)324-1000 or (608)324-2000.

3 2

any benefit to skipping unused schema files?
by Tim Mooney 16 Apr '10

16 Apr '10

I'm preparing to upgrade our OpenLDAP installation from 2.3.x to 2.4.21. I've been through chapter 13 (Schema Specification) of the admin guide and read the entries in the schema section of the FAQ. With 2.4.x, there are several more schema files that are loaded by default, vs. what we are using in our 2.3.x installation (core, cosine, inetorgperson, misc, and one custom overlay). Is there any appreciable benefit to not loading schema files that I'm confident we won't be using (java, dyngroup, corba, probably others)? I generally avoid "kitchen sink" software installation and prefer to pare down what's enabled in a software package to the bits we need, but I can't imagine skipping a few schema files is going to save a significant amount of resources on a modern system with 24 GiB RAM. Is there any other reason to skip schema files we won't be using? Thanks, Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

2 1

ACLs - allowing a user to add a new attribute
by Matt Ingram 15 Apr '10

15 Apr '10

Hi All. We're trying to implement acls that will allow our Admins to modify the LDAP directory without using a generic admin account, and using their own credentials within LDAP. Our requirement is that the Admins can modify the mail, uid and userPassword attributes. Which I have working. Part of this also requires that the Admin has the ability to add those attributes. That does not work. We have our system automated so that HR creates a user and the basics are automatically populated into LDAP, however the mail, uid and userpassword attributes are not created at that time. What kind of an ACL do I need to allow the Admins to create the mail, uid and userPassword attributes ? Thanks in advance. Matt. Here's what I have for ACLs access to dn="cn=Manager,dc=domain,dc=com" by * auth access to dn="ou=Admins,dc=domain,dc=com" by dn.children="ou=Admins,dc=domain,dc=com" read by * auth access to attrs=employeeNumber by dn.children="ou=Admins,dc=domain,dc=com" write by self read by * search #Allow Admins ou and ldappers group to modify ldap's userPassword attribute access to attrs=userPassword by group/groupOfNames/member="cn=ldappers,ou=Apps,ou=Groups,ou=Accounts,dc=domain,dc=com" write by dn.children="ou=Admins,dc=domain,dc=com" write by self write by * auth #allow Admins ou and ldappers group to modify ldap's mail and uid attributes and cbnActive attribute access to attrs=mail,uid by group/groupOfNames/member="cn=ldappers,ou=Apps,ou=Groups,ou=Accounts,dc=domain,dc=com" write by dn.children="ou=Admins,dc=domain,dc=com" write by self read by * read access to * by dn.children="ou=Admins,dc=domain,dc=com" write by * read -- Matt Ingram Intermediate Unix Administrator, IS Canadian Bank Note Company, Limited \m/

4 7

Re: Problems replicating deleted entries when slave is down.
by Lior Goikhburg 15 Apr '10

15 Apr '10

Sorry my bad, Master: dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}memberof.la structuralObjectClass: olcModuleList creatorsName: cn=config entryUUID: b4dec246-8d67-102d-9827-65d8858906d8 createTimestamp: 20090212154358Z entryCSN: 20090212154358.261980Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090212154358Z dn: olcOverlay={1}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpSessionlog: 100 entryUUID: ad98aace-8b05-102d-8b73-fd81f30554e6 creatorsName: cn=config createTimestamp: 20090209145713Z structuralObjectClass: olcSyncProvConfig olcSpCheckpoint: 100 1 entryCSN: 20091104130358.860872Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20091104130358Z Slave: dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}memberof.la structuralObjectClass: olcModuleList creatorsName: cn=config entryUUID: b4dec246-8d67-102d-9827-65d8858906d8 createTimestamp: 20090212154358Z entryCSN: 20090212154358.261980Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090212154358Z dn: olcOverlay={1}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpSessionlog: 100 entryUUID: ad98aace-8b05-102d-8b73-fd81f30554e6 creatorsName: cn=config createTimestamp: 20090209145713Z structuralObjectClass: olcSyncProvConfig olcSpCheckpoint: 100 1 entryCSN: 20091104130358.860872Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20091104130358Z On Thu, Apr 15, 2010 at 7:32 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > Please keep replies on the list. Thanks. See the end of the email for my > question. > > > > --On Thursday, April 15, 2010 4:50 PM +0400 Lior Goikhburg < > mailing-lists(a)griddynamics.com> wrote: > > Here are the configs: >> >> Master: >> >> dn: cn=config >> objectClass: olcGlobal >> cn: config >> olcConfigFile: slapd.conf.1 >> olcConfigDir: slapd.d >> olcArgsFile: /var/run/openldap/slapd.args >> olcAttributeOptions: lang- >> olcConcurrency: 0 >> olcConnMaxPending: 100 >> olcConnMaxPendingAuth: 1000 >> olcGentleHUP: FALSE >> olcIdleTimeout: 0 >> olcIndexSubstrIfMaxLen: 4 >> olcIndexSubstrIfMinLen: 2 >> olcIndexSubstrAnyLen: 4 >> olcIndexSubstrAnyStep: 2 >> olcIndexIntLen: 4 >> olcLocalSSF: 71 >> olcPidFile: /var/run/openldap/slapd.pid >> olcReadOnly: FALSE >> olcReverseLookup: FALSE >> olcSaslSecProps: noplain,noanonymous >> olcSockbufMaxIncoming: 262143 >> olcSockbufMaxIncomingAuth: 16777215 >> olcThreads: 16 >> olcTLSCRLCheck: none >> olcTLSVerifyClient: never >> olcToolThreads: 1 >> structuralObjectClass: olcGlobal >> creatorsName: cn=config >> entryUUID: b4deb404-8d67-102d-9826-65d8858906d8 >> createTimestamp: 20090212154358Z >> olcSaslHost: ldap-test1.carina.griddynamics.net >> olcLogLevel: 0 >> olcAuthzPolicy: to >> olcAuthzRegexp: {0}uid=([^@]*)[@,].*cn=digest-md5,cn=auth >> ldap:///dc=griddynam >> ics,dc=net??sub?(uid=$1) >> olcSizeLimit: 10000 >> olcServerID: 1 ldap://ldap-test1.carina.griddynamics.net >> entryCSN: 20091121171118.965511Z#000000#002#000000 >> modifiersName: cn=config >> modifyTimestamp: 20091121171118Z >> contextCSN: 20100121080100.534901Z#000000#001#000000 >> >> dn: olcDatabase={2}bdb >> objectClass: olcDatabaseConfig >> objectClass: olcBdbConfig >> olcDatabase: {2}bdb >> olcDbDirectory: /var/lib/ldap/griddynamics.net >> olcSuffix: dc=griddynamics,dc=net >> olcLastMod: TRUE >> olcMaxDerefDepth: 15 >> olcReadOnly: FALSE >> olcRootDN: cn=Manager,dc=griddynamics,dc=net >> olcMonitoring: TRUE >> olcDbDirtyRead: FALSE >> olcDbLinearIndex: FALSE >> olcDbMode: 384 >> olcDbSearchStack: 16 >> olcDbShmKey: 0 >> olcDbCacheFree: 1 >> olcDbDNcacheSize: 0 >> entryUUID: acc152ea-8b05-102d-8b71-fd81f30554e6 >> creatorsName: cn=config >> createTimestamp: 20090209145711Z >> structuralObjectClass: olcBdbConfig >> olcRootPW:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= >> olcAccess: {0}to >> attrs=userPassword,userPKCS12,sambaLMPassword,sambaNTPassword >> by sockurl.regex="^ldapi:///$" write by >> group.exact="cn=noc,ou=groups,dc=gr >> iddynamics,dc=net" write by self write by anonymous auth >> olcAccess: {1}to attrs=shadowLastChange by sockurl.regex="^ldapi:///$" >> write >> by group.exact="cn=noc,ou=groups,dc=griddynamics,dc=net" write by >> self wri >> te by * read >> olcAccess: {2}to * by sockurl.regex="^ldapi:///$" write by >> group.exact="cn=n >> oc,ou=groups,dc=griddynamics,dc=net" write by self write by * read >> olcDbIndex: default eq >> olcDbIndex: objectClass,entryUUID,entryCSN >> olcDbIndex: cn pres,eq,sub >> olcDbIndex: uid pres,eq,sub >> olcDbIndex: uidNumber pres,eq >> olcDbIndex: gidNumber pres,eq >> olcDbIndex: memberOf pres,eq >> olcDbIndex: ou pres,eq,sub >> olcDbIndex: mail pres,eq,sub >> olcDbIndex: loginShell pres,eq >> olcDbIndex: sn pres,eq,sub >> olcDbIndex: givenName pres,eq,sub >> olcDbIndex: memberUid pres,eq >> olcDbIndex: nisMapName pres,eq,sub >> olcDbIndex: nisMapEntry pres,eq,sub >> olcDbIndex: uniqueMember pres,eq >> olcDbIndex: gosaObject pres,eq >> olcDbIndex: zoneName pres,eq >> olcDbIndex: relativeDomainName pres,eq >> olcDbIndex: member pres,eq >> olcDbIndex: dhcpPrimaryDN pres,eq >> olcDbIndex: dhcpSecondaryDN pres,eq >> olcDbIndex: dhcpServerDN pres,eq >> olcDbIndex: dhcpFailOverPeerDN pres,eq >> olcDbIndex: dhcpHWAddress pres,eq >> olcDbNoSync: TRUE >> olcDbCheckpoint: 1024 5 >> olcDbCacheSize: 5000 >> olcDbIDLcacheSize: 5000 >> olcSyncrepl: {0}rid=001 >> provider=ldap://ldap-test1.carina.griddynamics.net bindmetho >> d=simple timeout=1 network-timeout=0 >> binddn="cn=manager,dc=griddynamics,dc=ne >> t" credentials="xxxxxxxxxxx" starttls=no filter="(objectclass=*)" >> searchbase="dc >> =griddynamics,dc=net" scope=sub schemachecking=off >> type=refreshAndPersist ret >> ry="10 +" >> olcDbConfig: {0}set_flags DB_LOG_AUTOREMOVE >> olcDbConfig: {1}set_cachesize 0 33554432 0 >> entryCSN: 20091121172900.646924Z#000000#001#000000 >> modifiersName: cn=config >> modifyTimestamp: 20091121172900Z >> >> >> Slave: >> >> dn: cn=config >> objectClass: olcGlobal >> cn: config >> olcConfigFile: slapd.conf.1 >> olcConfigDir: slapd.d >> olcArgsFile: /var/run/openldap/slapd.args >> olcAttributeOptions: lang- >> olcConcurrency: 0 >> olcConnMaxPending: 100 >> olcConnMaxPendingAuth: 1000 >> olcGentleHUP: FALSE >> olcIdleTimeout: 0 >> olcIndexSubstrIfMaxLen: 4 >> olcIndexSubstrIfMinLen: 2 >> olcIndexSubstrAnyLen: 4 >> olcIndexSubstrAnyStep: 2 >> olcIndexIntLen: 4 >> olcLocalSSF: 71 >> olcPidFile: /var/run/openldap/slapd.pid >> olcReadOnly: FALSE >> olcReverseLookup: FALSE >> olcSaslSecProps: noplain,noanonymous >> olcSockbufMaxIncoming: 262143 >> olcSockbufMaxIncomingAuth: 16777215 >> olcThreads: 16 >> olcTLSCRLCheck: none >> olcTLSVerifyClient: never >> olcToolThreads: 1 >> structuralObjectClass: olcGlobal >> creatorsName: cn=config >> entryUUID: b4deb404-8d67-102d-9826-65d8858906d8 >> createTimestamp: 20090212154358Z >> olcSaslHost: ldap-test1.carina.griddynamics.net >> olcLogLevel: 0 >> olcAuthzPolicy: to >> olcAuthzRegexp: {0}uid=([^@]*)[@,].*cn=digest-md5,cn=auth >> ldap:///dc=griddynam >> ics,dc=net??sub?(uid=$1) >> olcSizeLimit: 10000 >> olcServerID: 1 ldap://ldap-test1.carina.griddynamics.net >> entryCSN: 20091121171118.965511Z#000000#002#000000 >> modifiersName: cn=config >> modifyTimestamp: 20091121171118Z >> contextCSN: 20100121080100.534901Z#000000#001#000000 >> >> dn: olcDatabase={2}bdb >> objectClass: olcDatabaseConfig >> objectClass: olcBdbConfig >> olcDatabase: {2}bdb >> olcDbDirectory: /var/lib/ldap/griddynamics.net >> olcSuffix: dc=griddynamics,dc=net >> olcLastMod: TRUE >> olcMaxDerefDepth: 15 >> olcReadOnly: FALSE >> olcRootDN: cn=Manager,dc=griddynamics,dc=net >> olcMonitoring: TRUE >> olcDbDirtyRead: FALSE >> olcDbLinearIndex: FALSE >> olcDbMode: 384 >> olcDbSearchStack: 16 >> olcDbShmKey: 0 >> olcDbCacheFree: 1 >> olcDbDNcacheSize: 0 >> entryUUID: acc152ea-8b05-102d-8b71-fd81f30554e6 >> creatorsName: cn=config >> createTimestamp: 20090209145711Z >> structuralObjectClass: olcBdbConfig >> olcRootPW:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= >> olcAccess: {0}to >> attrs=userPassword,userPKCS12,sambaLMPassword,sambaNTPassword >> by sockurl.regex="^ldapi:///$" write by >> group.exact="cn=noc,ou=groups,dc=gr >> iddynamics,dc=net" write by self write by anonymous auth >> olcAccess: {1}to attrs=shadowLastChange by sockurl.regex="^ldapi:///$" >> write >> by group.exact="cn=noc,ou=groups,dc=griddynamics,dc=net" write by >> self wri >> te by * read >> olcAccess: {2}to * by sockurl.regex="^ldapi:///$" write by >> group.exact="cn=n >> oc,ou=groups,dc=griddynamics,dc=net" write by self write by * read >> olcDbIndex: default eq >> olcDbIndex: objectClass,entryUUID,entryCSN >> olcDbIndex: cn pres,eq,sub >> olcDbIndex: uid pres,eq,sub >> olcDbIndex: uidNumber pres,eq >> olcDbIndex: gidNumber pres,eq >> olcDbIndex: memberOf pres,eq >> olcDbIndex: ou pres,eq,sub >> olcDbIndex: mail pres,eq,sub >> olcDbIndex: loginShell pres,eq >> olcDbIndex: sn pres,eq,sub >> olcDbIndex: givenName pres,eq,sub >> olcDbIndex: memberUid pres,eq >> olcDbIndex: nisMapName pres,eq,sub >> olcDbIndex: nisMapEntry pres,eq,sub >> olcDbIndex: uniqueMember pres,eq >> olcDbIndex: gosaObject pres,eq >> olcDbIndex: zoneName pres,eq >> olcDbIndex: relativeDomainName pres,eq >> olcDbIndex: member pres,eq >> olcDbIndex: dhcpPrimaryDN pres,eq >> olcDbIndex: dhcpSecondaryDN pres,eq >> olcDbIndex: dhcpServerDN pres,eq >> olcDbIndex: dhcpFailOverPeerDN pres,eq >> olcDbIndex: dhcpHWAddress pres,eq >> olcDbNoSync: TRUE >> olcDbCheckpoint: 1024 5 >> olcDbCacheSize: 5000 >> olcDbIDLcacheSize: 5000 >> olcSyncrepl: {0}rid=001 >> provider=ldap://ldap-test1.carina.griddynamics.net bindmetho >> d=simple timeout=1 network-timeout=0 >> binddn="cn=manager,dc=griddynamics,dc=ne >> t" credentials="xxxxxxxxxxx" starttls=no filter="(objectclass=*)" >> searchbase="dc >> =griddynamics,dc=net" scope=sub schemachecking=off >> type=refreshAndPersist ret >> ry="10 +" >> olcDbConfig: {0}set_flags DB_LOG_AUTOREMOVE >> olcDbConfig: {1}set_cachesize 0 33554432 0 >> entryCSN: 20091121172900.646924Z#000000#001#000000 >> modifiersName: cn=config >> modifyTimestamp: 20091121172900Z >> >> >> Thanks in advance, >> > > > Where is your syncprov overlay, required to use syncrepl? > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

bindDN-rewriting - can't get to grips with overlays rwm+relay
by Thomas Wunder 15 Apr '10

15 Apr '10

Hi! I'm currently using the rwm overlay to filter the objects from my ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and project the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de Therefore I use the following section within my slapd.conf (before the "database hdb..." section): database relay suffix "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" overlay rwm #rwm-rewriteEngine on rwm-suffixmassage "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" "ou=students,dc=uni-bamberg,dc=de" rwm-rewriteContext bindDN rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" searchFilter rewriting works perfectly but I also need to rewrite the bindDN as every operation within ou=students,dc=uni-bamberg,dc=de needs to be carried out by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) (the reason is that i don't want any user other than ldapadmin to be able to write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy entries from ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) according to the logs and the error reply messages there seems to be no binndn rewriting done... It looks like the rule never matches. Is my rule not general enough to match each possible bindDN-String? Is "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) not well formatted (does it expect something else)? Does the overlay "relay" prevent the replacement of the bindDN? Any help appreciated! -- Lehrstuhl für Softwaretechnik und Programmiersprachen Fakultät WIAI, Universität Bamberg, 96045 Bamberg Email: thomas.wunder(a)swt-bamberg.de Web: http://www.swt-bamberg.de/ Tel.: 0951 863-3852 / Fax: 0951 863-3855

2 3

Re: Problems replicating deleted entries when slave is down.
by Quanah Gibson-Mount 15 Apr '10

15 Apr '10

Please keep replies on the list. Thanks. See the end of the email for my question. --On Thursday, April 15, 2010 4:50 PM +0400 Lior Goikhburg <mailing-lists(a)griddynamics.com> wrote: > Here are the configs: > > Master: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcConfigFile: slapd.conf.1 > olcConfigDir: slapd.d > olcArgsFile: /var/run/openldap/slapd.args > olcAttributeOptions: lang- > olcConcurrency: 0 > olcConnMaxPending: 100 > olcConnMaxPendingAuth: 1000 > olcGentleHUP: FALSE > olcIdleTimeout: 0 > olcIndexSubstrIfMaxLen: 4 > olcIndexSubstrIfMinLen: 2 > olcIndexSubstrAnyLen: 4 > olcIndexSubstrAnyStep: 2 > olcIndexIntLen: 4 > olcLocalSSF: 71 > olcPidFile: /var/run/openldap/slapd.pid > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcSaslSecProps: noplain,noanonymous > olcSockbufMaxIncoming: 262143 > olcSockbufMaxIncomingAuth: 16777215 > olcThreads: 16 > olcTLSCRLCheck: none > olcTLSVerifyClient: never > olcToolThreads: 1 > structuralObjectClass: olcGlobal > creatorsName: cn=config > entryUUID: b4deb404-8d67-102d-9826-65d8858906d8 > createTimestamp: 20090212154358Z > olcSaslHost: ldap-test1.carina.griddynamics.net > olcLogLevel: 0 > olcAuthzPolicy: to > olcAuthzRegexp: {0}uid=([^@]*)[@,].*cn=digest-md5,cn=auth > ldap:///dc=griddynam > ics,dc=net??sub?(uid=$1) > olcSizeLimit: 10000 > olcServerID: 1 ldap://ldap-test1.carina.griddynamics.net > entryCSN: 20091121171118.965511Z#000000#002#000000 > modifiersName: cn=config > modifyTimestamp: 20091121171118Z > contextCSN: 20100121080100.534901Z#000000#001#000000 > > dn: olcDatabase={2}bdb > objectClass: olcDatabaseConfig > objectClass: olcBdbConfig > olcDatabase: {2}bdb > olcDbDirectory: /var/lib/ldap/griddynamics.net > olcSuffix: dc=griddynamics,dc=net > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=griddynamics,dc=net > olcMonitoring: TRUE > olcDbDirtyRead: FALSE > olcDbLinearIndex: FALSE > olcDbMode: 384 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1 > olcDbDNcacheSize: 0 > entryUUID: acc152ea-8b05-102d-8b71-fd81f30554e6 > creatorsName: cn=config > createTimestamp: 20090209145711Z > structuralObjectClass: olcBdbConfig > olcRootPW:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= > olcAccess: {0}to > attrs=userPassword,userPKCS12,sambaLMPassword,sambaNTPassword > by sockurl.regex="^ldapi:///$" write by > group.exact="cn=noc,ou=groups,dc=gr > iddynamics,dc=net" write by self write by anonymous auth > olcAccess: {1}to attrs=shadowLastChange by sockurl.regex="^ldapi:///$" > write > by group.exact="cn=noc,ou=groups,dc=griddynamics,dc=net" write by > self wri > te by * read > olcAccess: {2}to * by sockurl.regex="^ldapi:///$" write by > group.exact="cn=n > oc,ou=groups,dc=griddynamics,dc=net" write by self write by * read > olcDbIndex: default eq > olcDbIndex: objectClass,entryUUID,entryCSN > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: uidNumber pres,eq > olcDbIndex: gidNumber pres,eq > olcDbIndex: memberOf pres,eq > olcDbIndex: ou pres,eq,sub > olcDbIndex: mail pres,eq,sub > olcDbIndex: loginShell pres,eq > olcDbIndex: sn pres,eq,sub > olcDbIndex: givenName pres,eq,sub > olcDbIndex: memberUid pres,eq > olcDbIndex: nisMapName pres,eq,sub > olcDbIndex: nisMapEntry pres,eq,sub > olcDbIndex: uniqueMember pres,eq > olcDbIndex: gosaObject pres,eq > olcDbIndex: zoneName pres,eq > olcDbIndex: relativeDomainName pres,eq > olcDbIndex: member pres,eq > olcDbIndex: dhcpPrimaryDN pres,eq > olcDbIndex: dhcpSecondaryDN pres,eq > olcDbIndex: dhcpServerDN pres,eq > olcDbIndex: dhcpFailOverPeerDN pres,eq > olcDbIndex: dhcpHWAddress pres,eq > olcDbNoSync: TRUE > olcDbCheckpoint: 1024 5 > olcDbCacheSize: 5000 > olcDbIDLcacheSize: 5000 > olcSyncrepl: {0}rid=001 > provider=ldap://ldap-test1.carina.griddynamics.net bindmetho > d=simple timeout=1 network-timeout=0 > binddn="cn=manager,dc=griddynamics,dc=ne > t" credentials="xxxxxxxxxxx" starttls=no filter="(objectclass=*)" > searchbase="dc > =griddynamics,dc=net" scope=sub schemachecking=off > type=refreshAndPersist ret > ry="10 +" > olcDbConfig: {0}set_flags DB_LOG_AUTOREMOVE > olcDbConfig: {1}set_cachesize 0 33554432 0 > entryCSN: 20091121172900.646924Z#000000#001#000000 > modifiersName: cn=config > modifyTimestamp: 20091121172900Z > > > Slave: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcConfigFile: slapd.conf.1 > olcConfigDir: slapd.d > olcArgsFile: /var/run/openldap/slapd.args > olcAttributeOptions: lang- > olcConcurrency: 0 > olcConnMaxPending: 100 > olcConnMaxPendingAuth: 1000 > olcGentleHUP: FALSE > olcIdleTimeout: 0 > olcIndexSubstrIfMaxLen: 4 > olcIndexSubstrIfMinLen: 2 > olcIndexSubstrAnyLen: 4 > olcIndexSubstrAnyStep: 2 > olcIndexIntLen: 4 > olcLocalSSF: 71 > olcPidFile: /var/run/openldap/slapd.pid > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcSaslSecProps: noplain,noanonymous > olcSockbufMaxIncoming: 262143 > olcSockbufMaxIncomingAuth: 16777215 > olcThreads: 16 > olcTLSCRLCheck: none > olcTLSVerifyClient: never > olcToolThreads: 1 > structuralObjectClass: olcGlobal > creatorsName: cn=config > entryUUID: b4deb404-8d67-102d-9826-65d8858906d8 > createTimestamp: 20090212154358Z > olcSaslHost: ldap-test1.carina.griddynamics.net > olcLogLevel: 0 > olcAuthzPolicy: to > olcAuthzRegexp: {0}uid=([^@]*)[@,].*cn=digest-md5,cn=auth > ldap:///dc=griddynam > ics,dc=net??sub?(uid=$1) > olcSizeLimit: 10000 > olcServerID: 1 ldap://ldap-test1.carina.griddynamics.net > entryCSN: 20091121171118.965511Z#000000#002#000000 > modifiersName: cn=config > modifyTimestamp: 20091121171118Z > contextCSN: 20100121080100.534901Z#000000#001#000000 > > dn: olcDatabase={2}bdb > objectClass: olcDatabaseConfig > objectClass: olcBdbConfig > olcDatabase: {2}bdb > olcDbDirectory: /var/lib/ldap/griddynamics.net > olcSuffix: dc=griddynamics,dc=net > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=griddynamics,dc=net > olcMonitoring: TRUE > olcDbDirtyRead: FALSE > olcDbLinearIndex: FALSE > olcDbMode: 384 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1 > olcDbDNcacheSize: 0 > entryUUID: acc152ea-8b05-102d-8b71-fd81f30554e6 > creatorsName: cn=config > createTimestamp: 20090209145711Z > structuralObjectClass: olcBdbConfig > olcRootPW:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= > olcAccess: {0}to > attrs=userPassword,userPKCS12,sambaLMPassword,sambaNTPassword > by sockurl.regex="^ldapi:///$" write by > group.exact="cn=noc,ou=groups,dc=gr > iddynamics,dc=net" write by self write by anonymous auth > olcAccess: {1}to attrs=shadowLastChange by sockurl.regex="^ldapi:///$" > write > by group.exact="cn=noc,ou=groups,dc=griddynamics,dc=net" write by > self wri > te by * read > olcAccess: {2}to * by sockurl.regex="^ldapi:///$" write by > group.exact="cn=n > oc,ou=groups,dc=griddynamics,dc=net" write by self write by * read > olcDbIndex: default eq > olcDbIndex: objectClass,entryUUID,entryCSN > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: uidNumber pres,eq > olcDbIndex: gidNumber pres,eq > olcDbIndex: memberOf pres,eq > olcDbIndex: ou pres,eq,sub > olcDbIndex: mail pres,eq,sub > olcDbIndex: loginShell pres,eq > olcDbIndex: sn pres,eq,sub > olcDbIndex: givenName pres,eq,sub > olcDbIndex: memberUid pres,eq > olcDbIndex: nisMapName pres,eq,sub > olcDbIndex: nisMapEntry pres,eq,sub > olcDbIndex: uniqueMember pres,eq > olcDbIndex: gosaObject pres,eq > olcDbIndex: zoneName pres,eq > olcDbIndex: relativeDomainName pres,eq > olcDbIndex: member pres,eq > olcDbIndex: dhcpPrimaryDN pres,eq > olcDbIndex: dhcpSecondaryDN pres,eq > olcDbIndex: dhcpServerDN pres,eq > olcDbIndex: dhcpFailOverPeerDN pres,eq > olcDbIndex: dhcpHWAddress pres,eq > olcDbNoSync: TRUE > olcDbCheckpoint: 1024 5 > olcDbCacheSize: 5000 > olcDbIDLcacheSize: 5000 > olcSyncrepl: {0}rid=001 > provider=ldap://ldap-test1.carina.griddynamics.net bindmetho > d=simple timeout=1 network-timeout=0 > binddn="cn=manager,dc=griddynamics,dc=ne > t" credentials="xxxxxxxxxxx" starttls=no filter="(objectclass=*)" > searchbase="dc > =griddynamics,dc=net" scope=sub schemachecking=off > type=refreshAndPersist ret > ry="10 +" > olcDbConfig: {0}set_flags DB_LOG_AUTOREMOVE > olcDbConfig: {1}set_cachesize 0 33554432 0 > entryCSN: 20091121172900.646924Z#000000#001#000000 > modifiersName: cn=config > modifyTimestamp: 20091121172900Z > > > Thanks in advance, Where is your syncprov overlay, required to use syncrepl? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Problems replicating deleted entries when slave is down.
by Lior Goikhburg 14 Apr '10

14 Apr '10

Hello, I'm having problem with 2 OpenLDAP (ver 2.4.21) servers acting as "master" and "slave" using "refresh and persist" synchronization. When both servers are up, all changes get replicated (including deletes), however when slave is down and objects get deleted on master, they are not deleted on the slave after it comes up. Also, an interesting issue I noticed, deleting object on master doesn't change the servers contextCSN, so this could be related to the problem I have. What can be done about this situation? Thanks in advance for your advice, Lior Goikhburg.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software April 2010