openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6834) Conversion to cn=config needs more detail
by andrew.findlay＠skills-1st.co.uk 16 Feb '11

16 Feb '11

On Wed, Feb 16, 2011 at 11:50:21AM +0000, Andrew Findlay wrote: > Admin Guide Section 5.4. "Converting old style slapd.conf(5) file to cn=config > format" suggests that it is enough to run a slapd tool with both -f and -F > options to perform this conversion. While strictly true, this will almost > certainly result in an un-manageable server because there is no rootPW set for > cn=config. > > The attached patch provides guidance to avoid this trap. It would also be useful to copy the config database clause from slapd-config(5) into the example in the Admin Guide: # set a rootpw for the config database so we can bind. # deny access to everyone else. dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy olcAccess: to * by * none Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

(ITS#6834) Conversion to cn=config needs more detail
by andrew.findlay＠skills-1st.co.uk 16 Feb '11

16 Feb '11

Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/afindlay-slapdconf2.sdf.20110216.diff Submission from: (NULL) (88.97.25.132) Admin Guide Section 5.4. "Converting old style slapd.conf(5) file to cn=config format" suggests that it is enough to run a slapd tool with both -f and -F options to perform this conversion. While strictly true, this will almost certainly result in an un-manageable server because there is no rootPW set for cn=config. The attached patch provides guidance to avoid this trap.

1 0

(ITS#6833) LDAP hangs on Solaris
by tombolala＠gmx.de 16 Feb '11

16 Feb '11

Full_Name: Thomas Bopp Version: 4.2.22 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.47.255.100) After approximately one week our LDAP stops working and hangs (we had this situation several times). We have the www.sunfreeware.com package of LDAP installed. It had a bunch of connection in CLOSE_WAIT state (indicating basically that a close request has come in but slapd did not serve it). Making a truss on the process showed all threads blocked on lwp_cond_wait. I really need a solution for this problem.

1 0

(ITS#6832) fix #elif statement
by naota＠elisp.net 16 Feb '11

16 Feb '11

Full_Name: Naohiro Aota Version: 2.4.23 OS: Gentoo/FreeBSD 8.0 URL: http://elisp.net/openldap.patch Submission from: (NULL) (125.102.92.74) There are some #elif statements like "#elif FOOBAR", which should be "#elif defined(FOOBAR)". These statements might cause build error like this: i686-gentoo-freebsd8.0-gcc -O2 -pipe -march=prescott --param l1-cache-size=16 --param l1-cache-line-size=64 -mtune=prescott -D_GNU_SOURCE -I../../include -I../../include -I/usr/include/db4.8 -I/usr/include/db4.8 -c -o detach.o detach.c detach.c:131:7: error: missing binary operator before token "long" gmake[2]: *** [detach.o] Error 1 gmake[2]: Leaving directory `/usr/tmp/portage/net-nds/openldap-2.4.23/work/openldap-2.4.23/libraries/liblutil' gmake[1]: *** [all-common] Error 1 gmake[1]: Leaving directory `/usr/tmp/portage/net-nds/openldap-2.4.23/work/openldap-2.4.23/libraries' gmake: *** [all-common] Error 1 Build Environment: Gentoo/FreeBSD 8.0 gcc 4.4.4 URL is a address of the patch to fix the statements.

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 15 Feb '11

15 Feb '11

Also, this is not the same as ITS#6242, because the patch for that issue (adding the manageDSAit control) already exists in the versions of OpenLDAP I've tested with (2.4.21, 2.4.23).

1 0

Re: (ITS#6217) proxycache not returning cached data
by hyc＠symas.com 15 Feb '11

15 Feb '11

ryans(a)aweber.com wrote: > I am experiencing what appears to be the same issue, and opened a ticket - > http://www.openldap.org/its/index.cgi?findid=6831 - because this one did not pop up when I searched for existing ITS's > (perhaps my search terms did not match or I just overlooked it). As I mentioned in the ticket I opened, this is not a > schema issue - all the schema match on every server, and if that were the problem, none of the users would be served > properly. What I found is that the keys that proxycache was looking for did not exist in the bdb it was searching. Why > exactly that is, I'm not sure. Hopefully the information I provided in that ITS (or, perhaps some additional debugging > information - gdb output or copies of databases exhibiting the problem) will help shed some light. If it is indeed the > same issue, I'm all for coalescing the two. I have tested this all the way up through 2.4.23, and there are no commits > to pcache.c or back-ldap/search.c since 2.4.23 was released that addresses this problem. Since you are not having the objectclass-related problem described in this ticket it is not the same issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6217) proxycache not returning cached data
by ryans＠aweber.com 15 Feb '11

15 Feb '11

I am experiencing what appears to be the same issue, and opened a ticket - http://www.openldap.org/its/index.cgi?findid=6831 - because this one did not pop up when I searched for existing ITS's (perhaps my search terms did not match or I just overlooked it). As I mentioned in the ticket I opened, this is not a schema issue - all the schema match on every server, and if that were the problem, none of the users would be served properly. What I found is that the keys that proxycache was looking for did not exist in the bdb it was searching. Why exactly that is, I'm not sure. Hopefully the information I provided in that ITS (or, perhaps some additional debugging information - gdb output or copies of databases exhibiting the problem) will help shed some light. If it is indeed the same issue, I'm all for coalescing the two. I have tested this all the way up through 2.4.23, and there are no commits to pcache.c or back-ldap/search.c since 2.4.23 was released that addresses this problem.

1 0

Re: (ITS#6831) Proxycache database corruption
by ryans＠aweber.com 15 Feb '11

15 Feb '11

This may also be related to ITS#6217 (http://www.openldap.org/its/index.cgi?findid=6217). In fact, I'm pretty sure it is. In response to the last question in that ITS posed by Howard Chu (Followup 18), the schema on the proxy servers match the schema available on the primary servers exactly. If not, it wouldn't work for some users and not others simultaneously (that is, users who have the same objectClasses and attributes, and differ only in the user-specific attribute values like uid, gecos, phone extension, etc.). Hopefully the data and logs I was able to provide (and any debugger output/cache databases that might be requested of me as the ITS moves forward) will help to fill in some of the blanks.

1 0

(ITS#6831) Proxycache database corruption
by ryans＠aweber.com 15 Feb '11

15 Feb '11

Full_Name: Ryan Steele Version: 2.4.23 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ryan-steele-110215.proxycache-failure.log Submission from: (NULL) (207.106.239.81) I use back-ldap + proxycache on many of my servers to reduce network traffic and to alleviate load on the masters, as well as to maintain service continuity in the event of a network failure. However, we have recently been noticing an issue where the proxycache database claims that it has the data and that the query is answerable, but fails to read data from any of the indices it thinks the data is at. It happens randomly, and to random entries. We do not cache negative search results, so the cache should never return nentries=0 authoritatively. I can temporarily fix it for some broken users by restarting slapd and clearing the cache (i.e., pcachePersist is set to FALSE), but inevitably others stop working (or sometimes, the same users stop working). When this happens, most entries are still served from the cache just fine, but the entries that aren't never will unless slapd is restarted. I have tested this with 2.4.17, 2.4.21, and 2.4.23, using the amd64 architecture, and with libdb4.6 and libdb4.7. Included below is the slapd.conf I use on my back-ldap + proxycache nodes, an example of the behavior using ldapsearch, and the log messages during a failed search in which using log level 16383: ## Proxycache slapd configuration # Schema include /etc/ldap/schema/core.schema include /etc/ldap/schema/collective.schema include /etc/ldap/schema/corba.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/java.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/examplecom.schema include /etc/ldap/schema/rfc2307bis.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/apple_auxiliary.schema include /etc/ldap/schema/apple.schema # System pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel stats TLSCACertificateFile /etc/ldap/ssl/certs/cacert.pem TLSCertificateFile /etc/ldap/ssl/certs/openldap.cert.pem TLSCertificateKeyFile /etc/ldap/ssl/keys/openldap.key.pem TLSVerifyClient never # Modules modulepath /usr/lib/ldap moduleload back_ldap.la moduleload back_hdb.la moduleload pcache.la # Back-LDAP database ldap uri "ldap://ldapmaster.example.com" suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw SECRET tls start # ACLs access to attrs=userPassword by tls_ssf=128 ssf=128 self write by tls_ssf=128 ssf=128 anonymous auth by tls_ssf=128 ssf=128 group/groupOfURLs/Member="cn=ops,ou=Groups,dc=example,dc=com" write by tls_ssf=128 ssf=128 * compare access to * by tls_ssf=128 ssf=128 self write by tls_ssf=128 ssf=128 group/groupOfURLs/Member="cn=ops,ou=Groups,dc=example,dc=com" write by tls_ssf=128 ssf=128 * read # ProxyCache overlay pcache proxycache hdb 500000 1 5000 86400 directory /var/lib/ldap/proxycache index cn eq index departmentName eq index entryCSN eq index entryUUID eq index gidNumber eq index mail eq index member eq index memberUid eq index objectClass eq index pcacheQueryid eq index uid eq index uidNumber eq index uniqueMember eq proxycachequeries 1000000 proxyattrset 0 apple-user-homeDirectory blogCategory cn dateCreated departmentName departmentNumber description displayColor employeeNumber gecos getsPages gidNumber givenName homeDirectory htaccessPasswd isAvailable isPhoneOperator lastAdminVisit loginShell mail manager member memberUid mobile mobileEmail numTickets objectClass ou phoneExtension sn sortOrder uid uidNumber uniqueMember userPassword proxytemplate (blogCategory=) 0 86400 proxytemplate (cn=) 0 86400 proxytemplate (dateCreated=) 0 86400 proxytemplate (departmentName=) 0 86400 proxytemplate (departmentNumber=) 0 86400 proxytemplate (description=) 0 86400 proxytemplate (displayColor=) 0 86400 proxytemplate (employeeNumber=) 0 86400 proxytemplate (gecos=) 0 86400 proxytemplate (getsPages=) 0 86400 proxytemplate (gidNumber=) 0 86400 proxytemplate (givenName=) 0 86400 proxytemplate (homeDirectory=) 0 86400 proxytemplate (apple-user-homeDirectory=) 0 86400 proxytemplate (htaccessPasswd=) 0 86400 proxytemplate (isAvailable=) 0 86400 proxytemplate (isPhoneOperator=) 0 86400 proxytemplate (lastAdminVisit=) 0 86400 proxytemplate (loginShell=) 0 86400 proxytemplate (mail=) 0 86400 proxytemplate (manager=) 0 86400 proxytemplate (member=) 0 86400 proxytemplate (memberUid=) 0 86400 proxytemplate (memberURL=) 0 86400 proxytemplate (mobile=) 0 86400 proxytemplate (mobileEmail=) 0 86400 proxytemplate (numTickets=) 0 86400 proxytemplate (objectClass=) 0 86400 proxytemplate (ou=) 0 86400 proxytemplate (phoneExtension=) 0 86400 proxytemplate (sn=) 0 86400 proxytemplate (sortOrder=) 0 86400 proxytemplate (uid=) 0 86400 proxytemplate (uidNumber=) 0 86400 proxytemplate (uniqueMember=) 0 86400 proxytemplate (|(memberUid=)(member=)) 0 86400 proxytemplate (|(memberUid=)(uniqueMember=)) 0 86400 proxytemplate (&(objectClass=)(uid=)) 0 86400 proxytemplate (&(objectClass=)(memberUid=)) 0 86400 proxytemplate (&(objectClass=)(uniqueMember=)) 0 86400 proxytemplate (&(objectClass=)(uidNumber=)) 0 86400 proxytemplate (&(objectClass=)(gidNumber=)) 0 86400 proxytemplate (&(objectClass=)(|(memberUid=)(member=))) 0 86400 proxytemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 86400 proxytemplate (&(objectClass=)(member=)) 0 86400 proxytemplate (&(objectClass=)(cn=)) 0 86400 proxytemplate (&(|(objectClass=)(objectClass=))(uid=)) 0 86400 ## example of the failures using ldapsearch bash:~# for i in `seq 1 14`; do echo "PROCESSING jdoe$i"; ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe'$i'))' uid; sleep 1; done PROCESSING jdoe1 dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 PROCESSING jdoe2 dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 PROCESSING jdoe3 dn: uid=jdoe3,ou=Users,dc=example,dc=com uid: jdoe3 PROCESSING jdoe4 dn: uid=jdoe4,ou=Users,dc=example,dc=com uid: jdoe4 PROCESSING jdoe5 PROCESSING jdoe6 PROCESSING jdoe7 PROCESSING jdoe8 PROCESSING jdoe9 PROCESSING jdoe10 PROCESSING jdoe11 PROCESSING jdoe12 PROCESSING jdoe13 PROCESSING jdoe14 bash:~# A log file (with log level set to 16383) showing what happens when the cache is queried and it responds with "QUERY ANSWERABLE", and then fails to read data from any of the indices referenced, can be found at ftp://ftp.openldap.org/incoming/ryan-steele-110215.proxycache-failure.log. It seems similar to ITS#6242, but my version of pcache.c, at least in the 2.4.21 and 2.4.23 versions of OpenLDAP, definitely contain that patch, as I can see it in the source (the manageDSAit control). Please let me know if you need any other information to debug this problem (e.g., specific variables from a debugger run, copy of a proxycache database experiencing the problem, etc.)

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 15 Feb '11

15 Feb '11

Howard Chu wrote: > Yes, several objections. Post diffs that can be applied by the "patch" > command, not the complete file. See below. > If you're going to add more rules, make > them conform to the standard Makefiles. E.g. the correct macro is > "prefix" not "PREFIX". Not consequently used in contrib/slapd-modules/. Therefore I didn't know this. Ciao, Michael. Index: Makefile =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/contrib/slapd-modules/lastbind/Makefile,v retrieving revision 1.2.2.2 diff -u -r1.2.2.2 Makefile --- Makefile 4 Feb 2011 23:39:17 -0000 1.2.2.2 +++ Makefile 15 Feb 2011 14:48:30 -0000 @@ -10,6 +10,8 @@ # top-level directory of the distribution or, alternatively, at # <http://www.OpenLDAP.org/license.html>. +prefix=/usr/local + CPPFLAGS+=-I../../../include -I../../../servers/slapd CPPFLAGS+=-DSLAPD_OVER_LASTBIND=SLAPD_MOD_DYNAMIC #LIBTOOL=libtool @@ -23,7 +25,12 @@ lastbind.la: lastbind.lo $(LIBTOOL) --mode=link $(CC) -version-info 0:0:0 \ - -rpath $(PREFIX)/lib -module -o $@ $? + -rpath $(prefix)/lib -module -o $@ $? clean: rm -rf lastbind.lo lastbind.la lastbind.o .libs/ + +install: lastbind.la + mkdir -p $(prefix)/libexec/openldap + $(LIBTOOL) --mode=install cp lastbind.la $(prefix)/libexec/openldap + $(LIBTOOL) --finish $(prefix)/libexec/openldap

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs