openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

runtime config: adding values to olcDbConfig
by Alexander 'Leo' Bergolth 21 Aug '09

21 Aug '09

Hi! I am experiencing troubles when trying to add an additional value to the olcDbConfig attribute (openldap-2.4.16): $ ldapmodify -xvW -h bach-s49 -D cn=Manager,cn=config <<EOF > dn: olcDatabase={1}bdb,cn=config > changetype: modify > add: olcDbConfig > olcDbConfig: {19}# urxn > - > EOF ldap_initialize( ldap://bach-s49 ) Enter LDAP Password: add olcDbConfig: {19}# urxn modifying entry "olcDatabase={1}bdb,cn=config" ldap_modify: Inappropriate matching (18) additional info: modify/add: olcDbConfig: no equality matching rule replacing all attribute values with "changetype: modify" and "replace: olcDbConfig" works fine but unfortunately Apache DirectoryStudio doesn't seem to offer that way of committing changes... Unfortunately the attribute definition of olcDbConfig seems to be hardcoded, so is there any way to make the above modification work? Thanks, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria

2 1

question for some code in sasl binding
by Xu, Qiang (FXSGSC) 21 Aug '09

21 Aug '09

Hi, all: In reading OpenLDAP code related to SASL binding, I found the following snippet: ======================================== int ldap_sasl_bind( LDAP *ld, LDAP_CONST char *dn, LDAP_CONST char *mechanism, struct berval *cred, LDAPControl **sctrls, LDAPControl **cctrls, int *msgidp ) { ... if( mechanism == LDAP_SASL_SIMPLE ) { /* simple bind */ rc = ber_printf( ber, "{it{istON}" /*}*/, id, LDAP_REQ_BIND, ld->ld_version, dn, LDAP_AUTH_SIMPLE, cred ); } else if ( cred == NULL || cred->bv_val == NULL ) { /* SASL bind w/o credentials */ rc = ber_printf( ber, "{it{ist{sN}N}" /*}*/, id, LDAP_REQ_BIND, ld->ld_version, dn, LDAP_AUTH_SASL, mechanism ); } else { /* SASL bind w/ credentials */ rc = ber_printf( ber, "{it{ist{sON}N}" /*}*/, id, LDAP_REQ_BIND, ld->ld_version, dn, LDAP_AUTH_SASL, mechanism, cred ); } ... } ======================================== Just wanna know that if I remove the condition "|| cred->bv_val == NULL" in the "else if" brance, what will happen? Anyone can tell me why this condition was added? What bug did it fix? My guess is that if it is removed, then the network trace will display some packet marked with "Malformed Packet", but the binding result should be the same. Still, I need some confirmation from your guys. P.S. Shouldn't another condtion, say, "|| cred->bv_len == 0" be added into the "else if" brance as well? Thanks, Xu Qiang

1 0

Avoid unexistent user queries
by Jordi Espasa Clofent 20 Aug '09

20 Aug '09

Hi all, I'm using OpenLDAP as account server. In the server I see a lot of queries from inexistents users in LDAP: filter="(&(objectClass=posixGroup)(|(memberUid=ivan)(uniqueMember=uid=ivan,ou=sat,ou=tecnic,dc=cdmon,dc=com)))" filter="(&(objectClass=posixAccount)(uidNumber=900))" filter="(&(objectClass=posixAccount)(uid=postfix))" filter="(&(objectClass=posixAccount)(uid=postfix))" filter="(&(objectClass=posixAccount)(uid=postfix))" filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=nobody))" gidNumbercn filter="(&(objectClass=posixAccount)(uid=postfix))" gidNumbercn filter="(&(objectClass=posixAccount)(uidNumber=125))" gidNumbercn filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=xatlantax))" gidNumbercn filter="(&(objectClass=posixAccount)(uidNumber=900))" gidNumbercn filter="(&(objectClass=posixAccount)(uid=cetr))" gidNumbercn filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uidNumber=900))" gidNumbercn filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=www-data))" I don't understand why because of users as '900, postfix, root, www-data' don't exists as users in LDAP server. On the other hand, the user 'ivan' exists and you can see the difference in the log record. ¿Where is the problem? Maybe in my /etc/nsswitch.conf of LDAP clients? # cat /etc/nsswitch.conf passwd: files ldap group: files ldap shadow: files ldap sudoers: ldap hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis Taking for example the common 'www-data' user query, I see in the LDAP client the next: # cat /var/log/auth.log | grep apache Aug 20 01:20:30 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:20:30 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:20:30 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:20:30 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:20:58 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:02 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:04 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:04 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:05 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:05 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:05 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:05 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:06 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:48 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:49 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:50 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:50 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:50 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:50 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:50 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:21:59 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:00 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:00 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:03 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:05 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:07 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:07 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:24 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:24 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:24 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ Aug 20 01:22:25 xen-ad0010 apache2: nss_ldap: reconnected to LDAP server ldap://192.168.10.1/ ¿Why Apache2 tries to connect to LDAP (192.168.10.1)? ¿How I can avoid it? -- Thanks, Jordi Espasa Clofent

1 0

using ldapsearch to get whole data
by mukim pathan 20 Aug '09

20 Aug '09

Hi, I am unable to use slapcat to get whole database into a ldif file because I have a 32 bit machine which cannot write file having size more than 2 GB. So I am looking for alternate ways to get full database into ldif file. So please tell me if there are any alternate ways to do this. I am using openldap-2.4.16 with BDB-4.5 Regards, Mukim Pathan

4 4

LDAP Multimaster Replication
by Paul bob 19 Aug '09

19 Aug '09

Hi - I have question regarding the HA, configured LDAP Multimaster Replication (Openldap 2.4.17 & BDB 4.6.21 ) I can see the Users data in both Server1 and Server2. When I turned off the server2 the users are not getting authenticated through Server1. It always getting authentication through Server2. I would appreciate your valuable suggestion! Thanks, PB

1 0

ldap_add: Already exists (68) errors when testing multi-master sync replication
by Barry Colston 19 Aug '09

19 Aug '09

While testing sync replication, I encountered a situation in which a previously deleted DN cannot be added again because the ldapadd command receives a 68 error code. If I perform an ldapsearch command for the DN, the DN is not found. If I try to add the DN, the add fails with a 68 error code. If I perform a slapcat command for that DN, slapcat displays the record. I have removed all BDB index files and rerun the slapindex command, but the DN is still not found with the ldapsearch command and fails to be added because of a 68 error code. 1 reason I can think of is that deleting a DN does not physically delete the record, but flags the DN as being logically deleted. This condition does not happen all the time, but it does happen eventually after I have been adding, modifying, and deleting records for approximately 15 minutes. I'm running openLDAP 2.4.17 with BDB 4.6.21 (and have not applied the 4 BDB patches). Running sync replication with 2 masters defined in mirror mode using refreshandpersist; issuing LDAP commands against only master slapd #1. Barry Colston

2 3

Need help migrating from Novell eDirectory to OpenLDAP
by Donal Duane 19 Aug '09

19 Aug '09

Hi all, Has anyone tried to migrate data between eDirectory and OpenLDAP? I am having a lot of trouble with invalid attributes. /D

2 1

[PROBLEM] delta-syncrepl, accesslog and filters
by mkappe 19 Aug '09

19 Aug '09

Hello, I use openldap 2.4.16. I configured 2 servers using syncrepl. I would like to sync only a DIT fragment and so i put these lines in the consumer slapd.conf file: syncrepl rid=111 provider=ldaps://mydomain.it<http://ldapstudenti.cca.unipd.it:12315/> type=refreshAndPersist searchbase="dc=mydomain,dc=it" filter="(&(objectClass=MyClass)(Email=true))" attrs="Username,UserStatus,UserExpireDate" schemachecking=off bindmethod=simple binddn="cn=reader,dc=mydomain,dc=it" credentials=xxxxxx retry="60 +" When i try to get out of the scope an entry (setting its attribute 'Email' = false) in the producer, i see that the same entry is removed from the consumer. Everything works fine if i don't activate delta syncrepl mode using accesslog overlay. If i do that, every changes in the producer is propagated to the consumer even if the entry is out of the scope defined in the consumer. How can i configure delta syncrepl (with accesslog) for sync only a DIT fragment? My producer (delta-syncrepl mode) slapd.conf is: moduleload syncprov.la ####################################################################### # ACCESSLOG database definitions ####################################################################### moduleload accesslog.la database bdb suffix "cn=accesslog" rootdn "cn=accesslog" directory /openldap/data/accesslog index default eq index entryCSN,objectClass overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ####################################################################### # BDB database definitions ####################################################################### # RAMO LOCALE: database bdb suffix "dc=mydomain,dc=it" rootdn "cn=manager,dc=mydomain,dc=it" rootpw xxxxxxx directory /openldap/data index objectClass,uid eq index entryCSN eq index entryUUId eq index Email pres,eq ####################################################################### # Syncrepl - Sincprov ####################################################################### overlay syncprov syncprov-checkpoint 100 1 syncprov-sessionlog 100 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 00+01:00 00+00:15 ####################################################################### # ACL ####################################################################### access to dn.subtree="dc=mydomain,dc=it" attrs="userPassword" by anonymous auth by self write by * search access to * by dn.base="cn=reader,dc=mydomain,dc=it" read by * break My consumer (delta-syncrepl mode) slapd.conf is: ####################################################################### # BDB database definitions ####################################################################### # RAMO LOCALE: database bdb suffix "dc=mydomain,dc=it" rootdn "cn=manager,dc=mydomain,dc=it" rootpw xxxxxxx directory /openldap/data index objectClass,uid eq index entryUUID,entryCSN eq index Email pres,eq ####################################################################### # DELTA-SYNCREPL ####################################################################### syncrepl rid=005 provider=ldaps://mydomain.it:123 type=refreshAndPersist searchbase="dc=mydomain,dc=it" filter="(&(objectClass=myClass)(Email=true))" logbase="cn=accesslog" syncdata=accesslog schemachecking=off bindmethod=simple binddn="cn=reader,dc=mydomain,dc=it" credentials=xxxxxx retry="60 +" updateref ldaps://mydomain.it:123 ###################################################################### # ACL ###################################################################### access to dn.subtree="dc=mydomain,dc=it" attrs="userPassword" by anonymous auth by self write by * search access to * by dn.base="cn=reader,dc=mydomain,dc=it" read by * break Thank you! Marco

1 0

Missing UUID for entry being copied by syncrepl to secondary ldap
by Robert Hanson 19 Aug '09

19 Aug '09

(Openldap 2.4.17; BDB 4.5) I have a database that I have set up in non-replicated mode (no syncrepl setup). Now, I've added a second node in a multi-master configuration. When I start slapd on the second node, syncrepl starts up and tries to copy data to the second node. I've stepped through the syncrepl code on the master using a debugger, and it is clear that onespecific node (from the set of nodes in the master database is being queued up and sent to the secondary) has a UUID entry of length 1, and a value of "0". When that node is sent to the secondary, it is treated as if it has no UUID, which is caught by an assertion. This causes the slapd on the secondary to exit. Why is the node on the primary missing the UUID? Is there some code I can trace through to determine this? Is there a way to add the UUID to the entry? Or is there a way to patch the syncrepl code to avoid sending the node that is missing the UUID?

1 0

How to get some overlays?
by ulises gonzalez 18 Aug '09

18 Aug '09

Hello I'm begining to use Openldap, I'm using the version 2.4.11 which comes precompiled with Debian Lenny, the problem is that each time I try to load some overlay the logs saids... Aug 17 13:56:36 ldap slapd[4935]: @(#) $OpenLDAP: slapd 2.4.11 (Oct 12 2008 04:13:21) $#012#011buildd@ninsei:/build/buildd/openldap-2.4.11/debian/build/servers/slapd Aug 17 13:56:36 ldap slapd[4935]: overlay "syncprov" not found Aug 17 13:56:36 ldap slapd[4935]: slapd stopped. Aug 17 13:56:36 ldap slapd[4935]: connections_destroy: nothing to destroy. Aug 17 14:44:23 ldap slapd[5027]: @(#) $OpenLDAP: slapd 2.4.11 (Oct 12 2008 04:13:21) $#012#011buildd@ninsei:/build/buildd/openldap-2.4.11/debian/build/servers/slapd Aug 17 14:44:23 ldap slapd[5027]: overlay "unique" not found Aug 17 14:44:23 ldap slapd[5027]: slapd stopped. Aug 17 14:44:23 ldap slapd[5027]: connections_destroy: nothing to destroy. Aug 17 14:49:07 ldap slapd[5040]: @(#) $OpenLDAP: slapd 2.4.11 (Oct 12 2008 04:13:21) $#012#011buildd@ninsei:/build/buildd/openldap-2.4.11/debian/build/servers/slapd Aug 17 14:49:08 ldap slapd[5040]: overlay "ppolicy" not found Aug 17 14:49:08 ldap slapd[5040]: slapd stopped. Aug 17 14:49:08 ldap slapd[5040]: connections_destroy: nothing to destroy. And Openldap doesn't start, I've been searching in the Openldap website but I haven't found any link to download so my question is where I can get overlays? I need exactly unique and syncprov overlays. Thanks... -- Salu2 ________________________ Ulinx Administrador de redes Ministerio de Finanzas y Precios Linux user 366775 "En un problema con n ecuaciones siempre habrá al menos n+1 incógnitas."

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical