openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

slapd 2.4.33 changes 'dc' to 'ou' after cn=schema,cn=config modification
by Igor Zinovik 30 Apr '13

30 Apr '13

Hello. I'm running openldap 2.4.33 with on-line configuration (slapd-config). Before running slapd with on-line configuration i developed my own schema and after that i converted old fashioned slapd.conf to slapd.d. Today i modified one attribute in my schema from this: olcAttributeTypes: {9}( 2.16.840.1.113730.3.1.217 NAME 'spamassassin' DESC 'Sp amAssassin user preferences settings' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) to this olcAttributeTypes: {9}( 2.16.840.1.113730.3.1.217 NAME 'spamassassin' DESC 'Sp amAssassin user preferences settings' SUP name ) I was binded to cn=config with DN that is not part of that tree, my dn was uid=zinovik,ou=people,dc=...,dc=ru So after that change i noticed that i see following messages while running slaptest: ldap1:~ $ sudo slaptest -vF /etc/openldap/slapd.d 51800ba4 PROXIED attributeDescription "OU" inserted. 51800ba4 PROXIED attributeDescription "DC" inserted. config file testing succeeded I pointed out that this happened because i modified entries in cn=config with modifierName not being part of cn=config namespace. But that is not a problem. Problem happens when i do following ldap1:~ $ cat example.com.ldif dn: dc=example.com,ou=Mail,dc=...,dc=ru objectClass: top objectClass: domain objectClass: amavisAccount dc: example.com amavisLocal: TRUE ldap1:~ $ ldapadd -v -ZZxWD uid=zinovik,ou=people,dc=...,dc=ru -f example.com.ldif add objectClass: top domain amavisAccount add dc: example.com add amavisLocal: TRUE adding new entry "dc=example.com,ou=Mail,dc=...,dc=ru" modify complete ldap1:~ $ ldapsearch -LLLZZxWD uid=zinovik,ou=people,dc=...,dc=ru -b ou=Mail,dc=...,dc=ru -s one '(&)' Enter LDAP Password: dn: dc=example.com,ou=Mail,dc=...,dc=ru objectClass: top objectClass: domain objectClass: amavisAccount ou: example.com amavisLocal: TRUE Why i do not see 'dc' attribute in this entry and why 'ou' appeared? Trace of this operation: 51800cc6 >>> dnPrettyNormal: <dc=example.com,ou=Mail,dc=...,dc=ru> 51800cc6 <<< dnPrettyNormal: <dc=example.com,ou=Mail,dc=...,dc=ru>, <dc=example.com,ou=mail,dc=...,dc=ru> 51800cc6 ==> unique_add <dc=example.com,ou=Mail,dc=...,dc=ru> 51800cc6 oc_check_required entry (dc=example.com,ou=Mail,dc=...,dc=ru), objectClass "domain" 51800cc6 oc_check_required entry (dc=example.com,ou=Mail,dc=...,dc=ru), objectClass "amavisAccount" 51800cc6 oc_check_allowed type "objectClass" 51800cc6 oc_check_allowed type "dc" 51800cc6 oc_check_allowed type "amavisLocal" 51800cc6 oc_check_allowed type "structuralObjectClass" 51800cc6 mdb_dn2entry("dc=example.com,ou=mail,dc=...,dc=ru") 51800cc6 => mdb_dn2id("dc=example.com,ou=mail,dc=...,dc=ru") 51800cc6 <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798) 51800cc6 => mdb_entry_decode: 51800cc6 <= mdb_entry_decode 51800cc6 mdb_dn2entry("cn=ldap admins,ou=groups,dc=...,dc=ru") 51800cc6 => mdb_dn2id("cn=ldap admins,ou=groups,dc=...,dc=ru") 51800cc6 <= mdb_dn2id: got id=0xfab 51800cc6 => mdb_entry_decode: 51800cc6 <= mdb_entry_decode 51800cc6 mdb_entry_get: rc=0 51800cc6 => mdb_dn2id_add 0x1f19: "dc=example.com,ou=mail,dc=...,dc=ru" 51800cc6 <= mdb_dn2id_add 0x1f19: 0 51800cc6 => index_entry_add( 7961, "dc=example.com,ou=Mail,dc=...,dc=ru" ) 51800cc6 <= index_entry_add( 7961, "dc=example.com,ou=Mail,dc=...,dc=ru" ) success 51800cc6 => mdb_entry_encode(0x00001f19): dc=example.com,ou=Mail,dc=...,dc=ru 51800cc6 <= mdb_entry_encode(0x00001f19): dc=example.com,ou=Mail,dc=...,dc=ru 51800cc6 mdb_add: added id=00001f19 dn="dc=example.com,ou=Mail,dc=...,dc=ru" 51800cc6 send_ldap_result: conn=1000 op=2 p=3 When i try to modify attribute: dn: dc=example.com,ou=Mail,dc=...,dc=ru changetype: modify add: dc dc: example.com I get: modifying entry "dc=example.com,ou=Mail,dc=...,dc=ru" ldap_modify: Object class violation (65) additional info: attribute 'ou' not allowed Even my root object lost its 'dc' attribute somehow: ldap1: ~$ ldapsearch -LLLZZxWD uid=zinovik,ou=people,dc=...,dc=ru -b dc=...,dc=ru -s base '(&)' dn: dc=...,dc=ru ou: ... objectClass: organization objectClass: dcObject o: my organization If it matters i use slapd-mdb as storage backend. I did not changed 'dc' and 'ou': ldap1:~ $ ldapsearch -LLLZZxWD uid=zinovik,ou=people,dc=...,dc=ru -b 'cn={0}core,cn=schema,cn=config' '(&)' olcAttributeTypes|egrep -e "'(ou|dc)'" Enter LDAP Password: olcAttributeTypes: {8}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC ' olcAttributeTypes: {49}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone I do not use slapo-rwm. Here are my overlays for dc=...,dc=ru: dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {1}refint olcRefintAttribute: seeAlso olcRefintAttribute: uniqueMember olcRefintAttribute: member olcRefintNothing: cn=EMPTY dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {2}unique olcUniqueURI: ldap:///ou=Hosts,dc=...,dc=ru?ipHostNumber?sub olcUniqueURI: ldap:///ou=People,dc=...,dc=ru?uid,uidNumber?sub olcUniqueURI: ldap:///ou=Groups,dc=...,dc=ru?cn,gidNumber?sub olcUniqueURI: ldap:///ou=Mail,dc=...,dc=ru?mail,mailLocalAddress?sub dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig olcOverlay: {3}syncprov olcSpCheckpoint: 200 20 olcSpSessionlog: 100

1 0

slapschema and slapd-mdb
by Igor Zinovik 30 Apr '13

30 Apr '13

Hello. Is it safe to run slapschema with slapd-mdb(5) (while slapd is running in r/w mode)?

1 0

replicating a special objectclass with a seperate syncrepl statement
by Al 30 Apr '13

30 Apr '13

Hi, I am wondering if it is possible to have two syncrepl statements on a consumer that pull from the same source, but do so with a different set of parameters and filters that ensure their is no overlap. Below is an example of what I am interested in trying: olcSyncRepl: rid=001 provider=ldap://server1.example.com binddn="MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshAndPersist retry="5 5 300 5" timeout=1 filter="(!(objectclass=mygroup))" olcSyncRepl: rid=002 provider=ldap://server1.example.com binddn="MANAGERDN" bindmethod=simple credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly interval=00:00:10:00 retry="5 5 300 5" timeout=1 filter="(objectclass=mygroup)" Basically, I am interested in syncing certain groups occasionally (they have a custom objectclass), but everything else as quickly as possible. Thanks! Al

1 0

Chaining stops working after slapd restart
by jeevan kc 29 Apr '13

29 Apr '13

Hi, I am trying to setup a chain overlay to allow writes to a read-only slave to be chained up to the master. dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=configchangetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDBURI: ldap://10.1.0.3/ olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=********** mode=self This works until I have to restart the slave ldap server. Can anyone help me fix this problem?

2 1

slow replication
by Meike Stone 29 Apr '13

29 Apr '13

Hello, I've a problem with the speed of replication. I've set up openldap 2.4.33 with a Master and one consumer. At the moment the full replaction takes abaout 32hours. No LDAP operations are made on master or consumer during this time. (I know, i depends on Hardware too, but the two servers are fast ) How long should it need, to replicate a DB from about 6GByte (id2entry.bdb + dn2id.bdb) with 1.6M DN's and about 66M Attributes. Replication is configured with RefreshAndPersist, no DeltaSync. Both servers are on the same IP segment, connected via gigabit ethernet switch. I played in test environment with different parameters: - shm_key - dbnosync - switched off all indexes on consumer except entryUUID and entryCSN - different bdb cachesize - noatime, relatime - ext3/xfs I locked on disk via iostat (nothing seen), no io waits with top, looked on network, but max 5Mbit/s is used, I listen with strace on slapd and I see, that slapd is reading from Network and wrinting it to id2entiry.bdb. Before each Test, I deleted complete ldap db (except DB_CONFIG) and shared memory ipcrm -m Are there similar limitations, that will trigger slow replication like BDB_IDL_LOGN? How can I accelerate this Replication. I'm of the opinion that it was significantly faster with a smaller database. Thanks and kindly regards Meike Configuration: -------------------- Configuration is only a test configuration, some values differs, some are commented out because of playing with them. # Master (Provider) ========================================================== include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/rfc2307bis.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov sizelimit -1 timelimit 300 tool-threads 8 threads 8 serverID 001 ######################################## database bdb suffix "ou=root" rootdn "cn=admin,ou=root" #loglevel stats sync loglevel 0 rootpw <password> directory /DATA/ldap #cachesize 500000 #dncachesize 500000 #idlcachesize 150000 cachefree 500 dirtyread dbnosync shm_key 7 checkpoint 4096 15 index objectClass,entryUUID,entryCSN eq index cn eq,sub index ownattributes .... overlay syncprov syncprov-checkpoint 100 5 # Consumer ========================================================== include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/rfc2307bis.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_bdb moduleload syncprov sizelimit -1 timelimit 300 serverID 002 #loglevel stats sync loglevel 0 ######################################## database bdb suffix "ou=root" rootdn "cn=admin,ou=root" checkpoint 4096 15 rootpw <password> directory /DATA/ldap dbnosync shm_key 7 checkpoint 4096 15 #cachesize 100000 #dncachesize 100000 #idlcachesize 150000 #cachefree 500 #dirtyread syncrepl rid=020 provider=ldap://192.168.1.10 type=refreshAndPersist retry="5 5 300 +" searchbase="ou=root" attrs="*,+" bindmethod=simple binddn="cn=admin,ou=root" credentials=<password> index entryUUID,entryCSN eq #index cn eq,sub mirrormode FALSE

3 5

translucent overlay and memberof overlay together?
by Steve Eckmann 29 Apr '13

29 Apr '13

Are the translucent and memberof overlays supposed to work together? I have one mdb backend with "native" accounts, and another mdb backend for "remote" accounts using the translucent overlay to proxy a remote AD. I want to be able to add remote account entries to groups in the native branch and have a memberof attribute automatically instantiated in the already added local entry associated with the remote entry. That isn't happening, and what I see in the log is something like: memberof_value_modify DN="cn=xxx,ou=users,ou=remote,dc=example,dc=com" add myMemberOf="cn=myGroup,ou=Groups,ou=Native,dc=example,dc=com" failed err=32 The local objectClass for user entries has myMemberOf as a DN-valued attribute (I tried using the builtin "memberOf", but when that didn't work I thought there might be a conflict between the remote attribute name and the local attribute name). I have the memberof overlay applied to both mdb backends. I guess what I'm trying to do is going across backends. Is that an incorrect/unsupported use of the memberof overlay? Thanks. Steve

1 0

back-sql: restart slapd while new entry ldap_entries view
by hornuda 27 Apr '13

27 Apr '13

Hello, I set up a openldap-server with postgresql backend. Everything works fine but: On http://www.wingfoss.com/content/sample-mysql-for-openldap-back-sql you can read you have to restart the slapd server everytime you change one of the ldap_* tables. But my ldap_entries table is a view but I also have to restart slapd, is this a normal behavior? Thank you! hornuda

1 0

Issue with delta-sync multimaster
by Al 26 Apr '13

26 Apr '13

Hi All, I just recently migrated to a new OpenLDAP environment, and am experiencing an occasional issue. I am using 2.4.35 and Redhat 6 - x64 with OpenLDAP compiled and packaged locally. I have setup multimaster using delta-sync with MDB being utilized for both the user data as well as the access log. This environment is fronted by a load balancer, so traffic is directed to a single server. A couple of times an hour, I get the following error in the log on the second server: -------------------- Apr 25 13:52:19 server2 slapd[15648]: null_callback : error code 0x10 Apr 25 13:52:19 server2 slapd[15648]: syncrepl_message_to_op: rid=011 be_modify cn=USER123,cn=users,cn=domain,cn=com (16) -------------------- After this error, the second server goes into refresh mode and gets a fresh copy. It would appear that this error relates to the ppolicy overlay as the entries in the access log at the time of error shows the pwdFailureTime being removed during a password reset. I do see the pwdFailureTime being set in the access log earlier too, so the data should be there (even though the error code indicates no such attribute). I was luckily able to catch a bunch of debug logging while the issue occured. I have attempted to strip out some useful information, but I have a very large file with more data in it if neccessary. -------------------- 517967bc mdb_modify_internal: 0x000197ed: cn=USER123,cn=users,cn=domain,cn=com 517967bc <= acl_access_allowed: granted to database root 517967bc mdb_modify_internal: replace userPassword 517967bc mdb_modify_internal: replace pwdChangedTime 517967bc mdb_modify_internal: softdel pwdFailureTime 517967bc mdb_modify_internal: replace entryCSN 517967bc mdb_modify_internal: replace modifiersName 517967bc mdb_modify_internal: replace modifyTimestamp 517967bc mdb_modify_internal: delete pwdFailureTime 517967bc mdb_modify_internal: 16 modify/delete: pwdFailureTime: no such attribute 517967bc mdb_modify: modify failed (16) 517967bc send_ldap_result: conn=-1 op=0 p=3 517967bc send_ldap_result: err=16 matched="" text="modify/delete: pwdFailureTime: no such attribute" 517967bc null_callback : error code 0x10 517967bc slap_graduate_commit_csn: removing 0x7fc7ec1bc300 20130425172817.060117Z#000000#001#000000 517967bc syncrepl_message_to_op: rid=011 be_modify cn=USER123,cn=users,cn=domain,cn=com (16) ... 517967bc do_syncrep2: rid=011 delta-sync lost sync on (reqStart=20130425172817.000023Z,cn=accesslog), switching to REFRESH -------------------- Here is the important parts of my config - the configs are mirrored - so its the same on all: -------------------- dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /u01/openldap/live2/var/openldap-data olcSuffix: cn=domain,cn=com olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.base="cn=ldapreplicator,cn=systems,cn=domain,cn=com " size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=un limited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,cn=domain,cn=com olcRootPW:: NONONO olcSyncUseSubentry: FALSE olcMirrorMode: TRUE olcMonitoring: TRUE olcDbCheckpoint: 512 5 olcDbNoSync: TRUE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: uniqueMember eq olcDbIndex: nisNetgroupTriple eq olcDbIndex: sudoUser eq,sub olcDbMaxSize: 25000000000 olcDbMode: 0600 structuralObjectClass: olcMdbConfig entryUUID: a12ed549-25c6-4424-8c4f-fe63eed54ba2 creatorsName: cn=config createTimestamp: 20111014131247Z olcSyncrepl: {0}rid=011 provider=ldap://server1.company.com:21389/ bind method=simple timeout=1 network-timeout=1 binddn="cn=ldapreplicator,cn=system s,cn=domain,cn=com" credentials="NONONONO" keepalive=0:0:0 startt ls=critical filter="(objectclass=*)" searchbase="cn=domain,cn=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase="cn=access log" scope=sub schemachecking=off type=refreshAndPersist interval=00:00:00:05 retry="30 +" syncdata=accesslog olcSyncrepl: {1}rid=012 provider=ldap://server2.company.com:21389/ bind method=simple timeout=1 network-timeout=1 binddn="cn=ldapreplicator,cn=system s,cn=domain,cn=com" credentials="NONONO" keepalive=0:0:0 startt ls=critical filter="(objectclass=*)" searchbase="cn=domain,cn=com" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase="cn=access log" scope=sub schemachecking=off type=refreshAndPersist interval=00:00:00:05 retry="30 +" syncdata=accesslog entryCSN: 20130425161500.179131Z#000000#001#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20130425161500Z dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig entryUUID: 9a4fbba8-fbe8-4f89-a64f-f20d66023a8a creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20130425004117.389246Z#000000#001#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20130425004117Z dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 7+00:00 1+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 7e12de76-e7fd-4fb2-83f5-46bb58363dd9 creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20111019170537.715510Z#000000#000#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20111019170537Z dn: olcOverlay={2}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {2}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE structuralObjectClass: olcPPolicyConfig entryUUID: c9b15bd3-ae80-42f7-b355-31acebcc941f creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20111014131247.731074Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20111014131247Z dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {3}memberof olcMemberOfRefInt: FALSE olcMemberOfGroupOC: groupOfUniqueNames olcMemberOfMemberAD: uniquemember structuralObjectClass: olcMemberOf entryUUID: 370bc13f-ae2a-4082-945d-7e6778967400 creatorsName: cn=Manager,cn=config createTimestamp: 20121001170641Z entryCSN: 20121001170641.572227Z#000000#000#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20121001170641Z dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /u01/openldap/live2/var/accesslog-data olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.base="cn=manager,cn=company, cn=com" read by dn.base="cn=ldapreplicator,cn=systems,cn=company,cn=com" read by group/groupOfUniqueNames/uniqueMember.exact="cn=ldap_ admins,cn=ldap,cn=groups,cn=domain,cn=com" read by * none olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.base="cn=ldapreplicator,cn=systems,cn=domain,cn=com " size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=un limited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbNoSync: TRUE olcDbIndex: default eq olcDbIndex: objectClass eq olcDbIndex: entryCSN eq olcDbIndex: reqStart eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqDN eq olcDbMaxSize: 25000000000 olcDbMode: 0600 structuralObjectClass: olcMdbConfig entryUUID: 76907acf-5c8e-4650-9b36-023da1655a81 creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20130424144439.664389Z#000000#001#000000 modifiersName: cn=Manager,cn=config modifyTimestamp: 20130424144439Z dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: d6cadc16-c4f7-4daf-9a6b-9a37db55ca91 creatorsName: cn=config createTimestamp: 20111014131247Z entryCSN: 20111014131247.731074Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20111014131247Z -------------------- Thank you in advance for any help you might be able to offer. AL

2 3

Reduce the influence of ldap server trouble
by Yuki Takase 26 Apr '13

26 Apr '13

Hi all I'm a beginner of openldap. When I can't use a ldap server because of hardware or network trouble, I want to reduce the influence of ldap client. I changed the following configration of ldap.conf. bind_policy soft bind_timelimit 10 nss_initgroups_ignoreusers [local users...] Are there other solutions to reduce the influence? I use WebSphereMQ on Linux server. I added MQ's startup user 'mqm' to nss_initgroups_ignoreusers. But WebSphereMQ's startup command 'strmqm' always tries to connect to a ldap server. (I think that's a specification.) I use a ldap server to authentification of server maintenance members. But in some case such as above is it better not to use ldap?

2 1

hdb and mdb dereferencing aliases differently
by Juergen.Sprenger＠swisscom.com 26 Apr '13

26 Apr '13

Hi Michael, NSS results must not be dependent on the backend database a directory service uses. I activated connection logging and here's the proof that NSS is not the culprit. Searches initiated by NSS are identical and exactly this behavior can also be seen when using ldapsearch from command line with parameters from the log: # running 'getent passwd' with hdb backend: Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=656 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection lost) # running 'getent passwd' with mdb backend: Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection lost) I suspect that aliases are not handled the same way in hdb and mdb as I am using aliases here and deref=3 in both searches, example: dn: uid=joe,ou=Account,dc=its,dc=scom objectClass: alias objectClass: extensibleObject uid: joe aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom structuralObjectClass: alias When using hdb, the alias is dereferenced correctly (nentries=656), when using mdb it seems not to be dereferenced at all (nentries=0). Maybe there's a parameter around for mdb which I couldn't find in the docs to prevent this, but if not I consider this as a bug. Regards Juergen michael(a)stroeder.com wrote: >It would certainly help if you could examine the issue with pure LDAP search >operations preferably with OpenLDAP's ldapsearch command-line tool. > >When looking at NSS results too many things can go wrong with other >components' configuration. > >Ciao, Michael. > >Juergen.Sprenger(a)swisscom.com wrote: >> Hi, >> >> I have running OpenDLAP 2.4.35 on Gentoo Linux and wanted to make some tests with mdb. >> >> Slapd was running fine with hdb, no problems so far. >> Then I exported contents via slapcat and switched config to mdb. >> When slapd started using mdb no users from directory were shown by 'getent passwd': >> >> ### hdb part #### >> # using hdb parameters >> database hdb >> dirtyread >> cachesize 150000 >> cachefree 100 >> idlcachesize 450000 >> dncachesize 100000 >> >> # slapadd from backup and run slapd with hdb backend >> /etc/init.d/unscd stop >> /etc/init.d/slapd stop >> rm /var/lib/openldap-data/* >> rm -rf /etc/openldap/slapd.d/* >> cp -p /etc/openldap/DB_CONFIG /var/lib/openldap-data/ >> cp -p /etc/openldap/slapd.conf.hdb /etc/openldap/slapd.conf >> su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' >> /etc/init.d/slapd start >> /etc/init.d/unscd start >> slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum >> # 73850f9a3f7ff9d3d1ddb7663cd046a6 - >> >> getent passwd >> # all users shown, everything ok >> >> ### mdb part #### >> # using mdb paramters >> database mdb >> dbnosync >> maxsize 2094967296 >> searchstack 64 >> >> # slapadd from backup and run slapd with mdb backend >> /etc/init.d/unscd stop >> /etc/init.d/slapd stop >> rm /var/lib/openldap-data/* >> rm -rf /etc/openldap/slapd.d/* >> cp -p /etc/openldap/slapd.conf.mdb /etc/openldap/slapd.conf >> su ldap -c '/usr/sbin/slapadd -f /etc/openldap/slapd.conf -l odsldap-dev.ldif' >> /etc/init.d/slapd start >> /etc/init.d/unscd start >> slapcat -f /etc/openldap/slapd.conf -b dc=scom | md5sum >> # 73850f9a3f7ff9d3d1ddb7663cd046a6 - <> >> getent passwd >> # no users from ldap shown >> >> Am I missing something when setting up and using mdb? >> Both backends have exactly the same content, and so the results for searches should also be identical. >> >> Regards >> >> Jürgen Sprenger

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical