openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

no data are fetched when using cn=config + back-sql
by Benin Technologies 24 Jan '13

24 Jan '13

Hi, I'm using back-sql. After converting to cn=config, ldapsearch fetches no data (with the old slapd.conf everything worked fine). Any idea why ? ------> $ ldapsearch -x -h localhost -b "dc=example,dc=com" "(objectClass=*)" # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (objectClass=*) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error # numResponses: 1 ------> Versions : OpenLDAP 2.4.33 with latest patchs applied (until ITS#7499) Debian 6.0.4

1 0

Preoperation Plugin Questions
by Julius Plenz 23 Jan '13

23 Jan '13

Hi, I'm writing an preoperation authentication plugin for OpenLDAP, but I have trouble finding any documentation whatsoever on this. So most of what I know comes from tutorials like this one from Oracle: http://docs.oracle.com/cd/E19099-01/nscp.dirsvr416/816-6683-10/custauth.htm But since this is not official documentation and I find the execution paths hard to trace, I have two questions stemming from above guide: 1) The guide says that for an authentication preop plugin, Your pre-operation plug-in function is responsible for sending the result code to the client and for setting the DN and authentication method for the connection. Okay, so I do that. Like in the code example, I set the connection's DN to the value I got from the 'pb' in the first place: slapi_pblock_set(pb, SLAPI_CONN_DN, slapi_ch_strdup(dn)); But setting the authentication type fails: slapi_pblock_set(pb, SLAPI_CONN_AUTHTYPE, SLAPD_AUTH_SIMPLE); This is no real error though, it's simply not implemented: See http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… case SLAPI_CONN_AUTHMETHOD: ... /* These parameters cannot be set */ rc = PBLOCK_ERROR; break; (This was noted in 2006 already, with no reply on this list: http://www.openldap.org/lists/openldap-software/200601/msg00044.html ) So basically it boils down to: Do I have to do *any* other stuff except for sending back the result code? Like this: slapi_send_ldap_result(pb, rc, NULL, NULL, 0, NULL); 2) What is the preferred return value for a plugin function? Most (other) documentations and the code hints at this: i) return 0 if you handled the authentication ii) return 1 if you want successive plugins/backends/... to handle the authentication Is this correct? Or should I use the more suggestive SLAPI_BIND_SUCCESS and SLAPI_BIND_FAIL? Thanks! Julius P.S.: What I'm actually trying to achieve is to do RADIUS authentification via an external library. But I want to send the client's IP in a Calling-Station-Id attribute, so I cannot simply write a password check function, right? If you got any ideas that are better than a preop module, please tell me...

3 4

RE: slapd-ldap: second search operation always generates error LdapErr: DSID-0C0906E8
by Quanah Gibson-Mount 23 Jan '13

23 Jan '13

--On Wednesday, January 23, 2013 11:22 AM -0700 Bryce Powell <Bryce.Powell(a)TELUS.COM> wrote: > Hi Quanah, > > Thank you. Is this a known issue that's been addressed in the 2.4.33 > release? Please keep replies to the list, and please don't top post. There have been a multitude of bug fixes to slapd-ldap since the 2.4.23 release (I counted over 10 in the CHANGES file). There are also numerous other reasons not to use the generally broken packages provided by RH/CentOS. The first step to getting help with an issue like this is always going to be to first verify whether or not it occurs on a current release. Regards, 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

openldap overlays
by Carlos Santos 23 Jan '13

23 Jan '13

Greetings, I'm relatively new to OpenLDAP and I think I am an average user and a newbie when it comes to development. I am currently on a project on which we use openldap2.4 and the dyngroup overlay. My goal is to build another group overlay which will fetch data from outside the ldap machine (webservices) and then works just like the regular dyngroup overlay, returning the members of that group based on the results of the call to the webservices. The problem is, like I said, that I'm a newbie. I looked at dyngroup.c and I find it quite hard to understand what is going on. It has very few comments and of little help. Can someone give me an overview of the code, and maybe introduce me to the steps of creating an overlay? thanks, Carlos Santos

1 0

RE: (ITS#7498) Openldap syncrepl issue
by Chris Card 23 Jan '13

23 Jan '13

Hi,> > Hi, > > I've been having issues with syncrepl in openldap. This is plain > syncrepl. I'm not using delta-syncrepl as I run with mirror mode on. > > I've noticed that when there are a large number of writes on the > writemaster (Typically around 10 per second) the data on the readslave > goes out of sync with the master, typically having entries which have > been deleted on the master. The contextCSNs on both the readslaves and > writemaster match eventually, but the data doesn't. I'm running the > readslave in refreshOnly mode with an interval of 1 minute. I'm using a > reasonably large DB of size ~ 2 GB. I turned on the sync logs and found > lots of entries with "nonpresent_callback" and "syncrepl_del_nonpresent". > > Tested this and found it occurring in both 2.4.29 and 2.4.33 (Latest as > of this time), and with BDB 4.2.36 as the backend. > > I was wondering if anyone has faced similar issues before, and if there > exists a solution to this problem. I will send any relevant > configuration and log snippets as needed. > > Thanks >I am certainly seeing similar problems with plain syncrepl in an MMR setup (all writes to one server currently, openldap 2.4.31):for example, at the moment in my production system, there are 18 DNs (out of 5.7 million) which are in the writemaster but which are missing from the 3 readslaves, although the contextCSNs all match. Deleting and re-adding such DNs to the writemastercan usually fix this up, but sometimes the contextCSNs get out of sync, andthen the only practical way to recover is to rebuild the readslaves from a backup taken from the writemaster. Because of this issue I am planning to change to using delta-syncrepl, which does appear to work and not get out of sync in the testingI have done. I believe this is the only solution at the moment. Chris

1 0

Grant access to a group
by Onno van der Straaten 23 Jan '13

23 Jan '13

Hi, I would like to grant access to a group in my directory. Granting access to user is straightforward and works, for example access to attrs=myAttribute by dn="cn=User,dc=mydomain,dc=com" write by anonymous auth by users read by * none Now I'm trying to do the same using a group for example access to attrs=myAttribute by group/groupOfUniqueNames/uniqueMember="cn=ldap-admins,dc=groups,dc=mydomain,dc=com" write by anonymous auth by users read by * none I can't get this to work. I tried by group and by group.exact, these also don't work. From the documentation I understand that by group assumes objectClass 'groupOfNames' and attribute 'member' I used groupOfUniqueNames and uniqueMember so the configuration ended up as above. Is is possible to grant access to the directory in such a way? To a group? How? Best Regards, Onno

1 0

bug on dynamic configuration with back-sql
by Benin Technologies 22 Jan '13

22 Jan '13

Hi, I'm on Debian 6 / OpenLDAP 2.4.33 with back-sql. According to http://www.openldap.org/software/release/changes.html, back-sql supports dynamic config as of version 2.4.27. So I converted slapd.conf to slapd.d, conversion went well. However, when I start slapd, I get the following message : # /usr/local/libexec/slapd -u openldap -g openldap -d -1 ....... 50ff3f0a <<< dnPrettyNormal: <cn=root,dc=example,dc=com>, <cn=root,dc=example,dc=com> 50ff3f0a olcSqlInsEntryStmt: value #0: <olcSqlInsEntryStmt> extra cruft after <SQL expression>. 50ff3f0a config error processing olcDatabase={1}sql,cn=config: <olcSqlInsEntryStmt> *extra cruft after <SQL expression>* 50ff3f0a send_ldap_result: conn=-1 op=0 p=0 50ff3f0a send_ldap_result: err=19 matched="" text="" 50ff3f0a slapd destroy: freeing system resources. 50ff3f0a slapd stopped. 50ff3f0a connections_destroy: nothing to destroy. I took a look into olcDatabase={1}sql.ldif, and I saw that olcSqlInsEntryStmt was splitted on two lines : olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) v alues ((select max(id)+1 from ldap_entries),?,?,?,?) I tries to put everything on the same line, like : olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?) But the error persists. If I comment that line, the server starts fine # olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)

1 0

slapcat output is truncated every now and then
by Balint Reczey 22 Jan '13

22 Jan '13

Dear Members of OpenLDAP Technical List, Could you please help in finding and explanation and potentially a fix for the bug reported at [1]? It seems it has been found often enough by Elmar as well to write a workaround [2]. Thanks, Balint [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038 [2] https://github.com/elmar/ldap-git-backup/blob/master/README.mdown#safe-ldif On 06/19/2012 06:27 PM, Quanah Gibson-Mount wrote: > --On Tuesday, June 19, 2012 2:25 PM +0200 Axel Beckert > <abe(a)debian.org> wrote: > >> Hi Steve, >> >> Steve Langasek wrote: >>> > According to the slapcat man page it should be "always safe to run >>> > slapcat with the slapd-bdb(5) ... backends" even if slapd runs. We do >>> > use a BDB backend. >>> >>> Note that the HDB backend is the one recommended upstream and the >>> Debian >>> default. >> >> Well, yeah, that system has been dist-upgraded from at least Etch. >> IIRC it started at some time when BDB was still the default. >> >> I wrote that -- according to our backups -- this happened already with >> Lenny's slapd. But with Lenny it seemed to have happened less often >> (which is why we noticed it only recently). > > Personally, I would advise you to ask a question about this on > openldap-technical(a)openldap.org. I asked Howard about it, and he had > a ready answer as to why you were seeing this, but I forget what it > is. In any case, this is not a debian specific openldap bug. > > --Quanah > ...

2 1

Re: Replication not working
by anil beniwal 22 Jan '13

22 Jan '13

> > I will be highly thankful to you, if you can help me out in below issue. > > We have three servers on rhel 6.3, 16 vcpu and 32G RAM , openldap 2.4.33 > with mdb db of 200G > > We are facing replication issue on our servers, otherwise servers are good > with login and user registration from website.(doing on one server only as > of now) > > We imported data on one server mmam01 and copied it to other 2 servers. > After some time we got big diff b/w db size of mmam01 and other two servers. > Then exported data and restored it on other two servers. > > i tried adding a user and i got replicated to other two servers, but after > some time, new users stop getting replicated to other servers. > > initial replication status after some 30 min > > Even when i tried with blank db it initally started and then stopped. i got errors like dn_callback : entries have identical CSN syncrepl_entry: rid=111 entry unchanged, ignored > Sat Jan 12 12:40:41 EST 2013 > > DR-SJ > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > DC-mmam01 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130112174006.314483Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > DC-mmam04 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > > After 2 hours > > DR-SJ > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > contextCSN: 20130112175710.938307Z#000000#003#000000 > DC-mmam01 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130112193219.242546Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > contextCSN: 20130112175710.938307Z#000000#003#000000 > DC-mmam04 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > contextCSN: 20130112175710.938307Z#000000#003#000000 > > My ldap.conf file is(same on all server) , we have host-ip mapping in > /etc/hosts file > > BASE dc=example, dc=com > URI ldap://mmam01.com ldaps://mmam01.com ldap://mmam04.com ldaps:// > mmam04.com ldap://sjam01.com ldaps://sjam01.com > TLS_REQCERT demand > TLS_CACERT /etc/openldap/cacerts/cacert.pem > > slapd.conf file(from mmam01) > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/nis.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/openldap.schema > include /etc/openldap/schema/dyngroup.schema > include /etc/openldap/schema/ppolicy.schema > include /etc/openldap/schema2/channelIdentifier.schema > include /etc/openldap/schema2/platform.schema > include /etc/openldap/schema2/extendedProfileKey.schema > include /etc/openldap/schema2/extendedProfileValue.schema > include /etc/openldap/schema2/behaviorKey.schema > include /etc/openldap/schema2/behaviorValue.schema > include /etc/openldap/schema2/questionAnswer.schema > include /etc/openldap/schema2/extendedTop.schema > include /etc/openldap/schema2/counter.schema > serverid 1 > TLSCipherSuite HIGH:MEDIUM:+SSLv3 > TLSCACertificateFile /etc/openldap/cacerts/cacert.pem > TLSCertificateFile /etc/openldap/cacerts/mmam01.crt > TLSCertificateKeyFile /etc/openldap/cacerts/mmam01.key > TLSVerifyClient never > pidfile /var/symas/run/slapd.pid > argsfile /var/symas/run/slapd.args > loglevel sync stats > idletimeout 30 > writetimeout 30 > modulepath /etc/openldap/lib64/openldap > moduleload back_mdb.la > moduleload ppolicy.la > moduleload unique.la > moduleload syncprov.la > database mdb > suffix "dc=example,dc=com" > directory /openldap/var/data > access to attrs=userPassword > by self write > by anonymous auth > by * break > > access to * > by > group/groupOfUniqueNames/uniqueMember.exact="cn=PWrite,ou=bGroup,dc=example,dc=com" > manage > by > group/groupOfUniqueNames/uniqueMember.exact="cn=PRead,ou=bGroup,dc=example,dc=com" > read > by * break > access to * > by self write > by anonymous auth > by * read > rootdn "cn=Manager,dc=example,dc=com" > rootpw {SSHA}dXDESQeFjSoa/A1HfJ2TAzYf4DrSYWY > index > mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,type > eq > index givenName,sn,city,cn,extName sub > index displayName approx > index entryCSN,entryUUID eq > checkpoint 128 15 > maxsize 274877906944 > syncrepl rid=111 > provider=ldap://sjam01.com > binddn="cn=Manager,dc=example,dc=com" > bindmethod=simple > credentials=0m2013 > tls_cacert=/etc/openldap/cacerts/cacert.pem > searchbase="dc=example,dc=com" > type=refreshAndPersist > retry="5 5 60 +" > network-timeout=10 > timeout=10 > syncrepl rid=222 > provider=ldap://mmam04.com > binddn="cn=Manager,dc=example,dc=com" > bindmethod=simple > credentials=0m2013 > tls_cacert=/etc/openldap/cacerts/cacert.pem > searchbase="dc=example,dc=com" > type=refreshAndPersist > retry="5 5 60 +" > network-timeout=10 > timeout=10 > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > mirrormode true > overlay unique > unique_attributes mail > overlay ppolicy > ppolicy_default "cn=default,ou=pwdPolicy,dc=example,dc=com" > ppolicy_use_lockout > > logs > > DR-sj > > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > > mmam04 > > Jan 12 14:53:24 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:53:24 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:53:25 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:53:25 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > > mmam01 > Users are add on this server > > > Jan 12 14:53:26 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55dd4fa120 20130112195326.941804Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=291 RESULT tag=105 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55d010ee30 20130112195326.941804Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=292 MOD > dn="extName=PIT,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=292 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55deffc210 20130112195327.100182Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=292 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55d8392770 20130112195327.100182Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=293 MOD > dn="extName=RVW,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=293 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f560a22e210 20130112195327.103686Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=293 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55fc6f35e0 20130112195327.103686Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 MOD > dn="extName=ICA,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55f3ffd210 20130112195327.107815Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55f3ffd210 20130112195327.107815Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55e87ae550 20130112195327.107815Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=295 MOD > dn="extName=RVP,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=295 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55f0cf8210 20130112195327.112994Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=295 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55e4618780 20130112195327.112994Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=296 MOD > dn="extName=RAD,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=296 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55dd4f9210 20130112195327.117321Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=296 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55d0001490 20130112195327.117321Z#000000#001#000000 > > > I have tried adding users and changing passwords one by one, it doesn't > work. > I can search old entries from one server to other server. > > -- Thanks&Regards Anil Beniwal +919891695048

3 6

about Too many executing
by rodrigo tavares 22 Jan '13

22 Jan '13

Hello ! I'm see my logs, many messagens come: deferring operation: too many executing. Search in Google, I found informations, about message. First: "too many executing" is undesirable. Second: It means there are too many operations active on the given connection, so mais operations on that connection will be queued until some of the active operations complete. It is cause some problem for the sytem, memory or slapd ? Thanks: Rodrigo

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical