openldap-software

openldap-software@openldap.org

2719 discussions

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 15 Apr '10

15 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

back-ldap and CLOSE_WAIT
by Hugo Monteiro 14 Apr '10

14 Apr '10

Hello list, I have an ldap server acting as proxy, through back-ldap, to another ldap server which holds the data. These servers are in distinct networks and connections are all routed through a firewall. Both proxy and backend servers are running openldap version 2.4.17 (from debian testing/sid). Everything is working fine except that from time to time the proxy server has trouble responding requests. These anomalies happen not very often and for very short periods of time, usually from a couple of seconds to ten seconds. Although things keep working, it's rather annoying for the end user to have its interaction with a system delayed or denied, even if for such short periods. Both system loads, from the proxy and the backend server, appear to be fine and i have no reason to believe that it's a matter of system resources shortness. I can observe though a rather large number of connections (usually from 1k to 2k), from the proxy server to the backend server, in CLOSE_WAIT state. Both servers have set an idletimeout value of 30 seconds and i was to expect that the unused connections would seize to exist after that period of time. Basically i want to know if this number of connections is normal, taking in consideration that most queries and performed anonymously and i'm quite positive that there aren't more than a couple hundred of authenticated binds simultaneously. What steps can i take to reduce this behavior? Thank you all in advance, Hugo Monteiro. -- fct.unl.pt:~# cat .signature Hugo Monteiro Email : hugo.monteiro(a)fct.unl.pt Telefone : +351 212948300 Ext.15307 Web : http://hmonteiro.net Divisão de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.fct.unl.pt apoio(a)fct.unl.pt fct.unl.pt:~# _

1 0

Slave connecting to maser always stay connected?
by Mathew Rowley 13 Apr '10

13 Apr '10

I have a setup with 2 masters (nway multimaster) and 4 slaves each having syncrepl set up to connect to the 2 masters. The question I have, with the following configuration (on the slaves) should they always be connected to the masters? Netstat is showing that the connections are intermittent: type=refreshAndPersist retry="60 +" Netstat on the masters shows that the connections from the slaves will vary sometimes 0, sometimes 4 seems to be somewhat random. We are trying to determine if there is something wrong in our network. Thanks for the help. MAT

3 6

Re:ACLs - allowing a user to add a new attribute
by Sergiy Stepanenko 13 Apr '10

13 Apr '10

I agree about userPassword Something like that can restrict access to it access to attrs=userPassword by anonymous auth by * none -- Sergiy Stepanenko Systems Administrator Information Technology Services University of Saskatchewan ----------------------------------- phone: (306) 966-2762 email:sergiy.stepanenko@usask.ca

1 0

ppolicy_hash_cleartext "recommendation" ?
by Jesús Couto 13 Apr '10

13 Apr '10

Hi all. I've set up an openLDAP directory with the password policy overlay and the ppolicy_hash_cleartext option to ensure cleartext passwords get hashed (as my client request). But the slapo-ppolicy man page clearly states: "It is recommended that when this option is used that compare, search, and read access be denied to all directory users." Its this warning about the userPassword attribute only? That is, more or less, the standard configuration, not even the user can read his password, only write. Or this warning applies to all the directory (bit too much?) Any reason for this warning in particular here? I mean, not letting anybody but the rootdn see the userPassword attribute is a good idea anyway, any particular reason why enabling ppolicy_hash_cleartext makes its extra-good? Best regards, ------------------------------ Jesús Couto F.

1 0

Re: Problems witch dynacl/now=<=...
by masarati＠aero.polimi.it 10 Apr '10

10 Apr '10

> Am 10.04.10 00:03 schrieb "masarati(a)aero.polimi.it" unter > <masarati(a)aero.polimi.it>: > >>> Hi, >>> >>> I am trying to use the >>> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-05.1.c> >>> dynacl >>> module with slapd 2.4.11 (from debian). >>> >>> >>> access to dn.children="dc=dg-i,dc=net" >>> by dynacl/now=>=auditTimestamp none >>> by dynacl/now=<=auditTimestamp none >>> by group.exact="cn=Readers,...." read >> >> Yes. I think you did not understand the logic behind the ACI access >> granting mechanism. When you write >> >> by dynacl/now=>=auditTimestamp none >> >> the "none" indicates how much privilege you allow this rule to give. >> Then, if the rule matches, the privilege is given, otherwise it is not. >> This was designed because ACIs were much more granular that the "now" >> dynacl. Think of this dynacl as something that gives a boolean >> (match/nomatch). If true, the access level will be granted, otherwise >> denied. So, if you have an attribute "validityStarts" and another >> "validityEnds", and you want to allow "read" access to entries that are >> in >> between the validity interval, you'd need to do >> >> access to <what> >> by dynacl/now=">=validityStarts" <level> break >> >> access to <what> >> by dynacl/now="<=validityEnds" <level> > > What I am trying to do is I want to deny access to for Users who either > are > noty yet valid or are expired. > > access to <what> > by dynacl/now="<=validityStarts" none > by dynacl/now=">=validityEnds" none > > > Would this deny Users that are not valid or expired ? If it were fine, it would work as expected. Do you see any resemblance between this and what I wrote above? Personally, I don't. By setting <level> to "none" you're telling dynacl to ignore those rules (line 1772 of slapd/acl.c). That's why now_dynacl_mask() is not even invoked. p.

1 0

Problems witch dynacl/now=<=...
by Manon Goo 10 Apr '10

10 Apr '10

Hi, I am trying to use the <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-05.1.c> dynacl module with slapd 2.4.11 (from debian). The module seams to initialize correctly but the "now_dynacl_mask" function is never called. my testing ACL looks like: access to dn.children="dc=dg-i,dc=net" by dynacl/now=>=auditTimestamp none by dynacl/now=<=auditTimestamp none by group.exact="cn=Readers,...." read This should allways fail but it does not. it read access is grants to the object for members of the group. Is the module intended for use with 2.4 ? Thanks Manon Manon Goo Dembach Goo Informatik GmbH & Co KG Untersachsenhausen 33 D-50667 Köln Tel: +49 221 801483 0 Mobil: +49 177 8091974 Fax: +49 221 801483 20 Email: manon(a)dg-i.net Emergency: +49 180 555 4992 Amtsgericht Köln HRA 22794, UST ID: DE242 159 527 Geschäftsführer: Manon Goo, Andreas Dembach Haftende Gesellschafterin: Dembach Goo Verwaltungs GmbH

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
272
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software