openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

"best" way to check if OpenLDAP replication is working
by Tim Gustafson 01 Jun '11

01 Jun '11

Hi, Is there a "best" way to check to see if OpenLDAP replication is working? I have one script that checks the ContextCSN of the root of the database, which works to a certain degree. However, even when that matches it seems that sometimes a "deep inspection" (actually traversing the whole database and comparing each entry individually) of the directory shows differences even when the ContextCSN of the directory root matches. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafson tjg(a)soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

8 11

Re: Should Berkeley DB backends be reloaded occasionally?
by Mark 31 May '11

31 May '11

Thank you both for your quick response. I understand non-indexed reads will always be slower than indexed, but it was a batch process and I didn't want to incur the overhead of another write-impacting index. I've recently come back to OpenLDAP and so wasn't sure whether the new version's backend became 'fragmented' (for lack of a better term) like the old ones (<=2.1.25) seemed to. I hoped they did not, but I wanted to confirm as I haven't been running 2.4.25 w/BDB 4.8.30 long enough or under enough load yet to tell. I'm glad to hear 'defraging' is not required in newer versions. I will begin testing BDB 5.x as a replacement to our current BDB 4.8.30 backend. Is anyone aware of any technical reasons why one should use 5.1.25 over 4.8.30? On Tue, May 31, 2011 at 5:27 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Tuesday, May 31, 2011 4:49 PM -0500 Mark <mah042(a)gmail.com> wrote: > > Back in the days of OpenLDAP 2.1 with Berkeley DB 4.1.25.3 we used to >> have to 'reload' out backend database occasionally as non-indexed reads >> would get slower and slower over time. The 'reload' entailed: >> >> • stop slapd >> • slapcat the contents to an .ldif file >> >> • remove the database files >> • slapadd the .ldif file to create a new, fresh db instance >> • start slapd >> >> Then our performance problems went away. Re-indexing didn't do the trick. >> >> Is such occasional re-building of the backend database recommended in >> OpenLDAP 2.4.25 with Berkeley DB 4.8.30? >> > > No. You are having this problem by running ancient releases of OpenLDAP > and BDB. BTW, BDB 5.x (5.1 and 5.0) are also fully supported by OpenLDAP > 2.4.23 and later. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

slapcating multi-master database to add new multi-master
by Mark 31 May '11

31 May '11

If I wanted to add another multi-master with a unique ServerID to a current set, I've read that in most instances it's best to slapcat one of the current multi-master's data, then slapadd that data into the new multi-master rather than wait for the new mmaster to 'catch up'. Q: Should I do something with the contextCSN at the top of the tree before I import it or will the new server create a new contextCSN using it's own ServerID? Q Should all multi-master instances include a contextCSN for each of the multi-master instances or just a contextCSN for itself? I have a 2-way mmaster duo where each mmaster only has it's own contextCSN. And another 4-way mmaster setup where each mmaster has a 4 contextCSNs, one for each of the mmasters in the group. Thank you, Mark

1 0

replace running LDAP-server in multimaster configuration
by Andreas Haubod 31 May '11

31 May '11

Hello, at the moment, I have running two LDAP-Server (2.4.23) on two sites (AP and Europe) with multi master replication. All is running very well. On both sites will be written from applications to the local LDAP-server and the complete database is replicated to the other site (syncrepl/push). A third LDAP-server (read-only replica) on one site is used to make a backup hourly. The LDAP is stopped an the database is saved with slapcat. Now I want replace one of the LDAP-Server because of better Hardware. So I know, I have two choices: 1) Only setup the new LDAP-Server with a empty Database and wait till the replication is finished 2) Fill the Database with one of the hourly backup and start the server and wait till the replication is finished. What will happen, when I use method 1) and the application write during the (initial) replication to the (for explamle only 2% filled) Database? (I checked the initial replication. It needs about one hour because of the old slow hardware.) Does this work without expecting any problems or should I avoid the writing till the initial replication has finished? When I use method 2) and for example the saved database is 10h old and during this time are many (>10000) changes made in the productive system? Is then this method then recommended or is method 1) better in this situation? Are there any comparison or recommendations for backup/recover and migration in such multi master setups? A second Question I have. Is it possible, to mix the openldap (minor) versions (eg. 2.4.23 and 2.4.25)? I ask this, because I want update the servers on different times. Thanks for help and the great openLDAP !!! Andreas

2 1

Last Bind (Last logon) attribute
by Andy Carlson 31 May '11

31 May '11

As far as I am aware, there is no attribute in the OpenLDAP shema that holds the last logon (or last bind) time or built-in slapd functionality to do so. If I am incorrect, please let me know. If I am correct, I am wondering if there is any way to implement triggers that can be executed when a successful bind operation happens such as executing a shell script that will modify a user-defined attribute that holds a timestamp. Thanks much, Andy Carlson Identity Administrator | Information Systems 312-329-4385

3 2

back-sql configuration
by Chris Card 30 May '11

30 May '11

I am trying to set up openldap to use back-sql and mysql (currently on Fedora 14 with packages openldap-servers-sql-2.4.23-4.fc14.x86_64, openldap-2.4.23-4.fc14.x86_64, openldap-clients-2.4.23-4.fc14.x86_64, openldap-servers-2.4.23-4.fc14.x86_64). Is it true that to do this openldap must use the old slapd.conf method rather than the newer dynamic configuration method using slapd.d? I can get back-sql working using config from /etc/openldap/slapd.conf, but when I try to create the equivalent config under slapd.d I can't see any where to put the equivalent of dbname, subtree_cond etc., and I see a warning "No dynamic config support for database sql". If it *is* true that slapd.conf must be used for back-sql config, can openldap use slapd.conf and slapd.d config at the same time, or must all the openldap config come from slapd.conf? Chris

3 3

How to write an overlay that perform search from within an overlay?
by hptf 30 May '11

30 May '11

Hello all, I am trying to write an overlay that is able to get the previous/old values of an Entity, before it is updated by a modify/delete. For that purpose, my first tries were to use a search from within the overlay, or pre-read. I try many method, (inspired by existing overlay), but none seems to work for now: - use of pre-read seems to be very complicated; moreover, pre-read ctrl seems to be returned as already ber-encoded, meaning that I need to re-decode the ber to get the value ... this is (too) expensive - use of search from within overlay raise, for now, some problems: * if using translucent like call to 'be_entry_get_rw' I got deadlock on hdb * if using rc = nop->o_bd->be_search(nop,&nrs); from within overlay, it seems that response is sent also to remote client socket, and not stay confined to overlay call ( and, btw, I fail to get the result: rs->sr_un.sru_search.r_entry is NULL ) I, for sure, miss something. Do you have any clue, example, advice that may help me to continue ? Thanks in advance for your help. hp tf PS: This is a repost in the good mailing list, initial message post in openldap-devel(a)openldap.org, sorry for the inconvenience.

2 1

Fail to test uid of OpenLDAP with TLS...
by Nguyen, Quoc Khanh 29 May '11

29 May '11

Hi all, Please help me about this problem... I want to use testsaslauthd to test uid of OpenLDAP with TLS, but it fail... Here is my config: /usr/local/etc/saslauthd.conf: ldap_servers: ldap://localhost ldap_bind_dn: cn=admin,dc=abc,dc=com ldap_bind_pw: 123456789 ldap_search_base: dc=abc,dc=com ldap_start_tls: yes ldap_tls_cacert_dir: /var/myCA ldap_tls_cacert_file: /var/myCA/cacert.crt ldap_debug: -1 start LDAP: root@ldap:~# /usr/local/openldap/libexec/slapd -h 'ldap:///' start saslauthd: root@ldap:~# /usr/local/sasl2/sbin/saslauthd -a ldap -O /usr/local/etc/saslauthd.conf -d saslauthd[765] :main : num_procs : 5 saslauthd[765] :main : mech_option: /usr/local/etc/saslauthd.conf saslauthd[765] :main : run_path : /var/run saslauthd[765] :main : auth_mech : ldap saslauthd[765] :ipc_init : using accept lock file: /var/run/mux.accept saslauthd[765] :detach_tty : master pid is: 0 saslauthd[765] :ipc_init : listening on socket: /var/run/mux saslauthd[765] :main : using process model saslauthd[765] :have_baby : forked child: 766 saslauthd[765] :have_baby : forked child: 767 saslauthd[765] :have_baby : forked child: 768 saslauthd[765] :have_baby : forked child: 769 saslauthd[765] :get_accept_lock : acquired accept lock test uid: root@ldap:~# /usr/local/sasl2/sbin/testsaslauthd -u khanhnq -p 123456 0: NO "authentication failed" I have a debug result: saslauthd[765] :rel_accept_lock : released accept lock saslauthd[767] :get_accept_lock : acquired accept lock ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 10 tm: 5 async: 0 ldap_ndelay_on: 10 ldap_int_poll: fd: 10 tm: 5 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 ldap_open_defconn: successful ldap_send_server_request ldap_result ld 0x9cef220 msgid 1 wait4msg ld 0x9cef220 msgid 1 (infinite timeout) wait4msg continue ld 0x9cef220 msgid 1 all 1 ** ld 0x9cef220 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:40:05 2011 ** ld 0x9cef220 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9cef220 request count 1 (abandoned 0) ** ld 0x9cef220 Response Queue: Empty ld 0x9cef220 response count 0 ldap_chkResponseList ld 0x9cef220 msgid 1 all 1 ldap_chkResponseList returns ld 0x9cef220 NULL ldap_int_select read1msg: ld 0x9cef220 msgid 1 all 1 read1msg: ld 0x9cef220 msgid 1 message type extended-result read1msg: ld 0x9cef220 0 new referrals read1msg: mark request completed, ld 0x9cef220 msgid 1 request done: ld 0x9cef220 msgid 1 res_errno: 0, res_error: , res_matched: ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ldap_parse_result ldap_msgfree TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 0, subject: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW Department, issuer: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW Department TLS certificate verification: depth: 0, err: 7, subject: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW, issuer: /CN=abc.com/ST=HCM/C=VN/emailAddress=root(a)abc.com/O=SGT/OU=NW Department TLS certificate verification: Error, certificate signature failure TLS trace: SSL3 alert write:fatal:decrypt error TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:func(144):reason(134) (certificate signature failure). ldap_err2string ldap_unbind ldap_free_connection 1 1 ldap_send_unbind ldap_free_connection: actually freed saslauthd[765] :do_auth : auth failure: [user=khanhnq] [service=imap] [realm=] [mech=ldap] [reason=Unknown] saslauthd[765] :do_request : response: NO What i'm doing wrong? I think my TLS is OK... Here is my ldapsearch result: root@ldap:/usr/local/openldap/bin# ./ldapsearch -xLL -b dc=abc,dc=com uid=khanhnq -d -1 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP abc.com:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x9023e88 ptr=0x9023e88 end=0x9023e96 len=14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ber_scanf fmt ({i) ber: ber_dump: buf=0x9023e88 ptr=0x9023e8d end=0x9023e96 len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_flush2: 14 bytes to sd 3 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 60 07 02 01 03 04 00 80 00 0....`........ ldap_result ld 0x901b540 msgid 1 wait4msg ld 0x901b540 msgid 1 (infinite timeout) wait4msg continue ld 0x901b540 msgid 1 all 1 ** ld 0x901b540 Connections: * host: abc.com port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:42:21 2011 ** ld 0x901b540 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x901b540 request count 1 (abandoned 0) ** ld 0x901b540 Response Queue: Empty ld 0x901b540 response count 0 ldap_chkResponseList ld 0x901b540 msgid 1 all 1 ldap_chkResponseList returns ld 0x901b540 NULL ldap_int_select read1msg: ld 0x901b540 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 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x9025488 ptr=0x9025488 end=0x9025494 len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x901b540 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x9025488 ptr=0x902548b end=0x9025494 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x901b540 0 new referrals read1msg: mark request completed, ld 0x901b540 msgid 1 request done: ld 0x901b540 msgid 1 res_errno: 0, res_error: , res_matched: ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x9025488 ptr=0x902548b end=0x9025494 len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x9025488 ptr=0x9025494 end=0x9025494 len=0 ldap_msgfree version: 1 ldap_search_ext put_filter: "uid=khanhnq" put_filter: default put_simple_filter: "uid=khanhnq" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x9023e88 ptr=0x9023e88 end=0x9023ebf len=55 0000: 30 35 02 01 02 63 30 04 0d 64 63 3d 61 62 63 2c 05...c0..dc=abc, 0010: 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 dc=com.......... 0020: 01 00 01 01 00 a3 0e 04 03 75 69 64 04 07 6b 68 .........uid..kh 0030: 61 6e 68 6e 71 30 00 anhnq0. ber_scanf fmt ({) ber: ber_dump: buf=0x9023e88 ptr=0x9023e8d end=0x9023ebf len=50 0000: 63 30 04 0d 64 63 3d 61 62 63 2c 64 63 3d 63 6f c0..dc=abc,dc=co 0010: 6d 0a 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 m............... 0020: a3 0e 04 03 75 69 64 04 07 6b 68 61 6e 68 6e 71 ....uid..khanhnq 0030: 30 00 0. ber_flush2: 55 bytes to sd 3 0000: 30 35 02 01 02 63 30 04 0d 64 63 3d 61 62 63 2c 05...c0..dc=abc, 0010: 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 dc=com.......... 0020: 01 00 01 01 00 a3 0e 04 03 75 69 64 04 07 6b 68 .........uid..kh 0030: 61 6e 68 6e 71 30 00 anhnq0. ldap_write: want=55, written=55 0000: 30 35 02 01 02 63 30 04 0d 64 63 3d 61 62 63 2c 05...c0..dc=abc, 0010: 64 63 3d 63 6f 6d 0a 01 02 0a 01 00 02 01 00 02 dc=com.......... 0020: 01 00 01 01 00 a3 0e 04 03 75 69 64 04 07 6b 68 .........uid..kh 0030: 61 6e 68 6e 71 30 00 anhnq0. ldap_result ld 0x901b540 msgid -1 wait4msg ld 0x901b540 msgid -1 (infinite timeout) wait4msg continue ld 0x901b540 msgid -1 all 0 ** ld 0x901b540 Connections: * host: abc.com port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:42:21 2011 ** ld 0x901b540 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x901b540 request count 1 (abandoned 0) ** ld 0x901b540 Response Queue: Empty ld 0x901b540 response count 0 ldap_chkResponseList ld 0x901b540 msgid -1 all 0 ldap_chkResponseList returns ld 0x901b540 NULL ldap_int_select read1msg: ld 0x901b540 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 82 01 13 02 01 02 64 0......d ldap_read: want=271, got=271 0000: 82 01 0c 04 28 63 6e 3d 4b 68 61 6e 68 20 4e 67 ....(cn=Khanh Ng 0010: 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 6f 72 6b 2c uyen,ou=network, 0020: 64 63 3d 61 62 63 2c 64 63 3d 63 6f 6d 30 81 df dc=abc,dc=com0.. 0030: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0040: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0050: 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 20 0'..cn1!..Khanh 0060: 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e 67 Nguyen..Khanh Ng 0070: 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e 31 uyen Quoc0...sn1 0080: 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 31 ...Khanh0...uid1 0090: 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 73 ...khanhnq0...us 00a0: 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 32 erPassword1...12 00b0: 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 0f 34560H..mail1@.. 00c0: 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d 04 khanhnq(a)abc.com [1]. 00d0: 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f 2e .nqk28703@yahoo. 00e0: 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 69 com..khanhnq@sai 00f0: 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 0f gontech.edu.vn0. 0100: 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ..ou1...network ber_get_next: tag 0x30 len 275 contents: ber_dump: buf=0x90255f0 ptr=0x90255f0 end=0x9025703 len=275 0000: 02 01 02 64 82 01 0c 04 28 63 6e 3d 4b 68 61 6e ...d....(cn=Khan 0010: 68 20 4e 67 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 h Nguyen,ou=netw 0020: 6f 72 6b 2c 64 63 3d 61 62 63 2c 64 63 3d 63 6f ork,dc=abc,dc=co 0030: 6d 30 81 df 30 1e 04 0b 6f 62 6a 65 63 74 43 6c m0..0...objectCl 0040: 61 73 73 31 0f 04 0d 69 6e 65 74 4f 72 67 50 65 ass1...inetOrgPe 0050: 72 73 6f 6e 30 27 04 02 63 6e 31 21 04 0c 4b 68 rson0'..cn1!..Kh 0060: 61 6e 68 20 4e 67 75 79 65 6e 04 11 4b 68 61 6e anh Nguyen..Khan 0070: 68 20 4e 67 75 79 65 6e 20 51 75 6f 63 30 0d 04 h Nguyen Quoc0.. 0080: 02 73 6e 31 07 04 05 4b 68 61 6e 68 30 10 04 03 .sn1...Khanh0... 0090: 75 69 64 31 09 04 07 6b 68 61 6e 68 6e 71 30 18 uid1...khanhnq0. 00a0: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 08 ..userPassword1. 00b0: 04 06 31 32 33 34 35 36 30 48 04 04 6d 61 69 6c ..1234560H..mail 00c0: 31 40 04 0f 6b 68 61 6e 68 6e 71 40 61 62 63 2e 1@..khanhn [2]q@abc. 00d0: 63 6f 6d 04 12 6e 71 6b 32 38 37 30 33 40 79 61 com..nqk28703@ya 00e0: 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 hoo.com..khanhnq 00f0: 40 73 61 69 67 6f 6e 74 65 63 68 2e 65 64 75 2e @saigontech.edu. 0100: 76 6e 30 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 vn0...ou1...netw 0110: 6f 72 6b ork read1msg: ld 0x901b540 msgid 2 message type search-entry ldap_get_dn_ber ber_scanf fmt ({ml{) ber: ber_dump: buf=0x90255f0 ptr=0x90255f3 end=0x9025703 len=272 0000: 64 82 01 0c 04 28 63 6e 3d 4b 68 61 6e 68 20 4e d....(cn=Khanh N 0010: 67 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 6f 72 6b guyen,ou=network 0020: 2c 64 63 3d 61 62 63 2c 64 63 3d 63 6f 6d 30 81 ,dc=abc,dc=com0. 0030: df 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 .0...objectClass 0040: 31 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 1...inetOrgPerso 0050: 6e 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 n0'..cn1!..Khanh 0060: 20 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e Nguyen..Khanh N 0070: 67 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e guyen Quoc0...sn 0080: 31 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 1...Khanh0...uid 0090: 31 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 1...khanhnq0...u 00a0: 73 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 serPassword1...1 00b0: 32 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 234560H..mail1@. 00c0: 0f 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d .khanhnq(a)abc.com 00d0: 04 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f ..nqk28703@yahoo 00e0: 2e 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 .com..khanhnq@sa 00f0: 69 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 igontech.edu.vn0 0100: 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ...ou1...network dn: cn=Khanh Nguyen,ou=network,dc=abc,dc=com ber_scanf fmt ({xx) ber: ber_dump: buf=0x90255f0 ptr=0x90255f3 end=0x9025703 len=272 0000: 64 82 01 0c 04 28 63 6e 3d 4b 68 61 6e 68 20 4e d....(cn=Khanh N 0010: 67 75 79 65 6e 2c 6f 75 3d 6e 65 74 77 6f 72 6b guyen,ou=network 0020: 2c 64 63 3d 61 62 63 2c 64 63 3d 63 6f 6d 00 81 ,dc=abc,dc=com.. 0030: df 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 .0...objectClass 0040: 31 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 1...inetOrgPerso 0050: 6e 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 n0'..cn1!..Khanh 0060: 20 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e Nguyen..Khanh N 0070: 67 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e guyen Quoc0...sn 0080: 31 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 1...Khanh0...uid 0090: 31 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 1...khanhnq0...u 00a0: 73 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 serPassword1...1 00b0: 32 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 234560H..mail1@. 00c0: 0f 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d .khanhnq(a)abc.com 00d0: 04 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f ..nqk28703@yahoo 00e0: 2e 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 .com..khanhnq@sa 00f0: 69 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 igontech.edu.vn0 0100: 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ...ou1...network ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x9025624 end=0x9025703 len=223 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 20 0'..cn1!..Khanh 0030: 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e 67 Nguyen..Khanh Ng 0040: 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e 31 uyen Quoc0...sn1 0050: 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 31 ...Khanh0...uid1 0060: 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 73 ...khanhnq0...us 0070: 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 32 erPassword1...12 0080: 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 0f 34560H..mail1@.. 0090: 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d 04 khanhnq(a)abc.com [3]. 00a0: 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f 2e .nqk28703@yahoo. 00b0: 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 69 com..khanhnq@sai 00c0: 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 0f gontech.edu.vn0. 00d0: 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ..ou1...network objectClass: inetOrgPerson ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x9025644 end=0x9025703 len=191 0000: 00 27 04 02 63 6e 31 21 04 0c 4b 68 61 6e 68 20 .'..cn1!..Khanh 0010: 4e 67 75 79 65 6e 04 11 4b 68 61 6e 68 20 4e 67 Nguyen..Khanh Ng 0020: 75 79 65 6e 20 51 75 6f 63 30 0d 04 02 73 6e 31 uyen Quoc0...sn1 0030: 07 04 05 4b 68 61 6e 68 30 10 04 03 75 69 64 31 ...Khanh0...uid1 0040: 09 04 07 6b 68 61 6e 68 6e 71 30 18 04 0c 75 73 ...khanhnq0...us 0050: 65 72 50 61 73 73 77 6f 72 64 31 08 04 06 31 32 erPassword1...12 0060: 33 34 35 36 30 48 04 04 6d 61 69 6c 31 40 04 0f 34560H..mail1@.. 0070: 6b 68 61 6e 68 6e 71 40 61 62 63 2e 63 6f 6d 04 khanhnq(a)abc.com [4]. 0080: 12 6e 71 6b 32 38 37 30 33 40 79 61 68 6f 6f 2e .nqk28703@yahoo. 0090: 63 6f 6d 04 19 6b 68 61 6e 68 6e 71 40 73 61 69 com..khanhnq@sai 00a0: 67 6f 6e 74 65 63 68 2e 65 64 75 2e 76 6e 30 0f gontech.edu.vn0. 00b0: 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 6b ..ou1...network cn: Khanh Nguyen cn: Khanh Nguyen Quoc ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x902566d end=0x9025703 len=150 0000: 00 0d 04 02 73 6e 31 07 04 05 4b 68 61 6e 68 30 ....sn1...Khanh0 0010: 10 04 03 75 69 64 31 09 04 07 6b 68 61 6e 68 6e ...uid1...khanhn 0020: 71 30 18 04 0c 75 73 65 72 50 61 73 73 77 6f 72 q0...userPasswor 0030: 64 31 08 04 06 31 32 33 34 35 36 30 48 04 04 6d d1...1234560H..m 0040: 61 69 6c 31 40 04 0f 6b 68 61 6e 68 6e 71 40 61 ail1@..khanhn [5]q@a 0050: 62 63 2e 63 6f 6d 04 12 6e 71 6b 32 38 37 30 33 bc.com..nqk28703 0060: 40 79 61 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 6e @yahoo.com..khan 0070: 68 6e 71 40 73 61 69 67 6f 6e 74 65 63 68 2e 65 hnq(a)saigontech.e 0080: 64 75 2e 76 6e 30 0f 04 02 6f 75 31 09 04 07 6e du.vn0...ou1...n 0090: 65 74 77 6f 72 6b etwork sn: Khanh ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x902567c end=0x9025703 len=135 0000: 00 10 04 03 75 69 64 31 09 04 07 6b 68 61 6e 68 ....uid1...khanh 0010: 6e 71 30 18 04 0c 75 73 65 72 50 61 73 73 77 6f nq0...userPasswo 0020: 72 64 31 08 04 06 31 32 33 34 35 36 30 48 04 04 rd1...1234560H.. 0030: 6d 61 69 6c 31 40 04 0f 6b 68 61 6e 68 6e 71 40 mail1@..khanhn [6]q@ 0040: 61 62 63 2e 63 6f 6d 04 12 6e 71 6b 32 38 37 30 abc.com..nqk2870 0050: 33 40 79 61 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 3@yahoo.com..kha [7] 0060: 6e 68 6e 71 40 73 61 69 67 6f 6e 74 65 63 68 2e nhnq@saigontech. 0070: 65 64 75 2e 76 6e 30 0f 04 02 6f 75 31 09 04 07 edu.vn0...ou1... 0080: 6e 65 74 77 6f 72 6b network uid: khanhnq ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x902568e end=0x9025703 len=117 0000: 00 18 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 ....userPassword 0010: 31 08 04 06 31 32 33 34 35 36 30 48 04 04 6d 61 1...1234560H..ma 0020: 69 6c 31 40 04 0f 6b 68 61 6e 68 6e 71 40 61 62 il1@..khanhn [8]q@ab 0030: 63 2e 63 6f 6d 04 12 6e 71 6b 32 38 37 30 33 40 c.com..nqk28703@ 0040: 79 61 68 6f 6f 2e 63 6f 6d 04 19 6b 68 61 6e 68 yahoo.com..khanh 0050: 6e 71 40 73 61 69 67 6f 6e 74 65 63 68 2e 65 64 nq(a)saigontech.ed [9] 0060: 75 2e 76 6e 30 0f 04 02 6f 75 31 09 04 07 6e 65 u.vn0...ou1...ne 0070: 74 77 6f 72 6b twork userPassword:: MTIzNDU2 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x90256a8 end=0x9025703 len=91 0000: 00 48 04 04 6d 61 69 6c 31 40 04 0f 6b 68 61 6e .H..mail1@..khan 0010: 68 6e 71 40 61 62 63 2e 63 6f 6d 04 12 6e 71 6b hnq@abc.com..nqk [10] 0020: 32 38 37 30 33 40 79 61 68 6f 6f 2e 63 6f 6d 04 28703(a)yahoo.com [11]. 0030: 19 6b 68 61 6e 68 6e 71 40 73 61 69 67 6f 6e 74 .khanhnq@saigont 0040: 65 63 68 2e 65 64 75 2e 76 6e 30 0f 04 02 6f 75 ech.edu.vn0...ou 0050: 31 09 04 07 6e 65 74 77 6f 72 6b 1...network mail: khanhnq(a)abc.com [12] mail: nqk28703(a)yahoo.com [13] mail: khanhnq(a)saigontech.edu.vn [14] ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x90255f0 ptr=0x90256f2 end=0x9025703 len=17 0000: 00 0f 04 02 6f 75 31 09 04 07 6e 65 74 77 6f 72 ....ou1...networ 0010: 6b k ou: network ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x901b540 msgid -1 wait4msg ld 0x901b540 msgid -1 (infinite timeout) wait4msg continue ld 0x901b540 msgid -1 all 0 ** ld 0x901b540 Connections: * host: abc.com port: 389 (default) refcnt: 2 status: Connected last used: Fri May 27 16:42:21 2011 ** ld 0x901b540 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x901b540 request count 1 (abandoned 0) ** ld 0x901b540 Response Queue: Empty ld 0x901b540 response count 0 ldap_chkResponseList ld 0x901b540 msgid -1 all 0 ldap_chkResponseList returns ld 0x901b540 NULL ldap_int_select read1msg: ld 0x901b540 msgid -1 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 02 65 07 0a 0....e.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x90252d8 ptr=0x90252d8 end=0x90252e4 len=12 0000: 02 01 02 65 07 0a 01 00 04 00 04 00 ...e........ read1msg: ld 0x901b540 msgid 2 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x90252d8 ptr=0x90252db end=0x90252e4 len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ read1msg: ld 0x901b540 0 new referrals read1msg: mark request completed, ld 0x901b540 msgid 2 request done: ld 0x901b540 msgid 2 res_errno: 0, res_error: , res_matched: ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x90252d8 ptr=0x90252db end=0x90252e4 len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ ber_scanf fmt (}) ber: ber_dump: buf=0x90252d8 ptr=0x90252e4 end=0x90252e4 len=0 ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed Please help, Best Regards, -- *********************************** EVERYTHING HAS JUST BEGUN... Links: ------ [1] mailto:khanhnq@abc.com [2] mailto:1@..khanhn [3] mailto:khanhnq@abc.com [4] mailto:khanhnq@abc.com [5] mailto:ail1@..khanhn [6] mailto:mail1@..khanhn [7] mailto:3@yahoo.com..kha [8] mailto:il1@..khanhn [9] mailto:nq@saigontech.ed [10] mailto:hnq@abc.com..nqk [11] mailto:28703@yahoo.com [12] mailto:khanhnq@abc.com [13] mailto:nqk28703@yahoo.com [14] mailto:khanhnq@saigontech.edu.vn

2 1

Should multiple cn entries in a dn be accepted?
by Ian Collins 27 May '11

27 May '11

I am trying to import data from another server into OpenLDAP and I've hit a snag with some dns which contain multiple cn entries: cn=Services_PM_Champions,cn=Services_PM_Team,ou=groups,o=staff,dc=client ADD is failing with error 32 (No such object): conn=1005 op=1236 ADD dn="cn=Service.Admin,ou=groups,o=staff,dc=client" conn=1005 op=1236 RESULT tag=105 err=0 text= conn=1005 op=1237 ADD dn="cn=Services_PM_Champions,cn=Services_PM_Team,ou=groups,o=staff,dc=client" conn=1005 op=1237 RESULT tag=105 err=32 text= Should this be accepted? -- Ian.

3 4

New consumer replication issues
by Christopher Strider Cook 26 May '11

26 May '11

I've got a mirrormode cluster of 2.4.25 running and using test059 as an example I had setup a script that would create new consumers of this cluster. It worked fine.. until now. Now when I run it I seem to run into, what I can only describe as, an ordering problem with the initial replication. The server is replicating parts of cn=config over but seems to complain because of an syntax check. Am I missing some flag in the sync or do entyCSNs need to be in a particular order...or am I missing something else altogether? Hear are some logs and configs In this case it looks like a needed schema wasn't synced first: May 26 15:02:49 ramones slapd[10377]: syncrepl_message_to_entry: rid=001 mods check (olcSuffix: value #0 invalid per syntax) May 26 15:02:49 ramones slapd[10377]: do_syncrepl: rid=001 rc 21 retrying And here I tried to sync the schema specifically and it errors on not understanding the creatorsName, because the database that contains it hasn't been synced yet: May 26 14:58:10 ramones slapd[7260]: syncrepl_message_to_entry: rid=001 mods check (creatorsName: value #0 invalid per syntax) May 26 14:58:10 ramones slapd[7260]: do_syncrepl: rid=001 rc 21 retrying Here is a debug: ==> rewrite_context_apply [depth=1] string='olcDatabase={1}hdb,cn=config,cn=slave' ==> rewrite_rule_apply rule='(.*)cn=config,cn=slave$' string='olcDatabase={1}hdb,cn=config,cn=slave' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'olcDatabase={1}hdb,cn=config'} ber_scanf fmt ({mW}) ber: ber_dump: buf=0xb155b0 ptr=0xb16005 end=0xb16046 len=65 0000: 30 23 04 11 73 75 62 73 63 68 65 6d 61 53 75 62 0#..subschemaSub 0010: 65 6e 74 72 79 31 0e 04 0c 63 6e 3d 53 75 62 73 entry1...cn=Subs 0020: 63 68 65 6d 61 30 1a 04 0f 68 61 73 53 75 62 6f chema0...hasSubo 0030: 72 64 69 6e 61 74 65 73 31 07 04 05 46 41 4c 53 rdinates1...FALS 0040: 45 E ==> rewrite_context_apply [depth=1] string='cn=Subschema' ==> rewrite_rule_apply rule='(.*)cn=config,cn=slave$' string='cn=Subschema' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'cn=Subschema'} ber_scanf fmt ({mW}) ber: ber_dump: buf=0xb155b0 ptr=0xb1602a end=0xb16046 len=28 0000: 30 1a 04 0f 68 61 73 53 75 62 6f 72 64 69 6e 61 0...hasSubordina 0010: 74 65 73 31 07 04 05 46 41 4c 53 45 tes1...FALSE >>> dnPretty: <dc=savagebeast,dc=com> => ldap_bv2dn(dc=savagebeast,dc=com,0) <= ldap_bv2dn(dc=savagebeast,dc=com)=0 syncrepl_message_to_entry: rid=001 mods check (olcSuffix: value #0 invalid per syntax) ldap_msgfree And here is the consumer's olcDatabase={0}config.ldif before the sync starts-- dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config structuralObjectClass: olcDatabaseConfig entryUUID: 3ff5aef4-ff02-102f-8945-2f8fc203546c creatorsName: cn=admin,cn=config createTimestamp: 20110419185450Z olcRootDN: cn=admin,cn=config olcRootPW:: xxx olcSyncrepl: {0}rid=001 provider=ldaps://ldap.savagebeast.com binddn="cn= admin,cn=config,cn=slave" bindmethod=simple credentials=xxx searchbase="cn= config,cn=slave" type=refreshAndPersist retry="60 +" timeout=3 suffixmassage= "cn=config" schemachecking=off entryCSN: 20110420231921.726316Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110420231921Z And here is the consumer's olcDatabase={0}config.ldif at the point it fails. dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config structuralObjectClass: olcDatabaseConfig entryUUID: 3ff5aef4-ff02-102f-8945-2f8fc203546c creatorsName: cn=admin,cn=config createTimestamp: 20110419185450Z olcRootDN: cn=admin,cn=config olcRootPW:: xxx olcUpdateRef: ldaps://ldap.savagebeast.com olcSyncrepl: {0}rid=001 provider=ldaps://guess-who.savagebeast.com binddn="cn= admin,cn=config,cn=slave" bindmethod=simple credentials=xxx searchbase="cn= config,cn=slave" schemachecking=off type=refreshAndPersist retry="60 +" timeo ut=3 suffixmassage="cn=config" entryCSN: 20110526212623.826014Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110526212623Z -- and here it is on the provider dn: olcDatabase={0}config,cn=config,cn=slave objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {SHA}/xxx olcSyncrepl: {0}rid=001 provider=ldaps://guess-who.savagebeast.com binddn="c n=admin,cn=config,cn=slave" bindmethod=simple credentials=xxx searchbase= "cn=config,cn=slave" schemachecking=off type=refreshAndPersist retry="60 +" timeout=3 suffixmassage="cn=config" olcUpdateRef: ldaps://ldap.savagebeast.com createTimestamp: 20110419185450Z creatorsName: cn=admin,cn=config entryCSN: 20110526212623.826014Z#000000#001#000000 entryDN: olcDatabase={0}config,cn=config,cn=slave entryUUID:: M2ZmNWFlZjQtZmYwMi0xMDJmLTg5NDUtMmY4ZmMyMDM1NDZj hasSubordinates: FALSE modifiersName: cn=admin,cn=config modifyTimestamp: 20110526212623Z structuralObjectClass: olcDatabaseConfig subschemaSubentry: cn=Subschema Thanks for reading this far down!

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical