openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

a lot of dnMatch msgs after do_syncrep2
by Daniel Jung 26 Aug '14

26 Aug '14

openldap-2.4.39 with lmdb backend running on centos 6.4. This occurred on one of the consumers and other consumers didnt have any issue. I was running args,stats and sync loglevel, and I see the following in the log. Each do_syncrep2 shows dnMatch. The contextcsn got out of sync and I used slapd -c to resync it and it looks ok now. Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c [7a441664] Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_delete_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c [eebf38e5] Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: mdb_idl_insert_keys: 226c Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text="" Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text="" Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc0185aa630 20140825014502.251709Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: syncrepl_entry: rid=703 be_modify cn=cname,ou=Group,dc=server,dc=com (0) Aug 25 03:45:02 servernameslapd[16312]: slap_queue_csn: queing 0x7fc01859e320 20140825014502.251709Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: mdb_modify: dc=server,dc=com Aug 25 03:45:02 servernameslapd[16312]: mdb_modify_internal: replace contextCSN Aug 25 03:45:02 servernameslapd[16312]: send_ldap_result: err=0 matched="" text="" Aug 25 03:45:02 servernameslapd[16312]: slap_graduate_commit_csn: removing 0x7fc01850f060 20140825014502.251709Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: connection_get(12) Aug 25 03:45:02 servernameslapd[16312]: do_syncrep2: rid=703 cookie=rid=703,sid=001,csn=20140825014502.428281Z#000000#001#000000 Aug 25 03:45:02 servernameslapd[16312]: syncrepl_message_to_entry: rid=703 DN: cn=development,ou=somegroup,dc=server,dc=com, UUID: a06de85e-b545-102d-9482-cde2fff247a7 Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3 Aug 25 03:45:02 servernameslapd[16312]: dnMatch 1 Aug 25 03:45:02 servernameslapd[16312]: dnMatch -3 Aug 25 03:45:02 servernameslapd[16312]: dnMatch -2 <snip>

1 1

How can I add ldap user from linux shell command line?
by Tian Zhiying 26 Aug '14

26 Aug '14

Hi All How can I add ldap user from linux shell command line? And how can I batch add ldap user from linux shell command line? Tian Zhiying

3 2

Getting the memberof overlay to work
by Karel Vervaeke 26 Aug '14

26 Aug '14

Hi. I've followed a number of memberof tutorials/howto guides, but I can't get it to work. I've tried to document my best attempt yet in this github repository: https://github.com/karel1980/openldap-memberof There is an installation script which: - installs slapd - sets up a new database - configures memberof and refint overlays - restarts slapd - adds groups and users There's also a sample query which should return memberOf attributes, but it does not. If you can spot the error of my ways, please enlighten me. Regards, Karel

1 1

Converting BDB database from 4.8 to 4.5.
by Markus Moeller 26 Aug '14

26 Aug '14

I have an openldap server using libdb-4.5, but somehow my OS had db-utils for 4.8 and I guess I run the wrong commands as I now get the following error when starting the server. Is there a way to "downgrade" to 4.5 ? Unacceptable log file /var/lib/ldap/log.0000000001: unsupported log version 16 Thank you Markus

4 4

(no subject)
by Meunier, Antonin 25 Aug '14

25 Aug '14

Hello, In my openldap with mdb I imported a ldif that made add and modify (1000 objects). 95% of the file is processed in 2 minutes without problems. 5% of the rest of file is porcessed in more than 1 hour. The problem is on the groupOfName with lots of member (more than 1000 members). Each modify can take between 3 and 10 minutes. My Openldap is MMR with 2 servers. The problem appears only on one of the two ldap server. On the second one, each modification take 2 seconds. I've tried a reindex of the member attribute but nothing change. I've tried a delete and reimport (ldif file from the second server) the ldap and the problem persist. The configurations are the same on the 2 servers. What can explain this huge time to modify a group ? Exemple of a modification in my ldif file : dn: cn=522495,ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr changetype: modify add: member member: uid=2142279020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr dn: cn=522813, ou=groupes,ou=XXXXXX,dc=xxxxx,dc=fr changetype: modify add: member member: uid=1021253020,ou=personnes,ou= XXXXXX,dc= xxxxx,dc=fr Thanks a lot by advance Antonin Meunier

3 3

idassert-authzFrom ignored
by Charles Bueche 22 Aug '14

22 Aug '14

Hi, I have an OpenLDAP proxy using back_meta to talk to two back-ends Microsoft AD servers. My goal is to provide a single view of both AD trees. Basically, it works, as long as I use a bind account which exists in one of the back-end AD's. However, to first search where an AD account is, I would like to use a local account on the LDAP proxy. To my understanding, I need to use database meta suffix dc=proxy,dc=stuff,dc=ch rootdn "cn=root,dc=proxy,dc=stuff,dc=ch" rootpw "secret" subordinate ... idassert-bind bindmethod=simple binddn="CN=srvLDAP,..." credentials="..." mode=none flags=non-prescriptive idassert-authzFrom "dn.exact:cn=root,dc=proxy,dc=stuff,dc=ch" The DN "cn=root,dc=proxy,dc=stuff,dc=ch" does exist in the proxy and can do local searches. However, the account defined in the idassert is never used, and the connections to the back-ends AD's fail. Respectively, I think they are contacted using anonymous instead of the account I specify (not sure about the anonymous part, the debug log isn't very clear about it). Hints welcome. Below is a part of the relevant log if it helps. Charles .......... tls_read: want=64, got=64 0000: 65 87 ac 08 7e 49 8d 7f 95 3c d0 1f 09 57 b7 ce e...~I...<...W.. 0010: d4 13 2e ac 57 c9 27 6b 58 f7 76 70 a1 95 10 3e ....W.'kX.vp...> 0020: e2 96 0d cf a1 d3 13 ff e7 0b b1 2f c0 6f dc 19 .........../.o.. 0030: 93 38 07 b9 f7 e4 81 a8 e0 45 0e 97 ec 7f 21 a6 .8.......E....!. TLS trace: SSL_connect:SSLv3 read finished A ldap_int_poll: fd: -1 tm: 0 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=4 53679e3b conn=1000 op=1 <<< meta_back_search_start[0]=4 53679e3b conn=1000 op=1 meta_back_search: ncandidates=1 cnd="*" 53679e3b conn=1000 op=1 >>> meta_search_dobind_init[0] ldap_sasl_bind ldap_send_initial_request ldap_int_poll: fd: 12 tm: 0 ldap_is_sock_ready: 12 ldap_ndelay_off: 12 TLS trace: SSL_connect:before/connect initialization tls_write: want=225, written=225 0000: 16 03 01 00 dc 01 00 00 d8 03 02 53 67 9e 3b 55 ...........Sg.;U 0010: 4b 2f ee 53 01 81 ee ca 6a 3f a0 ea 85 3a c9 7e K/.S....j?...:.~ 0020: e3 01 d7 e6 d1 09 65 14 21 05 ef 00 00 66 c0 14 ......e.!....f.. 0030: c0 0a c0 22 c0 21 00 39 00 38 00 88 00 87 c0 0f ...".!.9.8...... 0040: c0 05 00 35 00 84 c0 12 c0 08 c0 1c c0 1b 00 16 ...5............ 0050: 00 13 c0 0d c0 03 00 0a c0 13 c0 09 c0 1f c0 1e ................ 0060: 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 .3.2.....E.D.... 0070: 00 2f 00 96 00 41 c0 11 c0 07 c0 0c c0 02 00 05 ./...A.......... 0080: 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 ................ 0090: 00 03 00 ff 01 00 00 49 00 0b 00 04 03 00 01 02 .......I........ 00a0: 00 0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c ...4.2.......... 00b0: 00 18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 ................ 00c0: 00 14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 ................ 00d0: 00 03 00 0f 00 10 00 11 00 23 00 00 00 0f 00 01 .........#...... 00e0: 01 . TLS trace: SSL_connect:SSLv3 write client hello A tls_read: want=5 error=Connection reset by peer TLS trace: SSL_connect:error in SSLv3 read server hello A TLS: can't connect: . ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7 error=Broken pipe ldap_free_connection: actually freed 53679e3b conn=1000 op=1 <<< meta_search_dobind_init[0]=0 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_result: conn=1000 op=1 p=3 53679e3b send_ldap_result: err=0 matched="" text="" 53679e3b send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ tls_write: want=69, written=69

1 1

Re : RE24 testing call (2.4.40)
by "POISSON Frédéric" 22 Aug '14

22 Aug '14

Hello, I have tested with success the rev 55eddb0 on an RHEL 5.3 x86_64. I also copy a small test file (starting from a copy of the 051) in order to check if the new code correct the ITS#7822 "Segmentation fault while modifying olcDbMaxSize". The test file (see attachment) succeed like this : # ./run -b mdb test065-config-update Cleaning up test run directory leftover from previous run. Running ./scripts/test065-config-update for mdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Check the olcDbMaxSize dn: olcDatabase={1}mdb,cn=config olcDbMaxSize: 10485760 Dynamically updating the olcDbMaxSize Re-check the olcDbMaxSize dn: olcDatabase={1}mdb,cn=config olcDbMaxSize: 123456789 >>>>> Test succeeded While if i run the same test on release 2.4.39 and older it fail with a seg fault. I'm not sure that this is a good test for future release of openldap but if you agree, the ITS#7822 could be closed if release 2.4.40 of openldap has the same behavior :-). Thanks a lot, Regards, Le 11/08/14 20:58, Quanah Gibson-Mount <quanah(a)zimbra.com> a écrit : > > If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.39 release, please do so. > > Generally, get the code for RE24: > > <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> > > Configure & build. > > Execute the test suite (via make test) after it is built. > > Thanks! > > --Quanah > > > -- > Quanah Gibson-Mount > Server Architect > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- Frederic Poisson

1 0

Accesslog: Excluding attributes from logging
by Oriol Rosa Ramoneda 22 Aug '14

22 Aug '14

4 5

memberof overlay surpresses accesslog olcAccessLogOps = all
by Jan Prinsloo 21 Aug '14

21 Aug '14

Hi All, I would appreciate it if someone could give me some insight into the following issue: I have a standalone openldap 2.4.26 setup. We would like to use the accesslog overlay for auditing. I have enabled the accesslog overlay with olcAccessLogOps = all. This writes all groups of operations (writes, reads, session) to cn=accesslog without issues. We would also like to make use of the memberof overlay. The issue we're seeing is that once you enable the memberof overlay, only search, unbind, add operations are logged to accesslog. We do not see delete, modify, modrdn values logged. If I then change the logops to "olcAccessLogOps = add delete modify modrdn" we see those operations logged, but no bind, search, unbind operations (ie. no reads or session). Is this a limitation of using these two overlay's together, or am I completely missing something? Here is the configuration output: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read structuralObjectClass: olcDatabaseConfig entryUUID: 174cbd2c-bbe1-1033-97e1-99c5bb2fcfe1 creatorsName: cn=config createTimestamp: 20140819113832Z entryCSN: 20140819113832.018426Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819113832Z dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=config structuralObjectClass: olcDatabaseConfig entryUUID: 174cc498-bbe1-1033-97e2-99c5bb2fcfe1 creatorsName: cn=config createTimestamp: 20140819113832Z olcAccess: {0}to * by * manage entryCSN: 20140819153732.253785Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819153732Z dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=novell,dc=com olcAccess: {0}to attrs=userPassword by self write by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to * by * read olcRootDN: cn=admin,dc=novell,dc=com olcRootPW:: e1NTSEF9eTUrcGVLRmtBSlY4aytQUVJZOVVDTzByN1FwV1RrbENSZz09 olcDbCacheSize: 10000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_cachesize 0 15000000 1 olcDbConfig: {1}set_lg_regionmax 262144 olcDbConfig: {2}set_lg_bsize 2097152 olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE olcDbConfig: {4}set_lk_max_locks 30000 olcDbConfig: {5}set_lk_max_objects 30000 olcDbIDLcacheSize: 30000 olcDbIndex: objectclass eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: member eq olcDbIndex: memberUid eq olcDbIndex: mail eq olcDbIndex: cn eq,sub olcDbIndex: displayName eq,sub olcDbIndex: uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: givenName eq,sub olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq structuralObjectClass: olcBdbConfig entryUUID: 174ccbbe-bbe1-1033-97e3-99c5bb2fcfe1 creatorsName: cn=config createTimestamp: 20140819113832Z entryCSN: 20140819114039.896372Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819114039Z dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcAccessLogDB: cn=accesslog olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 827deb2a-bbe1-1033-8b97-93a12773fffb creatorsName: cn=config createTimestamp: 20140819114131Z olcOverlay: {0}accesslog olcAccessLogOps: writes entryCSN: 20140819154607.969610Z#000000#000#000000 modifiersName: cn=admin,dc=novell,dc=com modifyTimestamp: 20140819154607Z dn: olcOverlay={1}refint,olcDatabase={1}bdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: {1}refint olcRefintAttribute: memberof member manager owner structuralObjectClass: olcRefintConfig entryUUID: e5b204be-bbfb-1033-9b62-8fa7905953f2 creatorsName: cn=config createTimestamp: 20140819145025Z entryCSN: 20140819145025.207784Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819145025Z dn: olcDatabase={2}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=novell,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart structuralObjectClass: olcBdbConfig entryUUID: 827bc75a-bbe1-1033-8b95-93a12773fffb creatorsName: cn=config createTimestamp: 20140819114131Z entryCSN: 20140819114131.842907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20140819114131Z Regards, Jan Prinsloo

2 1

setting up mirroring with ldaps
by Sterling Sahaydak 20 Aug '14

20 Aug '14

Setting up mirroring between 2 servers - (ldap1 and ldap2) Have a self signed cert installed on ldap1(provider) and connecting to ldap2(consumer) which is using the same cert as ldap1. What I'm not sure about is can I put the same self signed cert on both ldap1 and ldap2? Or on ldap2 create a self signed cert and copy it to ldap1 and register it using (certutil) to fix the issue below? Thanks! [root@ldap1 log]# slapd -d Sync @(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) $ mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd /etc/openldap/slapd.conf: line 149: warning, destination attributeType 'sAMAccountName' is not defined in schema PROXIED attributeDescription "SAMACCOUNTNAME" inserted. /etc/openldap/slapd.conf: line 199: rootdn is always granted unlimited privileges. bdb_monitor_db_open: monitoring disabled; configure monitor database to enable slapd starting TLS: error: the certificate '/etc/openldap/certs/testldap1cert.pem' could not be found in the database - error -8174:security library: bad database.. TLS: certificate '/etc/openldap/certs/testldap1cert.pem' successfully loaded from PEM file. TLS: no unlocked certificate for certificate 'E=sterling.sahaydak(a)example.com,CN=ldap1.example.net,OU=IT,O=example,L=xxxx,ST=xx,C=xx'. TLS: hostname (ldap2.example.net) does not match common name in certificate (ldap1.example.net). TLS: can't connect: TLS error -8157:Certificate extension not found.. slap_client_connect: URI=ldaps://ldap2.example.net DN="cn=testsync,ou=roles,dc=example,dc=net" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=001 rc -1 retrying

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