"best" way to check if OpenLDAP replication is working
by Tim Gustafson
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
9 years, 10 months
slapcating multi-master database to add new multi-master
by Mark
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
9 years, 10 months
replace running LDAP-server in multimaster configuration
by Andreas Haubod
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
9 years, 10 months
Last Bind (Last logon) attribute
by Andy Carlson
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
9 years, 10 months
back-sql configuration
by Chris Card
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
9 years, 10 months
How to write an overlay that perform search from within an overlay?
by hptf
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.
9 years, 10 months
Fail to test uid of OpenLDAP with TLS...
by Nguyen, Quoc Khanh
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
9 years, 10 months
Should multiple cn entries in a dn be accepted?
by Ian Collins
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.
9 years, 10 months
New consumer replication issues
by Christopher Strider Cook
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!
9 years, 10 months
Syncrep size limit exceeded
by Darouichi, Aziz
Hi,
After configuring Openldap -2.4.23 Multi-master Syncrep with TLS. Replication never completes, log shows
slapd[13578]: do_syncrep2: rid=003 (4) Size limit exceeded.
This is slapd.conf
syncrepl rid=002
provider=ldap://xxx.xxx.xxx
tls_cert=/etc/pki/tls/certs/ldapcert.pem
tls_key=/etc/pki/tls/private/ldapkey.pem
tls_cacert=/etc/pki/tls/certs/ldapcert.pem
tls_reqcert=demand
searchbase="dc=establishment,dc=edu"
schemachecking=on
timelimit=unlimited
sizelimit=unlimited
type=refreshAndPersist
retry="60 +"
Thanks,
9 years, 10 months
