openldap-technical

openldap-technical@openldap.org

11 participants
9876 discussions

retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 23 Jul '11

23 Jul '11

While trying to determine how syncrepl behaves in various error conditions, I encountered an unexpected behaviour in which the retry specification doesn't seem to work. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" When I stop the REPLICA and add an entry on the MASTER, then the MASTER is retrying every 5s and claims that 4 (sometimes 3) retries are left: Jul 22 13:12:52 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:07 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:17 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:22 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:28 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:33 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:38 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:43 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:48 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:53 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:58 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) When I start REPLICA again, syncrepl succeeds. Do I have to set some other option such that the retry specification is actually used? That is, try every 5s for 5 times, then try every 60s. Or is the retry logic dependent on the error syncrepl encounters? The full log for one failed retry is: conn=1004 op=0 BIND dn="cn=manager" method=128 conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 conn=1004 op=0 RESULT tag=97 err=0 text= conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1004 op=1 SRCH attr=* + srs csn 20110722201233.471069Z#000000#001#000000 log csn 20110722201233.471069Z#000000#001#000000 cmp 0, too old log csn 20110722201252.820971Z#000000#001#000000 Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) syncrepl_entry: rid=001 be_search (52) syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com null_callback : error code 0x34 syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) do_syncrepl: rid=001 rc 52 retrying (4 retries left) conn=1004 op=2 UNBIND conn=1004 fd=15 closed connection_read(15): no connection! connection_read(15): no connection!

2 1

Kerberos with LDAP backend: password sync
by Nick Milas 22 Jul '11

22 Jul '11

Hello, We've been using OpenLDAP for all major services (mainly mail, Shibboleth, web service authentication etc.) based on authentication over the standard userPassword attribute (and uid as the username) of the person objectClass. Now, for particular authentication needs (because particular applications - like SQUID - do not support the standard PLAIN auth over TLS/SSL which we usually use), we consider installing Kerberos using our LDAP server as backend. Such a setup is meant to continue to allow the standard PLAIN auth over TLS/SSL (directly by LDAP) in some applications and provide Kerberos authentication in others, based on the same user/password database (stored and maintained in LDAP). [I know that in many environments, userPassword and krbPrincipalKey are deliberately different.] Generally, the Kerberos installation and user administration process involves creating Principals (krbPrincipalName) and Principal Keys (krbPrincipalKey). My question: Is there a way to automatically populate (either internally, via LDAP configuration, or externally, by running - for example - an external script) the values of krbPrincipalName and krbPrincipalKey attributes, so that these values can be produced by the values of the currently used attributes (uid, userPassword, including possibly others.)? This would allow initial creation of values for the above attributes using the same password value. Here: https://help.ubuntu.com/10.04/serverguide/C/kerberos-ldap.html I have found a quite descriptive tutorial, which, unfortunately, does not cover the above issues. Any feedback and system design advice will be appreciated. Thanks in advance, Nick

5 10

Two bases on same ldap server
by Édnei 21 Jul '11

21 Jul '11

Hi Guys! I don't know if it is possible, but....... What I do: sudo apt-get install slapd ldap-utils ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f backend.example.com.ldif ldapadd -x -D cn=admin,dc=felipemeirelles,dc=com,dc=br -W -f frontend.example.com.ldif *backend Base *felipemeirelles*:* # Load dynamic backend modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/ldap olcModuleload: back_hdb # Database settings dn: olcDatabase=hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcSuffix: dc=felipemeirelles,dc=com,dc=br olcDbDirectory: /var/lib/ldap olcRootDN: cn=admin,dc=felipemeirelles,dc=com,dc=br olcRootPW: 123456 olcDbConfig: set_cachesize 0 2097152 0 olcDbConfig: set_lk_max_objects 1500 olcDbConfig: set_lk_max_locks 1500 olcDbConfig: set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcLastMod: TRUE olcDbCheckpoint: 512 30 olcAccess: to attrs=userPassword by dn="cn=admin,dc=felipemeirelles,dc=com,dc=br" write by anonymous auth by self write by * none olcAccess: to attrs=shadowLastChange by self write by * read olcAccess: to dn.base="" by * read olcAccess: to * by dn="cn=admin,dc=felipemeirelles,dc=com,dc=br" write by * read *Frontend* *Base *felipemeirelles: # Create top-level object in domain dn: dc=felipemeirelles,dc=com,dc=br objectClass: top objectClass: dcObject objectclass: organization o: Example Organization dc: felipemeirelles description: LDAP SIJ # Admin user. dn: cn=admin,dc=felipemeirelles,dc=com,dc=br objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword: 123456 dn: ou=people,dc=felipemeirelles,dc=com,dc=br objectClass: organizationalUnit ou: people dn: ou=groups,dc=felipemeirelles,dc=com,dc=br objectClass: organizationalUnit ou: groups dn: uid=contato,ou=people,dc=felipemeirelles,dc=com,dc=br objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uid: contato sn: Contato givenName: Contato cn: Contato Contato displayName: Contato uidNumber: 1000 gidNumber: 10000 userPassword: 123456 gecos: Contato Contato loginShell: /bin/bash homeDirectory: /home/contato shadowExpire: -1 shadowFlag: 0 shadowWarning: 7 shadowMin: 8 shadowMax: 999999 shadowLastChange: 10877 mail: contato(a)felipemeirelles.com.br postalCode: 31000 l: Toulouse o: Example mobile: +33 (0)6 xx xx xx xx homePhone: +33 (0)5 xx xx xx xx title: System Administrator postalAddress: initials: JD dn: cn=felipemeirelles,ou=groups,dc=felipemeirelles,dc=com,dc=br objectClass: posixGroup cn: felipemeirelles gidNumber: 10000 Ok ? This is my first base. Now, i try added more: ldapadd -Y EXTERNAL -H ldapi:/// -f backend_sij_com.example.com.ldif ldapadd -x -D cn=admin,dc=sij,dc=com,dc=br -W -f frontend_sij_com.example.com.ldif ldap_bind: Invalid credentials (49) *BASE SIJ.COM.BR* ( Other backend: backend_sij_com.example.com.ldif ) # Load dynamic backend modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/ldap olcModuleload: back_hdb # Database settings dn: olcDatabase=hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcSuffix: dc=sij,dc=com,dc=br olcDbDirectory: /var/lib/ldap olcRootDN: cn=admin,dc=sij,dc=com,dc=br olcRootPW: 123456 olcDbConfig: set_cachesize 0 2097152 0 olcDbConfig: set_lk_max_objects 1500 olcDbConfig: set_lk_max_locks 1500 olcDbConfig: set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcLastMod: TRUE olcDbCheckpoint: 512 30 olcAccess: to attrs=userPassword by dn="cn=admin,dc=sij,dc=com,dc=br" write by anonymous auth by self write by * none olcAccess: to attrs=shadowLastChange by self write by * read olcAccess: to dn.base="" by * read olcAccess: to * by dn="cn=admin,dc=sij,dc=com,dc=br" write by * read *Other FrontEnd: frontend_sij_com.example.com.ldif* # Create top-level object in domain dn: dc=sij,dc=com,dc=br objectClass: top objectClass: dcObject objectclass: organization o: Example Organization dc: sij description: LDAP SIJ # Admin user. dn: cn=admin,dc=sij,dc=com,dc=br objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword: 123456 dn: ou=people,dc=sij,dc=com,dc=br objectClass: organizationalUnit ou: people dn: ou=groups,dc=sij,dc=com,dc=br objectClass: organizationalUnit ou: groups dn: uid=caho.lopes,ou=people,dc=sij,dc=com,dc=br objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uid: caho.lopes sn: caho givenName: Caho cn: Caho Lopes displayName: caho uidNumber: 1000 gidNumber: 10000 userPassword: testecahosij gecos: Caho Lopes loginShell: /bin/bash homeDirectory: /home/caho.lopes shadowExpire: -1 shadowFlag: 0 shadowWarning: 7 shadowMin: 8 shadowMax: 999999 shadowLastChange: 10877 mail: caho.lopes(a)sij.com.br postalCode: 31000 l: Toulouse o: Example mobile: +33 (0)6 xx xx xx xx homePhone: +33 (0)5 xx xx xx xx title: System Administrator postalAddress: initials: JD dn: cn=sij,ou=groups,dc=sij,dc=com,dc=br objectClass: posixGroup cn: sij gidNumber: 10000 root@PythonAPP:~# ldapadd -d 65535 -x -D cn=admin,dc=sij,dc=com,dc=br -W -f frontend_sij_com.example.com.ldif ldap_create Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 4 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x7f75c3f32540 ptr=0x7f75c3f32540 end=0x7f75c3f32570 len=48 0000: 30 2e 02 01 01 60 29 02 01 03 04 1c 63 6e 3d 61 0....`).....cn=a 0010: 64 6d 69 6e 2c 64 63 3d 73 69 6a 2c 64 63 3d 63 dmin,dc=sij,dc=c 0020: 6f 6d 2c 64 63 3d 62 72 80 06 31 32 33 34 35 36 om,dc=br..123456 ber_scanf fmt ({i) ber: ber_dump: buf=0x7f75c3f32540 ptr=0x7f75c3f32545 end=0x7f75c3f32570 len=43 0000: 60 29 02 01 03 04 1c 63 6e 3d 61 64 6d 69 6e 2c `).....cn=admin, 0010: 64 63 3d 73 69 6a 2c 64 63 3d 63 6f 6d 2c 64 63 dc=sij,dc=com,dc 0020: 3d 62 72 80 06 31 32 33 34 35 36 =br..123456 ber_flush2: 48 bytes to sd 4 0000: 30 2e 02 01 01 60 29 02 01 03 04 1c 63 6e 3d 61 0....`).....cn=a 0010: 64 6d 69 6e 2c 64 63 3d 73 69 6a 2c 64 63 3d 63 dmin,dc=sij,dc=c 0020: 6f 6d 2c 64 63 3d 62 72 80 06 31 32 33 34 35 36 om,dc=br..123456 ldap_write: want=48, written=48 0000: 30 2e 02 01 01 60 29 02 01 03 04 1c 63 6e 3d 61 0....`).....cn=a 0010: 64 6d 69 6e 2c 64 63 3d 73 69 6a 2c 64 63 3d 63 dmin,dc=sij,dc=c 0020: 6f 6d 2c 64 63 3d 62 72 80 06 31 32 33 34 35 36 om,dc=br..123456 ldap_result ld 0x7f75c3f2a2b0 msgid 1 wait4msg ld 0x7f75c3f2a2b0 msgid 1 (infinite timeout) wait4msg continue ld 0x7f75c3f2a2b0 msgid 1 all 1 ** ld 0x7f75c3f2a2b0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Wed Jul 20 17:53:53 2011 ** ld 0x7f75c3f2a2b0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f75c3f2a2b0 request count 1 (abandoned 0) ** ld 0x7f75c3f2a2b0 Response Queue: Empty ld 0x7f75c3f2a2b0 response count 0 ldap_chkResponseList ld 0x7f75c3f2a2b0 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f75c3f2a2b0 NULL ldap_int_select read1msg: ld 0x7f75c3f2a2b0 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 31 04 00 04 00 .1.... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x7f75c3f33920 ptr=0x7f75c3f33920 end=0x7f75c3f3392c len=12 0000: 02 01 01 61 07 0a 01 31 04 00 04 00 ...a...1.... read1msg: ld 0x7f75c3f2a2b0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7f75c3f33920 ptr=0x7f75c3f33923 end=0x7f75c3f3392c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... read1msg: ld 0x7f75c3f2a2b0 0 new referrals read1msg: mark request completed, ld 0x7f75c3f2a2b0 msgid 1 request done: ld 0x7f75c3f2a2b0 msgid 1 res_errno: 49, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x7f75c3f33920 ptr=0x7f75c3f33923 end=0x7f75c3f3392c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... ber_scanf fmt (}) ber: ber_dump: buf=0x7f75c3f33920 ptr=0x7f75c3f3392c end=0x7f75c3f3392c len=0 ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49) In the slapd -D, the log: ..... 0000: 30 2e 02 01 01 60 29 02 0....`). ldap_read: want=40, got=40 0000: 01 03 04 1c 63 6e 3d 61 64 6d 69 6e 2c 64 63 3d ....cn=admin,dc= 0010: 73 69 6a 2c 64 63 3d 63 6f 6d 2c 64 63 3d 62 72 sij,dc=com,dc=br 0020: 80 06 31 32 33 34 35 36 ..123456 *ldap_read: want=8 error=Resource temporarily unavailable* ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... ldap_bind: Invalid credentials (49) *Help ?* Thanks! ldap_read: want=8, got=0

3 4

installation problem on CentOS 6
by Jonathan Camilleri 19 Jul '11

19 Jul '11

I am trying to install OpenLDAP on my virtual machine, however, I am getting an error: configure: error: BDB/HDB: BerkeleyDB not available. I have tried running env=/usr/local/Berkeley.5.1/include, however, I still get this error when I re-run .*/configure*. Any ideas? -- Jonathan Camilleri Mobile (MT): 00356 7982 7113 E-mail: camilleri.jon(a)gmail.com Please consider your environmental responsibility before printing this e-mail. I usually reply to e-mails within 2 business days. If it's urgent, give me a call.

2 2

Inconsistent duplicate attributeType: "memberOf"
by Christian Ramseyer 19 Jul '11

19 Jul '11

(sorry if this appears twice, I've posted this some time ago before I was subscribed to the list and it didn't seem to appear) I'm trying to migrate an LDAP from Solaris/OpenLDAP 2.3 to Linux/OpenLDAP 2.4, and I have an issue with a custom schema: # slaptest -f etc/slapd.conf /data/openldap/etc/schema/nxx.schema: line 10 attributetype: Inconsistent duplicate attributeType: "memberOf" Now the problem is, I have no idea where this previous definiton of memberOf comes from.... These are the included schemas: # grep include etc/slapd.conf include /data/openldap/etc/schema/core.schema include /data/openldap/etc/schema/cosine.schema include /data/openldap/etc/schema/inetorgperson.schema include /data/openldap/etc/schema/nis.schema include /data/openldap/etc/schema/nxx.schema And none of them besides nxx defines a memberOf: # grep memberOf etc/schema/* etc/schema/nxx.schema:attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' etc/schema/nxx.schema: MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) ) <end of grep output> Also, nxx defines it only once (it's pasted below). After commenting nxx and generating a config directory with slaptest, I found this in cn=schema.ldif: # grep memberOf openldap-config/cn\=config/cn\=schema.ldif olcAttributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that t Where does this come from? Apparently not from the schemas I included, as a grep for memberOf doesn't return anything. There are also no other includes in these schema files. Is there any default schema data included besides what is given in include statements? Can I somehow get rid of this? Any help appreciated. Also I know that the attribute in the custom schema had better been prefixed, but this is an installation running since 2004 and "memberOf" is in scripts all over the place, so I'd rather not rename it. Thanks Christian nxx.schema objectIdentifier NxxRoot 1.3.6.1.4.1.21654 objectIdentifier NxxLDAP NxxRoot:3 objectIdentifier NxxLDAPattributeType NxxLDAP:1 objectIdentifier NxxLDAPobjectClass NxxLDAP:2 attributetype ( NxxLDAPattributeType:1 NAME 'memberOf' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # for password aging attributetype ( NxxLDAPattributeType:2 NAME 'lastLogin' DESC 'Stores the last successful login of a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype ( NxxLDAPattributeType:3 NAME 'passwordHistory' DESC 'Stores all password ever used by a user' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( NxxLDAPattributeType:4 NAME 'loginFailures' DESC 'Stores successives login failures for a user' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetype ( NxxLDAPattributeType:5 NAME 'passwordRecoveryMailAddress' EQUALITY caseExactIA5Match DESC 'Stores mail address for self password recovery' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( NxxLDAPattributeType:6 NAME 'passwordRecoveryChallenge' DESC 'Stores challenge for self password recovery' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) objectclass ( NxxLDAPobjectClass:1 NAME 'OssAccount' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( memberOf $ host $ lastLogin $ passwordHistory $ loginFailures $ passwordRecoveryMailAddress $ passwordRecoveryChallenge) ) objectclass ( NxxLDAPobjectClass:2 NAME 'OssHost' SUP top AUXILIARY DESC 'Additional attributes for OSS Accounts' MUST uid MAY ( host ) )

2 3

Database indexing: slapindex
by openldap＠ayni.com 19 Jul '11

19 Jul '11

Hi listers Installation here: openldap-servers-2.4.15-7.fc11.i586 One master server, two backup servers (syncrepl). All authentication and mailing is managed by ldap. 1. About indexing: When i check the slapd-log, i see many <= bdb_equality_candidates: (uidNumber) not indexed <= bdb_equality_candidates: (gidNumber) not indexed In the discussion about slapd tuning http://www.openldap.org/doc/admin24/tuning.html#Indexes, however, i read that if each entry in a certain set of ldap-entries has got the candidate-attribute, it is not worth while to index the attribute, because slapd needs to read each entry in any case in order to find the requested one. this is the case for uidNumber as well as gidNumber, because both are compulsory attributes for objectClass posixAccount. My first question: is it therefore correct to disregard the above indexing requests of slapd? 2. About slapindex: When it comes to use slapindex, the docu is not clear about how to do that. Some places say, that you need to stop slapd entirely, some places say that it is sufficient to put slapd in read-only mode for the corresponding background database, which in this case would be /etc/openldap/slapd.d/cn=config/olcDatabase\=\{2\}bdb.ldif this file contains both the olcReadOnly and the olcDbIndex attributes. So i could just add the following two lines in the above file: olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq set the olcReadOnly attribute to TRUE, and restart slapd, and everything would be done automatically? Or would i need to invoke slapindex additionally with the following command slapindex -c And if i had to start slapindex additionally, would slapindex tell me, that the database is in read-only mode, so no changes are possible, not even index changes? And, if i had to start slapindex additionally, i would do it as root. the files generated by slapindex would they be owned by root (inaccessible by slapd) or by the slapd user? Would the new indexes be propagated to the backup servers by syncrepl automatically? If not, what would i have to change on the backup servers? Thank you for your attention suomi

2 1

TLS configuration with syncrepl
by Naga Chaitanya Palle 19 Jul '11

19 Jul '11

Hi, I am configuring TLS for syncrepl. But the consumer is not reading any updates from the server. Without tls the configuration was working fine. Please let me know where I am going wrong On client, my configuration files are as follows slapd.conf access to attrs=userPassword by self write by users read by anonymous auth access to attrs=shadowLastChange by self write by * auth access to * by * read moduleload syncprov.la syncrepl rid=124 provider=ldaps://smalldevonly.comverse-in.com:389 type=refreshOnly interval=00:00:01:00 searchbase="dc=comverse-in,dc=com" filter="(objectClass=top)" scope=sub attrs="cn,uidNumber" schemachecking=off bindmethod=simple binddn="cn=Manager,dc=comverse-in,dc=com" credentials=sonora updateref ldaps://smalldevonly.comverse-in.com /etc/ldap.conf uri ldaps://smalldevonly.comverse-in.com ldaps://dtr98.comverse-in.com base dc=comverse-in,dc=com ssl start_tls ssl on tls_cacertfile /etc/openldap/cacerts/cacert.pem tls_cacertdir /etc/openldap/cacerts /etc/openldap/ldap.conf BASE dc=comverse-in,dc=com URI ldaps://smalldevonly.comverse-in.com/ ldaps://dtr98.comverse-in.com TLS_CACERT /etc/openldap/cacerts/cacert.pem TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT allow Thanks and Regards, Naga Chaitanya =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===============================================================================

3 3

Re: Simple Bind w/TLS without SASL/Kerberos possible to AD?
by David Mitton 18 Jul '11

18 Jul '11

1 0

raising olcSizeLimit
by E.S. Rosenberg 17 Jul '11

17 Jul '11

Are there any negative repercussions to raising the sizelimit parameter to a high number (that encompasses the whole db), is it better to tie such limits to specific accounts that need that level of access? The documentation just says that limiting is "desirable" but a lot of people both on this list and forums seem to be setting their limits to 10k or even 30k (I guess depending on the db size). Thanks, Eli

2 1

Problem with verifying replication state with contextCSN
by Liam Gretton 15 Jul '11

15 Jul '11

I have a single provider and a single consumer, both quite lightly loaded serving a few hundred clients between them for nss_ldap. I've been trying to monitor the replication state by comparing contextCSN on both systems, but I'm finding that on the consumer contextCSN is more often than not older than the most recent entryCSN value. I read contextCSN as so: ldapsearch -H ldap://ldapserver1.company.org -LLL -x -s base -b dc=company,dc=org contextCSN contextCSN: 20110715120001.914244Z#000000#000#000000 ldapsearch -H ldap://ldapserver2.company.org -LLL -x -s base -b dc=company,dc=org contextCSN contextCSN: 20110715085237.656585Z#000000#000#000000 Looking at the values of entryCSN for ldapserver2 (the consumer): ldapsearch + | grep entryCSN | sort -u ... entryCSN: 20110714154009.500299Z#000000#000#000000 entryCSN: 20110715085237.656585Z#000000#000#000000 entryCSN: 20110715120001.914244Z#000000#000#000000 It can be seen that the most recent entryCSN matches the contextCSN of the provider, but its own contextCSN is an entry behind (often its two or three entries old). The replication is up to date, but contextCSN on the consumer doesn't seem to be getting updated in all circumstances. The consumer is replicating using syncrepl refreshAndPersist. Here's the syncrepl configuration for the consumer: syncrepl rid=001 provider=ldap://ldapserver1.company.org type=refreshAndPersist interval=00:00:05:00 retry="60 +" searchbase="dc=company,dc=org" sizelimit=unlimited timelimit=unlimited binddn="cn=replication,ou=special users,dc=company,dc=org" bindmethod=simple credentials=password schemachecking=off starttls=critical I'm also using the memberOf overlay. I see in the list archives that this has been reported before, but I can't find a bug report to go with it: <http://www.openldap.org/cgi-bin/wilma_hiliter/openldap-technical/201103/msg…> I'm using OpenLDAP 2.4.12 on 64-bit openSUSE 11.1. I haven't been able to find time to set up a test environment with the latest OpenLDAP to see if the problem exists there. Has anybody else seen this behaviour in the latest OpenLDAP? My current workaround to monitor replication status is to modify a record created for the purpose and verify that the consumer has picked it up. -- Liam Gretton liam.gretton(a)le.ac.uk HPC Architect http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom

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