openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7578) delta-sync multimaster replication issue
by afrunning＠gmail.com 26 Apr '13

26 Apr '13

Full_Name: Al F Version: 2.4.35 OS: Redhat 6.4 - x64 URL: https://dl.dropboxusercontent.com/u/982376/its/al-f-130426.zip Submission from: (NULL) (74.123.146.10) Hi, I have a multimaster system utilizing delta-sync for replication. The system is utilizing mdb for both the user and the accesslog data. I have ppolicy & memberof overlays enabled as well. all of my writes are directed at a single server using a load balancer. I have found that when a user has a pwdFailureTime attribute set on their entry, if an administrator resets the password, "null_callback : error code 0x10" is produced in the log on the secondary system and the secondary system goes into refresh mode. The mentioned zip file contains most of my configuration as well a portion of the log when the issue occurred. The log was generated during a failure with -d-1 to slapd. I have a lot more log from before and after the issue however it is littered with sensitive data, so I didn't want to redact it unless necessary. Please let me know what else I can do to help. Regards, Al

1 0

Re: ITS#7552
by Matthew.Monaco＠colorado.edu 24 Apr '13

24 Apr '13

This is a multi-part message in MIME format. --------------010002070300090900000609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Caching queries with * attributes broken (compiled from 260fd69, RE24 HEAD). This works: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' This does not: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' uid I also have a problem where the attribute set is set to (nssov_passwd_byname): uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass For this, nssov does not work (I see cacheable, but the query never gets cached). However, this does work: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' uid (Also, test020 passes) --------------010002070300090900000609 Content-Type: text/plain; charset=UTF-8; name="slapd-master.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-master.conf" ######## ## ## CSEL ## ## # Modules #modulepath /usr/lib/ldap moduleload back_mdb.so moduleload nssov.so ## # Schema 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/misc.schema include /etc/openldap/schema/ldapns.schema ## # System pidfile /run/slapd/slapd.pid argsfile /run/slapd/slapd.args loglevel 256 sizelimit 5000 TLSCACertificateFile /etc/openldap/ldap-csel-ca.crt TLSCertificateFile /etc/openldap/ldap-csel.crt TLSCertificateKeyFile /etc/openldap/ldap-csel.key ## # ACLs access to attrs=userPassword by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage by self =xw by anonymous auth by * none #access to dn.children="ou=users,dc=cs,dc=colorado,dc=edu" # by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage # by self read # by * none #access to dn.children="ou=groups,dc=cs,dc=colorado,dc=edu" attrs=memberUid # by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage # by users search # by * none access to * by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage by users read by * read ## # Backend (mdb) database mdb directory /var/lib/openldap/csel.mdb maxsize 1073741824 suffix dc=cs,dc=colorado,dc=edu index default eq index objectClass index cn index uid index uidNumber index gidNumber index memberUid index uniqueMember index entryCSN ## # Overlay (nssov) overlay nssov nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one --------------010002070300090900000609 Content-Type: text/plain; charset=UTF-8; name="slapd-client.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-client.conf" ####### ## ## CSEL ## ## # Modules moduleload back_ldap.so moduleload back_mdb.so moduleload pcache.so moduleload nssov.so ## # Schema 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/misc.schema include /etc/openldap/schema/ldapns.schema ## # System pidfile /run/slapd/slapd.pid argsfile /run/slapd/slapd.args sizelimit 10000 ## # Backend (ldap) database ldap uri ldaps://xxx.colorado.edu/ tls ldaps tls_reqcert=allow suffix dc=cs,dc=colorado,dc=edu rootdn cn=pcache,ou=sys,dc=cs,dc=colorado,dc=edu ## # Overlay (proxy cache) overlay pcache pcache mdb 10000 1 256 120 pcacheOffline TRUE directory /var/lib/openldap/pcache.mdb maxsize 67108864 index default eq index objectClass index cn index uid index uidNumber index gidNumber index memberUid index uniqueMember pcacheAttrset 0 * pcacheTemplate (&(objectClass=)(uid=)) 0 3600 ## # Overlay (nssov) overlay nssov nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one --------------010002070300090900000609--

1 0

(ITS#7577) hdb and mdb derefere aliases differently
by juergen.sprenger＠swisscom.com 24 Apr '13

24 Apr '13

Full_Name: Juergen Sprenger Version: 2.4.35 OS: Gentoo Base System release 2.1, Kernel 3.7.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.5.238.18) mdb dereference aliases problem. I use aliases to keep information about a person who has multiple accounts consistent over all accounts and avoid redundancy, example: dn: uid=joe,ou=Account,dc=its,dc=scom objectClass: alias objectClass: extensibleObject uid: joe aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom structuralObjectClass: alias When using hdb as backend for slapd everything works fine, and user are authenticated properly: # running 'getent passwd' with hdb backend: Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=656 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection lost) When using mdb as backend with same directory content, users are no longer authenticated, search returns nentries=0: # running 'getent passwd' with mdb backend: Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection lost) Both setups have identical md5sum of slapcat output, so directory content can be assumed identical in my opinion.

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 23 Apr '13

23 Apr '13

--Apple-Mail-2--242372278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth wrote: >=20 > You can instead look for a mechanism with built-in credential passing, > apparently like Solaris "doors". =20 The sample client-server programs, see link below, show an experiment on = Solaris 8 that server creates and listens to door calls, while client = invokes them. When client invokes a door_call, server gets the euid and = egid, among others, of the client: https://dl.dropboxusercontent.com/u/94235048/door_call.tgz http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.html # ./server successfully created a door euid (101) egid (1) ruid (101) rgid (1) pid (8947) $ id uid=3D101(tedcheng) gid=3D1(other) $ ./client pid (8947): door_call succeeded There is the situation in which we are sending/getting client = credentials from a door call through say /tmp/door, while service = requests, such as nssov/nslcd (nss-pam-ldapd), through a separate Unix = domain socket. There is therefore the need to tie client credentials = with their respective (name) service requests; "doors" implements its = own threading support. The work to integrate doors for client credential = support into a server with threading support, such as slapd, may get = complicated fast. "Doors" does not seem to be a feasible solution for sending client = credentials in a context such as nssov/slapd. > Or look at what some other well-tested > and portable package does and suggest we steal its code.=20 >=20 This may be the only option, if there exists one, for older-system = support (Solaris 8). Ted C. Cheng Symas Corporation --Apple-Mail-2--242372278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div><div>On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth = wrote:</div><blockquote type=3D"cite"><div><font = class=3D"Apple-style-span" color=3D"#000000"><br></font>You can instead = look for a mechanism with built-in credential passing,<br>apparently = like Solaris "doors". =  </div></blockquote><div><br></div><div><div>The = sample client-server programs, see link below, show an experiment = on Solaris 8 that server creates and listens to door calls, while client = invokes them. When client invokes a door_call, server gets the euid and = egid, among others, of the client:</div><div><br></div><div><a = href=3D"https://dl.dropboxusercontent.com/u/94235048/door_call.tgz">https:= //dl.dropboxusercontent.com/u/94235048/door_call.tgz</a></div><div><br></d= iv><div><a = href=3D"http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.= html">http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.ht= ml</a></div><div><br></div><div># ./server<br>successfully created a = door<br>euid (101) egid (1) ruid (101) rgid (1) pid (8947)<br><br>$ = id<br>uid=3D101(tedcheng) gid=3D1(other)<br>$ ./client<br>pid (8947): = door_call succeeded</div><div><br></div><div>There is the situation = in which we are sending/getting client credentials from a door call = through say /tmp/door, while service requests, such as nssov/nslcd = (nss-pam-ldapd), through a separate Unix domain socket. There is = therefore the need to tie client credentials with their respective = (name) service requests; "doors" implements its own threading = support. The work to integrate doors for client credential support into = a server with threading support, such as slapd, may get complicated = fast.</div><div><br></div><div>"Doors" does not seem to be a feasible = solution for sending client credentials in a context such as = nssov/slapd.</div></div><br><blockquote type=3D"cite"><div>Or look at = what some other well-tested<br>and portable package does and suggest we = steal its code. <font class=3D"Apple-style-span" = color=3D"#006312"><br></font></div></blockquote><blockquote = type=3D"cite"><div><br></div></blockquote><br></div><div>This may be the = only option, if there exists one, for older-system support (Solaris = 8).</div><div><br></div><div><br></div><div><div>Ted C. = Cheng</div><div>Symas = Corporation</div></div><div><br></div><div><br></div></body></html>= --Apple-Mail-2--242372278--

1 0

Re: ITS#7518
by hyc＠symas.com 23 Apr '13

23 Apr '13

Matthew.Monaco(a)colorado.edu wrote: > commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build > > were updated files omitted from the nss-pam-ldapd directory? Yes, it looks like it. Updated files now pushed to git master, thanks for the report. -- -- 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#7518
by Matthew.Monaco＠colorado.edu 23 Apr '13

23 Apr '13

commit c3411fb breaks building, reverting on OPENLDAP_REL_ENG_2_4 allows me to build were updated files omitted from the nss-pam-ldapd directory?

1 0

Re: (ITS#7576) olcLogFile does not work on Ubuntu 12.04
by quanah＠zimbra.com 18 Apr '13

18 Apr '13

--On Tuesday, April 16, 2013 5:06 PM +0000 hvnsweeting(a)gmail.com wrote: > Full_Name: Nguyen Viet Hung > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.16.114.114) > > > I tried this directive on Ubuntu but it does not work. > Someone on openldap IRC said that > "olclogfile is only used on windows, because it lacks syslog" > > If he is right, please do change OpenLDAP document to make this less > confusing. Thanks Incorrect. Please read the slapd-config(5) man page. There is no issue using the logfile on linux. If you have questions on how to create one, please follow up with the openldap-technical list. This ITS will be closed. I would generally note that on linux setting the olcLogfile is not necessary, but if you must catch the stderr messages, you may which to do so. I would also note the version of OpenLDAP you are using is quite ancient. You'd be better served to upgrade to a current release. --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

(ITS#7576) olcLogFile does not work on Ubuntu 12.04
by hvnsweeting＠gmail.com 16 Apr '13

16 Apr '13

Full_Name: Nguyen Viet Hung Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.16.114.114) I tried this directive on Ubuntu but it does not work. Someone on openldap IRC said that "olclogfile is only used on windows, because it lacks syslog" If he is right, please do change OpenLDAP document to make this less confusing. Thanks

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by claude.brisson＠gmail.com 16 Apr '13

16 Apr '13

Ok, I understand, now. I totally overlooked the definition of MDB_NEXT_MULTIPLE, which I believed was here to return all the duplicate of the next key. Really sorry about all that noise. You may be interested in keeping the following little change from my patch, though: @@ -4377,6 +4377,8 @@ mdb_cursor_next(MDB_cursor *mc, MDB_val *key, MDB_val *data, MDB_cursor_op op) rc = mdb_cursor_first(&mc->mc_xcursor->mx_cursor, data, NULL); if (rc != MDB_SUCCESS) return rc; + } else if (mc->mc_db->md_flags & MDB_DUPSORT) { + mc->mc_xcursor->mx_cursor.mc_flags &= ~C_INITIALIZED; } } mdb_cursor_next should invalidate mx_cursor when there is no duplicate data for the current key. It's maybe useless if we are sure that we won't ever rely on this flag thereafter, but it's certainly safer. Regards, Claude On Mon, 15 Apr 2013 13:42:40 -0700 Howard Chu <hyc(a)symas.com> wrote: > claude.brisson(a)gmail.com wrote: > > On Mon, 15 Apr 2013 20:01:01 GMT > > hyc(a)symas.com wrote: > > > >> Your patch changes the meaning of these operations. > >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already > >> documented as such. > > > > The documentation in the header never states that MULTIPLE > > operations should *fail* on singletons. One could expect that the > > sentence "Return all the duplicate data items at the current cursor > > position" means that singletons will *also* be returned, without > > having to resort to a second call in case of failure. > > > >> Your patch makes them return non-duplicate data. This is a > >> fundamental change in an established behavior. A complete break, > >> actually; it will return data that doesn't match the key that the > >> client requested. It is completely wrong. > > > > I'm sorry if it broke something and made you loose your time, I was > > trying to help here. But the only change is to return singletons > > instead of MDB_NOTFOUND - the data will always match the key. > > No. This is in your patch: > > @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, > MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) > rc = mdb_cursor_first(mc, key, data); > else > - rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_DUP); > + rc = mdb_cursor_next(mc, key, data, > MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { > if (mc->mc_xcursor->mx_cursor.mc_flags & > C_INITIALIZED) { MDB_cursor *mx; > > So you've made it return non-matching data. > > > Maybe I missed something, here. But I wonder why the client code > > should at any point *expect* truly duplicate data. > > That is the sole purpose of these options. > > Re-read the description: > > MDB_GET_MULTIPLE, /**< Return all the duplicate data items > at the current > cursor position. Only for > #MDB_DUPFIXED */ > > If the current cursor position is a singleton, then you already have > its data if you positioned the cursor using (&key, &data) so there is > no need to make any further calls anyway. >

1 0

Re: (ITS#7570) fix MDB_GET_MULTIPLE and MDB_NEXT_MULTIPLE behaviour
by hyc＠symas.com 15 Apr '13

15 Apr '13

claude.brisson(a)gmail.com wrote: > On Mon, 15 Apr 2013 20:01:01 GMT > hyc(a)symas.com wrote: > >> Your patch changes the meaning of these operations. >> GET_MULTIPLE/NEXT_MULTIPLE is *only* for duplicate data and already >> documented as such. > > The documentation in the header never states that MULTIPLE operations > should *fail* on singletons. One could expect that the sentence "Return > all the duplicate data items at the current cursor position" means > that singletons will *also* be returned, without having to resort to a > second call in case of failure. > >> Your patch makes them return non-duplicate data. This is a >> fundamental change in an established behavior. A complete break, >> actually; it will return data that doesn't match the key that the >> client requested. It is completely wrong. > > I'm sorry if it broke something and made you loose your time, I was > trying to help here. But the only change is to return singletons > instead of MDB_NOTFOUND - the data will always match the key. No. This is in your patch: @@ -4803,7 +4806,7 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, MDB_val *data, if (!(mc->mc_flags & C_INITIALIZED)) rc = mdb_cursor_first(mc, key, data); else - rc = mdb_cursor_next(mc, key, data, MDB_NEXT_DUP); + rc = mdb_cursor_next(mc, key, data, MDB_NEXT_NODUP); if (rc == MDB_SUCCESS) { if (mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) { MDB_cursor *mx; So you've made it return non-matching data. > Maybe I missed something, here. But I wonder why the client code should > at any point *expect* truly duplicate data. That is the sole purpose of these options. Re-read the description: MDB_GET_MULTIPLE, /**< Return all the duplicate data items at the current cursor position. Only for #MDB_DUPFIXED */ If the current cursor position is a singleton, then you already have its data if you positioned the cursor using (&key, &data) so there is no need to make any further calls anyway. -- -- 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

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