- openldap-bugs - openldap.org

(ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by andrew.findlay＠skills-1st.co.uk 17 Feb '11

17 Feb '11

Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/afindlay-slapi-doc-patch-20110217a Submission from: (NULL) (88.97.25.132) This documentation patch affects the Admin Guide and one manpage. It gives information about the ldapi: transport and the use of SASL EXTERNAL with it. The SASL EXTERNAL section also contains a small expansion on the use of TLS.

1 0

(ITS#6838) TLS client will not accept certificate for 'localhost'
by andrew.findlay＠skills-1st.co.uk 17 Feb '11

17 Feb '11

Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.97.25.132) For various test and teaching purposes I have a set of OpenLDAP configs that run small servers intended for local access only. As I run these on a wide variety of machines and also give them to students to run on their own machines, all the LDAP clients are set up to access the servers via the loopback interface: typically ldap://localhost:1389/ Some of the configs use TLS. I have a local CA which issues simple server certs, usually with 'CN=localhost' as part of the subject name. Since upgrading the OS and OpenLDAP version of my main test environment I find that TLS connections are failing: > ldapsearch -d 768 -x -ZZ -H ldap://localhost:1389/ -b dc=example,dc=org sn=trott TLS: hostname (slab.skills-1st.co.uk) does not match common name in certificate (localhost). ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate slab.skills-1st.co.uk is indeed the name of the machine, but I asked to connect to 'localhost' so that is the name that should be checked against the certificate. If I put in any other alias for localhost in /etc/hosts and issue a certificate for that, the connection is OK so the problem is specific to the string 'localhost', not to the use of the loopback interface in general. I think the problem is in tlso_session_chkhost() in tls_o.c: if( ldap_int_hostname && ( !name_in || !strcasecmp( name_in, "localhost" ) ) ) { name = ldap_int_hostname; } else { name = name_in; } If I understand this correctly, the intention appears to be to allow a certificate issued for the FQDN of the machine to be accepted when it is presented on the loopback interface. This may be a reasonable thing to do, but the current implementation prevents the use of a certificate issued specifically for 'localhost'. My client scripts used to work: I think this was purely because earlier versions of the TLS client code were less careful about checking certificates. Specifically, the 'self signed certificate in certificate chain' error was not even reported unless client-side debugging was turned on.

1 0

(ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
by rhafer＠suse.de 17 Feb '11

17 Feb '11

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.243.151) After adding the following LDIF to cn=config (via ldapadd), slapd does not start anymore: ------------------------------------ dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectclass: olcChainConfig dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectclass: olcLDAPConfig objectclass: olcChainDatabase olcDbUri: ldap://ldap.server olcDatbase: {0}ldap ------------------------------------ To add some fun. Everything works as expected if I reorder the "objectClass" Values so that "olcLDAPConfig" appears after "olcChainDatabase". Additionally the error messages I get in the log when slapd fails to start with the above config seem to be completely unrelated: ------ olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix config error processing olcDatabase={0}config,cn=config: <olcRootPW> can only be set when rootdn is under suffix ------ The underlying problem seems to be that, when the "olcLDAPConfig" objectclass appears first slapd seems to choose the wrong ConfigTable for the olcDatabase attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the LDAP Database as if it were in "normal" database, including adding it to the backendDB list. As I configured the chain overlay as a global overlay this back-ldap database is put to the front of the backendDB list leading to problems when initializing the cn=config database itself, because the code assumes that the config database is always the first one, which will than lead to the strange error message above. (... that's how far I got with analyzing the problem, I have no idea yet how to fix it though. Suggestions are welcome.)

1 0

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

17 Feb '11

I believe this may be the same issue as in #6217, given this behavior with two users which have the same objectclasses, same attributes, and differ only in the attribute values (e.g., their name, phone number, and so on): The initial query, where one entry doesn't get returned as it should: ===================================================================== bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid If I reverse the filter, I get the expected results: ===================================================================== bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 Furthermore, if I now try the first query again, it too works: ===================================================================== bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 I already have the patch for ITS#5756 applied in all the versions I've tested (2.4.17, 2.4.21, and 2.4.23). I can provide a sample database which exhibits this behavior if needed, as I am working on providing a self-contained sanitized example already. If the developers agree that the issue described in these two ITS's are one and the same, I'm fine with marking this bug as a duplicate of ITS#6217 to avoid fragmentation of debugging efforts.

1 0

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

17 Feb '11

hyc(a)symas.com wrote: > > 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. Actually, having just tested that theory, I think my problem is actually objectclass-related, because it seems that it only happens when the objectClass attribute is included in the filter, and I can get different results by swapping the order of the filter components. Consider these two users, who have the same objectclasses, same attributes, and differ only in the attribute values (e.g., their name, phone number, and so on): bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid So, one entry doesn't get returned when it should. If I reverse the filter, I get the expected results: bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 Furthermore, if I now try the first query again, it too works: bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe1))' uid dn: uid=jdoe1,ou=Users,dc=example,dc=com uid: jdoe1 bash:~# ldapsearch -x -H ldaps://localhost -LLL -b ou=Users,dc=example,dc=com '(&(|(objectClass=examplecomEmployee)(objectClass=examplecomUtilityUser))(uid=jdoe2))' uid dn: uid=jdoe2,ou=Users,dc=example,dc=com uid: jdoe2 And, like Jim, I already have the patch for ITS#5756 applied in 2.4.17, 2.4.21, and 2.4.23. I can give you an example database exhibiting this behavior, if you like?

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 17 Feb '11

17 Feb '11

Howard Chu writes: > Agreed. I'm fine with dropping this configure switch and unifdef'ing it so > that librewrite is always used. Built unless --disable-slapd, I think. It is not installed, and the other libraries do not use it. -- Hallvard

1 0

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

17 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

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

17 Feb '11

On Wed, Feb 16, 2011 at 03:44:28PM -0800, Howard Chu wrote: > >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 > > That ACL is already the default. In an isolated example there's no > need to specify it. (It is present in the slapd-config(5) example to > ensure that it takes precedence over the olcFrontendConfig ACLs > immediately above it.) I was suggesting the inclusion of this entry mainly because of the olcRootPW, but as it would go into the config example in section 5.3 at about line 20, surely the ACL should be present for the same reason that it is in the manpage example? 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

Re: (ITS#6115) gdi32.lib required by OpenSSL+Windows
by hyc＠symas.com 17 Feb '11

17 Feb '11

slapd(a)hannebauer.name wrote: > Full_Name: Christoph Hannebauer > Version: 2.4.16 > OS: Windows/cygwin > URL: http://www.hannebauer.name/openldap-openssl/configure.in.patch > Submission from: (NULL) (139.18.40.169) > > > I tried to use OpenSSL 0.9.8k for TLS in my cygwin (target MinGW) OpenLDAP > build. The configure script does not detect OpenSSL (however, it doesn't break, > instead it finishes without TLS support), because the static library cannot be > linked. The config.log file contains error messages like > > /usr/local/mingw/lib/libcrypto.a(rand_win.o):rand_win.c:(.text+0xa0c): undefined > reference to `_CreateDCA@16' > > The missing functions are part of the library gdi32.lib. The OpenSSL readme file > INSTALL.W32 says, that Windows program using OpenSSL should link gdi32.lib (and > user32.lib, ..., but on my machine, gdi32.lib seems to be sufficient). Therefore > I have created the attached patch file to configure.in (1.697), which adds > gdi32.lib to LIBS, if it is required for OpenSSL. I have tested the patched > configure file on my machine, the build works without problems. You should simply add -lgdi32 to LIBS when running configure then, as documented in the INSTALL file. We add some platform-specific flags but we don't add site-specific flags to configure itself, and your problem depends on whether OpenSSL is using static or shared libraries on your installation. I.e., this issue is not generic to the Win32 platform. -- -- 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#6740) syncrepl/--disable-rewrite dependency
by hyc＠symas.com 17 Feb '11

17 Feb '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > configure should mention syncrepl here: > --enable-rewrite enable DN rewriting in back-ldap and rwm overlay > > test059-slave-config fails with --disable-rewrite. Testrun/test.out says > parse_syncrepl_line: > unable to parse "suffixmassage=cn=schema,cn=config,cn=slave" > > Ando wrote: >> What's special about DN rewriting so it has a configure option >> anyway? It doesn't disable building of libraries/librewrite. > > It used to, as far as I remember. I remember something about performing > simple suffixmassage when librewrite is not built. In any case I agree > that given the widespread usage of rewrite capabilities (authz regexp, for > example) not building librewrite is somehow pointless. Agreed. I'm fine with dropping this configure switch and unifdef'ing it so that librewrite is always used. -- -- 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

ITS#6512 BDB 5.0
by hyc＠symas.com 17 Feb '11

17 Feb '11

This was resolved by ITS#6698, support for BDB 5.x was released in 2.4.24. -- -- 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#6834) Conversion to cn=config needs more detail
by hyc＠symas.com 17 Feb '11

17 Feb '11

andrew.findlay(a)skills-1st.co.uk wrote: > 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 That ACL is already the default. In an isolated example there's no need to specify it. (It is present in the slapd-config(5) example to ensure that it takes precedence over the olcFrontendConfig ACLs immediately above it.) -- -- 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#6833) LDAP hangs on Solaris
by tombolala＠gmx.de 16 Feb '11

16 Feb '11

Hi Quanah! sorry for the wrong release, I meant 2.4.22 of course. /Thomas -------- Original-Nachricht -------- > Datum: Wed, 16 Feb 2011 16:34:39 GMT > Von: quanah(a)zimbra.com > An: openldap-its(a)openldap.org > Betreff: Re: (ITS#6833) LDAP hangs on Solaris > --On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de wrote: > > > Full_Name: Thomas Bopp > > Version: 4.2.22 > > > I really need a solution for this problem. > > I suggest you list an actual OpenLDAP release. It's near impossible to > help you without that. > > --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 > > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

(ITS#6835) extend pwFailureTime timestamp to microsecond resolution to improve pwdMaxFailure enforcement
by brian-ldap＠starvingprogrammer.com 16 Feb '11

16 Feb '11

Full_Name: Brian Wasserman Version: 2.4.21-0ubuntu5.3 OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.151.13.15) More than pwdMaxFailure attempts can be made before locking out an account if multiple attempts are made within the same second since it'll only log one pwdFailureTime per second. This is because the timestamp is stored in second resolution. Changing this timestamp to use microsecond resolution should minimize this limitation. In order to reproduce the problem by exceeding the number of max failures configured, just attempt to bind to a server with the policy below (or similar) multiple times per second with a valid user and observer the number of pwdFailureTime entries that are added to the given account. The account is locked after three pwdFailureTime entries are added, regardless of the number of actual attempts. Here's my policy configuration: dn: cn=Standard,ou=Policies,dc=local,dc=com cn: Standard description: Standard password policy. pwdAttribute: userPassword pwdCheckQuality: 1 pwdLockout: TRUE pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE objectClass: device objectClass: pwdPolicy pwdInHistory: 3 pwdMaxFailure: 3 pwdMinLength: 8 pwdMaxAge: 7776000 pwdMinAge: 86400

1 0

sortvals oddity
by Andrew Elble 16 Feb '11

16 Feb '11

I've run into the following issue while trying to track down why we are occasionally seeing duplicate members/memberUids in our groups: Set the server up for "sortvals memberUid". Add a posixGroup without any memberUid attributes present. Adding new memberUid attributes to the group afterwards will result in them being unsorted until server restart. I'm shooting from the hip here - shouldn't attr_merge() (in attr.c) have something like the following? if ( *a == NULL ) { *a = attr_alloc( desc ); if (desc->ad_type->sat_flags & SLAP_AT_SORTED_VAL) { (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; } } else { Thanks, Andy -- Andrew W. Elble aweits(a)discipline.rit.edu Infrastructure Engineer, Communications Technical Lead Rochester Institute of Technology PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

2 1

Re: (ITS#6833) LDAP hangs on Solaris
by quanah＠zimbra.com 16 Feb '11

16 Feb '11

--On Wednesday, February 16, 2011 11:37 AM +0000 tombolala(a)gmx.de wrote: > Full_Name: Thomas Bopp > Version: 4.2.22 > I really need a solution for this problem. I suggest you list an actual OpenLDAP release. It's near impossible to help you without that. --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

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

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 15 Feb '11

15 Feb '11

On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote: > >slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema > >fragments for pwdPolicySubentry and pwdAccountLockedTime. > > That's how they were defined in the IETF Draft. The schema fragments > in the manpage were copied directly from the spec. The fact that the > current implementation deviates from the spec is just out of > necessity to make things work at all in our present code base. Certainly the use of pwdPolicySubentry differs from the intention of the draft (which I believe was intending to use real X.500-style subentries). The case of pwdAccountLockedTime is arguable. draft-behera-ldap-password-policy-xx.txt says: This attribute holds the time that the user's account was locked. A locked account means that the password may no longer be used to authenticate. A 000001010000Z value means that the account has been locked permanently, and that only a password administrator can unlock the account. Unfortunately it says nothing about *how* a password administrator should do that when the attribute is marked NO-USER-MODIFICATION. I would argue that this is a deficiency in the draft, and that the current OpenLDAP behaviour is more useful. > Things will not always work this way... Indeed, but I would prefer the manpages to reflect the reality of the current release! 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

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 15 Feb '11

15 Feb '11

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.24 > OS: OpenSuSE 11.3 > URL: ftp://ftp.openldap.org/incoming/afindlay-ppolicy-man-patch-20110215 > Submission from: (NULL) (88.97.25.132) > > > slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema > fragments for pwdPolicySubentry and pwdAccountLockedTime. That's how they were defined in the IETF Draft. The schema fragments in the manpage were copied directly from the spec. The fact that the current implementation deviates from the spec is just out of necessity to make things work at all in our present code base. Things will not always work this way... > In addition, the description of pwdAccountLockedTime does not make it clear that > this attribute can be changed by administrative action. > > The attached patch is a suggested clarification for the manpage. -- -- 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

(ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by andrew.findlay＠skills-1st.co.uk 15 Feb '11

15 Feb '11

Full_Name: Andrew Findlay Version: 2.4.24 OS: OpenSuSE 11.3 URL: ftp://ftp.openldap.org/incoming/afindlay-ppolicy-man-patch-20110215 Submission from: (NULL) (88.97.25.132) slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema fragments for pwdPolicySubentry and pwdAccountLockedTime. In addition, the description of pwdAccountLockedTime does not make it clear that this attribute can be changed by administrative action. The attached patch is a suggested clarification for the manpage.

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠SonicWALL.com 15 Feb '11

15 Feb '11

I have tested a fix and uploaded the patch to ftp.openldap.org/incoming as = "ian-puleston-110214.patch". It includes small updates to 4 files in the op= enldap directory - ldap-int.h, open.c, request.c and cyrus.c. Note that I have not tested the change to cyrus.c since that file is not in= cluded in the build that I use, but it is pretty much the same as that to r= equest.c.

1 0

(ITS#6829) Auditlog Mod Patch
by ksmith8＠ycp.edu 14 Feb '11

14 Feb '11

Full_Name: Kyle Smith Version: 2.4.24 OS: Ubuntu 10.04 URL: http://faculty.ycp.edu/~ksmith8/patches/servers-slapd-overlays-auditlog.c.p… Submission from: (NULL) (192.245.87.12) This is an enhancement of the auditlog overlay. By using a new directive, auditlog_single_line, the auditlog is outputted on a single line, instead of the normal ldif style. I needed to make this change so that our log indexer doesn't have to parse lots of ldif data, instead it will just index the fields as written. This will also give the benefit of reduced filesize of the audit logs, as it shortens the record by a fair number of characters. How To configure: Add "auditlog_single_line" to the "overlay auditlog" configuration in slapd.conf.

1 0

(ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by ipuleston＠sonicwall.com 14 Feb '11

14 Feb '11

Full_Name: Ian Puleston Version: 2.4.23 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.115.118.5) When using TLS with OpenLDAP client the connection to the server sometimes fails if LDAP_OPT_CONNECT_ASYNC is being used. It appears to be a timing issue so it may work fine in some implementations, and in fact it works fine for me every time if I have any debug output turned on that prints before starting TLS. The problem is that ldap_int_tls_connect fails, and I'm pretty sure that it fails because it tries to start the TLS handshake before the connect has completed. Adding just one printf at the start of ldap_int_tls_connect delays it enough that it then works OK every time for me, presumably because the connect then completes first. If I set just the LDAP_DEBUG_PACKETS, LDAP_DEBUG_ARGS and LDAP_DEBUG_CONNS debug flags (0x0e) then it fails and I get just this one message printed: "TLS: can't connect: .". What appears to be missing is that before calling ldap_int_tls_start from ldap_int_open_connection a call to ldap_int_poll should be made to check if the connect has completed. Also, something similar may be required before calling ldap_start_tls_s from ldap_new_connection. It ends up calling back to ldap_send_initial_request, so will that work OK when the connection is in state LDAP_CONNST_CONNECTING? Will it result in LDAP_X_CONNECTING being returned?

1 0

Re: (ITS#6810) valgrind output
by masarati＠aero.polimi.it 11 Feb '11

11 Feb '11

Bruno HALEBLIAN wrote: > Hi, > > Attached here is valgrind output (some kind of crash I guess) > Hope it helps, I willl take a look and try to figure out what it says. There's clearly some invalid memory access, but the trace was probably obtained using a stripped binary; an unstripped binary would have probably given line numbers. Can you retry? p.

1 0

(ITS#6810) valgrind output
by bruno.haleblian＠gmail.com 11 Feb '11

11 Feb '11

--001636ed6965c05dfc049bfe938f Content-Type: text/plain; charset=ISO-8859-1 Hi, Attached here is valgrind output (some kind of crash I guess) Hope it helps, I willl take a look and try to figure out what it says. Regards, Bruno. --001636ed6965c05dfc049bfe938f Content-Type: application/octet-stream; name="vlvdir02.valgrind.out" Content-Disposition: attachment; filename="vlvdir02.valgrind.out" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gk0wu7wk0 PT02NjY3PT0gTWVtY2hlY2ssIGEgbWVtb3J5IGVycm9yIGRldGVjdG9yCj09NjY2Nz09IENvcHly aWdodCAoQykgMjAwMi0yMDA5LCBhbmQgR05VIEdQTCdkLCBieSBKdWxpYW4gU2V3YXJkIGV0IGFs Lgo9PTY2Njc9PSBVc2luZyBWYWxncmluZC0zLjUuMCBhbmQgTGliVkVYOyByZXJ1biB3aXRoIC1o IGZvciBjb3B5cmlnaHQgaW5mbwo9PTY2Njc9PSBDb21tYW5kOiAvdmFyL2xkYXAvc2VydmVyL2xp YmV4ZWMvc2xhcGQgLWQwIC1oIGxkYXA6Ly8qOjM4OSAtZiAvdmFyL2xkYXAvc2VydmVyL2V0Yy9v cGVubGRhcC9zbGFwZC5jb25mIC11IGxkYXAgLWcgbGRhcAo9PTY2Njc9PSBQYXJlbnQgUElEOiA0 NTAyCj09NjY2Nz09IAo9PTY2Njc9PSBXYXJuaW5nOiBzZXQgYWRkcmVzcyByYW5nZSBwZXJtczog bGFyZ2UgcmFuZ2UgWzB4MzkwMWQwMDAsIDB4NzkwMWQwMDApIChkZWZpbmVkKQo9PTY2Njc9PSBX YXJuaW5nOiBzZXQgYWRkcmVzcyByYW5nZSBwZXJtczogbGFyZ2UgcmFuZ2UgWzB4YzljNDA0MCwg MHgyNDczYzQ0OCkgKGRlZmluZWQpCj09NjY2Nz09IENvbmRpdGlvbmFsIGp1bXAgb3IgbW92ZSBk ZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT02NjY3PT0gICAgYXQgMHg0RjE4MTMy OiBfX2RidF91c2VyY29weSAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5z bykKPT02NjY3PT0gICAgYnkgMHg0RUQxN0JGOiBfX2xvY2tfZ2V0X3BwIChpbiAvdmFyL2xkYXAv YmVya2VsZXlkYi9saWIvbGliZGItNC44LnNvKQo9PTY2Njc9PSAgICBieSAweDRDRDhCNTogYmRi X2RuMmlkX2xvY2sgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0g ICAgYnkgMHg0Q0REQzM6IGJkYl9kbjJpZCAoaW4gL3Zhci9sZGFwL3NlcnZlci9saWJleGVjL3Ns YXBkKQo9PTY2Njc9PSAgICBieSAweDRDOTg3RjogYmRiX2NhY2hlX2ZpbmRfbmRuIChpbiAvdmFy L2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NENENkI4OiBiZGJf ZG4yZW50cnkgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAg YnkgMHg0RDE2MEQ6IGJkYl9lbnRyeV9nZXQgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9z bGFwZCkKPT02NjY3PT0gICAgYnkgMHg0OTc0NDk6IG92ZXJsYXlfZW50cnlfZ2V0X292IChpbiAv dmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NTJCNjVFOiBz eW5jcHJvdl9kYl9vcGVuIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2 Nz09ICAgIGJ5IDB4NDk3MUM2OiBvdmVyX2RiX29wZW4gKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGli ZXhlYy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHg0NDM5OTg6IGJhY2tlbmRfc3RhcnR1cF9vbmUg KGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHg0NDND NTI6IGJhY2tlbmRfc3RhcnR1cCAoaW4gL3Zhci9sZGFwL3NlcnZlci9saWJleGVjL3NsYXBkKQo9 PTY2Njc9PSAKPT02NjY3PT0gVGhyZWFkIDU6Cj09NjY2Nz09IENvbmRpdGlvbmFsIGp1bXAgb3Ig bW92ZSBkZXBlbmRzIG9uIHVuaW5pdGlhbGlzZWQgdmFsdWUocykKPT02NjY3PT0gICAgYXQgMHg0 RjM2NUYxOiBfX2xvZ19wdXRyIChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9saWIvbGliZGItNC44 LnNvKQo9PTY2Njc9PSAgICBieSAweDRGMzdGMEY6IF9fbG9nX3B1dCAoaW4gL3Zhci9sZGFwL2Jl cmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5zbykKPT02NjY3PT0gICAgYnkgMHg0RUU5QkNGOiBfX2Ri X2FkZHJlbV9sb2cgKGluIC92YXIvbGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09 NjY2Nz09ICAgIGJ5IDB4NEVGODNBQjogX19kYl9waXRlbSAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5 ZGIvbGliL2xpYmRiLTQuOC5zbykKPT02NjY3PT0gICAgYnkgMHg0RTUzRDk0OiBfX2JhbV9paXRl bSAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5zbykKPT02NjY3PT0gICAg YnkgMHg0RTREMDcyOiBfX2JhbWNfcHV0IChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9saWIvbGli ZGItNC44LnNvKQo9PTY2Njc9PSAgICBieSAweDRFRjBDQjk6IF9fZGJjX2lwdXQgKGluIC92YXIv bGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEVGMjY1 RDogX19kYmNfcHV0IChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9saWIvbGliZGItNC44LnNvKQo9 PTY2Njc9PSAgICBieSAweDRFRkQ3REY6IF9fZGJjX3B1dF9wcCAoaW4gL3Zhci9sZGFwL2Jlcmtl bGV5ZGIvbGliL2xpYmRiLTQuOC5zbykKPT02NjY3PT0gICAgYnkgMHg0RDM5OTI6IGJkYl9pZGxf aW5zZXJ0X2tleSAoaW4gL3Zhci9sZGFwL3NlcnZlci9saWJleGVjL3NsYXBkKQo9PTY2Njc9PSAg ICBieSAweDRENTZEMDogYmRiX2tleV9jaGFuZ2UgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhl Yy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHg0RDRBRDM6IGluZGV4ZXIgKGluIC92YXIvbGRhcC9z ZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gCj09NjY2Nz09IFN5c2NhbGwgcGFyYW0gcHdy aXRlNjQoYnVmKSBwb2ludHMgdG8gdW5pbml0aWFsaXNlZCBieXRlKHMpCj09NjY2Nz09ICAgIGF0 IDB4MzM5MzYwRTRDODogPz8/IChpbiAvbGliNjQvbGlicHRocmVhZC0yLjUuc28pCj09NjY2Nz09 ICAgIGJ5IDB4NEY0QzBGRjogX19vc19pbyAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xp YmRiLTQuOC5zbykKPT02NjY3PT0gICAgYnkgMHg0RjM2MkRBOiBfX2xvZ193cml0ZSAoaW4gL3Zh ci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5zbykKPT02NjY3PT0gICAgYnkgMHg0RjM2 RTJBOiBfX2xvZ19mbHVzaF9pbnQgKGluIC92YXIvbGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00 Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEYzODMzMDogX19sb2dfcHV0IChpbiAvdmFyL2xkYXAv YmVya2VsZXlkYi9saWIvbGliZGItNC44LnNvKQo9PTY2Njc9PSAgICBieSAweDRGNTlGNzA6IF9f dHhuX3JlZ29wX2xvZyAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5zbykK PT02NjY3PT0gICAgYnkgMHg0RjU2MzdGOiBfX3R4bl9jb21taXQgKGluIC92YXIvbGRhcC9iZXJr ZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEY1NjdGRTogX190eG5f Y29tbWl0X3BwIChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9saWIvbGliZGItNC44LnNvKQo9PTY2 Njc9PSAgICBieSAweDRDNkZERTogYmRiX2FkZCAoaW4gL3Zhci9sZGFwL3NlcnZlci9saWJleGVj L3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDQ5NzU5MTogb3ZlcmxheV9vcF93YWxrIChpbiAvdmFy L2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NDk3QUU2OiBvdmVy X29wX2Z1bmMgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAg YnkgMHg0OEI1QTg6IHN5bmNyZXBsX2VudHJ5IChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMv c2xhcGQpCj09NjY2Nz09ICBBZGRyZXNzIDB4OWZkYTg4YSBpcyBub3Qgc3RhY2snZCwgbWFsbG9j J2Qgb3IgKHJlY2VudGx5KSBmcmVlJ2QKPT02NjY3PT0gCj09NjY2Nz09IFRocmVhZCA0Ogo9PTY2 Njc9PSBTeXNjYWxsIHBhcmFtIHB3cml0ZTY0KGJ1ZikgcG9pbnRzIHRvIHVuaW5pdGlhbGlzZWQg Ynl0ZShzKQo9PTY2Njc9PSAgICBhdCAweDMzOTM2MEU0Qzg6ID8/PyAoaW4gL2xpYjY0L2xpYnB0 aHJlYWQtMi41LnNvKQo9PTY2Njc9PSAgICBieSAweDRGNEMwRkY6IF9fb3NfaW8gKGluIC92YXIv bGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEYzQUNB OTogX19tZW1wX3Bnd3JpdGUgKGluIC92YXIvbGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljgu c28pCj09NjY2Nz09ICAgIGJ5IDB4NEYzQUU1ODogX19tZW1wX2Jod3JpdGUgKGluIC92YXIvbGRh cC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEY0OEY5QTog X19tZW1wX3N5bmNfaW50IChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9saWIvbGliZGItNC44LnNv KQo9PTY2Njc9PSAgICBieSAweDRGNUE0NTY6IF9fdHhuX2NoZWNrcG9pbnQgKGluIC92YXIvbGRh cC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEY1QTg3ODog X190eG5fY2hlY2twb2ludF9wcCAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQu OC5zbykKPT02NjY3PT0gICAgYnkgMHg0QzY1RkE6IGJkYl9hZGQgKGluIC92YXIvbGRhcC9zZXJ2 ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHg0OTc1OTE6IG92ZXJsYXlfb3Bfd2Fs ayAoaW4gL3Zhci9sZGFwL3NlcnZlci9saWJleGVjL3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDQ5 N0FFNjogb3Zlcl9vcF9mdW5jIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09 NjY2Nz09ICAgIGJ5IDB4NDhCNUE4OiBzeW5jcmVwbF9lbnRyeSAoaW4gL3Zhci9sZGFwL3NlcnZl ci9saWJleGVjL3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDQ5MjgyMzogZG9fc3luY3JlcGwgKGlu IC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gIEFkZHJlc3MgMHgzYmM2 NzMxOCBpcyBub3Qgc3RhY2snZCwgbWFsbG9jJ2Qgb3IgKHJlY2VudGx5KSBmcmVlJ2QKPT02NjY3 PT0gCj09NjY2Nz09IFRocmVhZCA3Ogo9PTY2Njc9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUg ZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09NjY2Nz09ICAgIGF0IDB4NEYzNjVG MTogX19sb2dfcHV0ciAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5zbykK PT02NjY3PT0gICAgYnkgMHg0RjM3RjBGOiBfX2xvZ19wdXQgKGluIC92YXIvbGRhcC9iZXJrZWxl eWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEU3NUI3NjogX19iYW1fc3Bs aXRfbG9nIChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9saWIvbGliZGItNC44LnNvKQo9PTY2Njc9 PSAgICBieSAweDRFNjI1QzU6IF9fYmFtX3NwbGl0IChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9s aWIvbGliZGItNC44LnNvKQo9PTY2Njc9PSAgICBieSAweDRFNEQxNEM6IF9fYmFtY19wdXQgKGlu IC92YXIvbGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4 NEVGMENCOTogX19kYmNfaXB1dCAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQu OC5zbykKPT02NjY3PT0gICAgYnkgMHg0RUYyNjVEOiBfX2RiY19wdXQgKGluIC92YXIvbGRhcC9i ZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEVFNEMyQzogX19k Yl9wdXQgKGluIC92YXIvbGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09 ICAgIGJ5IDB4NEVGRTgxQzogX19kYl9wdXRfcHAgKGluIC92YXIvbGRhcC9iZXJrZWxleWRiL2xp Yi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEQyMDUxOiBiZGJfaWQyZW50cnlfcHV0 IChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NEM2 RDREOiBiZGJfYWRkIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09 ICAgIGJ5IDB4NDk3NTkxOiBvdmVybGF5X29wX3dhbGsgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGli ZXhlYy9zbGFwZCkKPT02NjY3PT0gCj09NjY2Nz09IFRocmVhZCA0Ogo9PTY2Njc9PSBJbnZhbGlk IHdyaXRlIG9mIHNpemUgOAo9PTY2Njc9PSAgICBhdCAweDUyNkY5MDogc3luY3Byb3Zfb3Bfc2Vh cmNoIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4 NDk3NTE5OiBvdmVybGF5X29wX3dhbGsgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFw ZCkKPT02NjY3PT0gICAgYnkgMHg0OTdBRTY6IG92ZXJfb3BfZnVuYyAoaW4gL3Zhci9sZGFwL3Nl cnZlci9saWJleGVjL3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDQzNzc4NTogZmVfb3Bfc2VhcmNo IChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NDM3 RjE2OiBkb19zZWFyY2ggKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3 PT0gICAgYnkgMHg0MzU1RjQ6IGNvbm5lY3Rpb25fb3BlcmF0aW9uIChpbiAvdmFyL2xkYXAvc2Vy dmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NDM1QkNFOiBjb25uZWN0aW9uX3Jl YWRfdGhyZWFkIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAg IGJ5IDB4NTQzNDhCOiBsZGFwX2ludF90aHJlYWRfcG9vbF93cmFwcGVyIChpbiAvdmFyL2xkYXAv c2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4MzM5MzYwNjczQzogc3RhcnRf dGhyZWFkIChpbiAvbGliNjQvbGlicHRocmVhZC0yLjUuc28pCj09NjY2Nz09ICAgIGJ5IDB4MzM5 MkVEM0QxQzogY2xvbmUgKGluIC9saWI2NC9saWJjLTIuNS5zbykKPT02NjY3PT0gIEFkZHJlc3Mg MHg3YWVkYmRhMCBpcyBub3Qgc3RhY2snZCwgbWFsbG9jJ2Qgb3IgKHJlY2VudGx5KSBmcmVlJ2QK PT02NjY3PT0gCj09NjY2Nz09IEludmFsaWQgd3JpdGUgb2Ygc2l6ZSA4Cj09NjY2Nz09ICAgIGF0 IDB4NTI2RjlCOiBzeW5jcHJvdl9vcF9zZWFyY2ggKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhl Yy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHg0OTc1MTk6IG92ZXJsYXlfb3Bfd2FsayAoaW4gL3Zh ci9sZGFwL3NlcnZlci9saWJleGVjL3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDQ5N0FFNjogb3Zl cl9vcF9mdW5jIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAg IGJ5IDB4NDM3Nzg1OiBmZV9vcF9zZWFyY2ggKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9z bGFwZCkKPT02NjY3PT0gICAgYnkgMHg0MzdGMTY6IGRvX3NlYXJjaCAoaW4gL3Zhci9sZGFwL3Nl cnZlci9saWJleGVjL3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDQzNTVGNDogY29ubmVjdGlvbl9v cGVyYXRpb24gKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAg YnkgMHg0MzVCQ0U6IGNvbm5lY3Rpb25fcmVhZF90aHJlYWQgKGluIC92YXIvbGRhcC9zZXJ2ZXIv bGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHg1NDM0OEI6IGxkYXBfaW50X3RocmVhZF9w b29sX3dyYXBwZXIgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0g ICAgYnkgMHgzMzkzNjA2NzNDOiBzdGFydF90aHJlYWQgKGluIC9saWI2NC9saWJwdGhyZWFkLTIu NS5zbykKPT02NjY3PT0gICAgYnkgMHgzMzkyRUQzRDFDOiBjbG9uZSAoaW4gL2xpYjY0L2xpYmMt Mi41LnNvKQo9PTY2Njc9PSAgQWRkcmVzcyAweDdhZWRiZGE4IGlzIG5vdCBzdGFjaydkLCBtYWxs b2MnZCBvciAocmVjZW50bHkpIGZyZWUnZAo9PTY2Njc9PSAKPT02NjY3PT0gSW52YWxpZCByZWFk IG9mIHNpemUgNAo9PTY2Njc9PSAgICBhdCAweDUyNzA1NDogc3luY3Byb3Zfb3Bfc2VhcmNoIChp biAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NDk3NTE5 OiBvdmVybGF5X29wX3dhbGsgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02 NjY3PT0gICAgYnkgMHg0OTdBRTY6IG92ZXJfb3BfZnVuYyAoaW4gL3Zhci9sZGFwL3NlcnZlci9s aWJleGVjL3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDQzNzc4NTogZmVfb3Bfc2VhcmNoIChpbiAv dmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NDM3RjE2OiBk b19zZWFyY2ggKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAg YnkgMHg0MzU1RjQ6IGNvbm5lY3Rpb25fb3BlcmF0aW9uIChpbiAvdmFyL2xkYXAvc2VydmVyL2xp YmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4NDM1QkNFOiBjb25uZWN0aW9uX3JlYWRfdGhy ZWFkIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4 NTQzNDhCOiBsZGFwX2ludF90aHJlYWRfcG9vbF93cmFwcGVyIChpbiAvdmFyL2xkYXAvc2VydmVy L2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4MzM5MzYwNjczQzogc3RhcnRfdGhyZWFk IChpbiAvbGliNjQvbGlicHRocmVhZC0yLjUuc28pCj09NjY2Nz09ICAgIGJ5IDB4MzM5MkVEM0Qx QzogY2xvbmUgKGluIC9saWI2NC9saWJjLTIuNS5zbykKPT02NjY3PT0gIEFkZHJlc3MgMHg3YWVk YmRiMCBpcyBub3Qgc3RhY2snZCwgbWFsbG9jJ2Qgb3IgKHJlY2VudGx5KSBmcmVlJ2QKPT02NjY3 PT0gCj09NjY2Nz09IFRocmVhZCA3Ogo9PTY2Njc9PSBDb25kaXRpb25hbCBqdW1wIG9yIG1vdmUg ZGVwZW5kcyBvbiB1bmluaXRpYWxpc2VkIHZhbHVlKHMpCj09NjY2Nz09ICAgIGF0IDB4NEYzNjVG MTogX19sb2dfcHV0ciAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5zbykK PT02NjY3PT0gICAgYnkgMHg0RjM3RjBGOiBfX2xvZ19wdXQgKGluIC92YXIvbGRhcC9iZXJrZWxl eWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEVFOUJDRjogX19kYl9hZGRy ZW1fbG9nIChpbiAvdmFyL2xkYXAvYmVya2VsZXlkYi9saWIvbGliZGItNC44LnNvKQo9PTY2Njc9 PSAgICBieSAweDRFRjgwQjU6IF9fZGJfZGl0ZW0gKGluIC92YXIvbGRhcC9iZXJrZWxleWRiL2xp Yi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEU1M0FBNTogX19iYW1faWl0ZW0gKGlu IC92YXIvbGRhcC9iZXJrZWxleWRiL2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4 NEU0RDA3MjogX19iYW1jX3B1dCAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQu OC5zbykKPT02NjY3PT0gICAgYnkgMHg0RUYwQ0I5OiBfX2RiY19pcHV0IChpbiAvdmFyL2xkYXAv YmVya2VsZXlkYi9saWIvbGliZGItNC44LnNvKQo9PTY2Njc9PSAgICBieSAweDRFRjI2NUQ6IF9f ZGJjX3B1dCAoaW4gL3Zhci9sZGFwL2JlcmtlbGV5ZGIvbGliL2xpYmRiLTQuOC5zbykKPT02NjY3 PT0gICAgYnkgMHg0RUZEN0RGOiBfX2RiY19wdXRfcHAgKGluIC92YXIvbGRhcC9iZXJrZWxleWRi L2xpYi9saWJkYi00Ljguc28pCj09NjY2Nz09ICAgIGJ5IDB4NEQzOTkyOiBiZGJfaWRsX2luc2Vy dF9rZXkgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAgYnkg MHg0RDU2RDA6IGJkYl9rZXlfY2hhbmdlIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xh cGQpCj09NjY2Nz09ICAgIGJ5IDB4NEQ0QkZBOiBpbmRleGVyIChpbiAvdmFyL2xkYXAvc2VydmVy L2xpYmV4ZWMvc2xhcGQpCj09NjY2Nz09IAoKdmFsZ3JpbmQ6IG1fbWFsbG9jZnJlZS5jOjI0OCAo Z2V0X2JzekJfYXNfaXMpOiBBc3NlcnRpb24gJ2JzekJfbG8gPT0gYnN6Ql9oaScgZmFpbGVkLgp2 YWxncmluZDogSGVhcCBibG9jayBsby9oaSBzaXplIG1pc21hdGNoOiBsbyA9IDE1LCBoaSA9IDQx Nzk5MTQzOTE1NTIwLgpUaGlzIGlzIHByb2JhYmx5IGNhdXNlZCBieSB5b3VyIHByb2dyYW0gZXJy b25lb3VzbHkgd3JpdGluZyBwYXN0IHRoZQplbmQgb2YgYSBoZWFwIGJsb2NrIGFuZCBjb3JydXB0 aW5nIGhlYXAgbWV0YWRhdGEuICBJZiB5b3UgZml4IGFueQppbnZhbGlkIHdyaXRlcyByZXBvcnRl ZCBieSBNZW1jaGVjaywgdGhpcyBhc3NlcnRpb24gZmFpbHVyZSB3aWxsCnByb2JhYmx5IGdvIGF3 YXkuICBQbGVhc2UgdHJ5IHRoYXQgYmVmb3JlIHJlcG9ydGluZyB0aGlzIGFzIGEgYnVnLgoKPT02 NjY3PT0gICAgYXQgMHgzODAyOUQ1QzogcmVwb3J0X2FuZF9xdWl0IChtX2xpYmNhc3NlcnQuYzox NDUpCj09NjY2Nz09ICAgIGJ5IDB4MzgwMkEwMzI6IHZnUGxhaW5fYXNzZXJ0X2ZhaWwgKG1fbGli Y2Fzc2VydC5jOjIxNykKPT02NjY3PT0gICAgYnkgMHgzODAzNDdCOTogdmdQbGFpbl9hcmVuYV9m cmVlIChtX21hbGxvY2ZyZWUuYzoyNDYpCj09NjY2Nz09ICAgIGJ5IDB4MzgwMDFDQkU6IGRpZV9h bmRfZnJlZV9tZW0gKG1jX21hbGxvY193cmFwcGVycy5jOjEyMykKPT02NjY3PT0gICAgYnkgMHgz ODAwMjg3QTogdmdNZW1DaGVja19yZWFsbG9jIChtY19tYWxsb2Nfd3JhcHBlcnMuYzo0MTApCj09 NjY2Nz09ICAgIGJ5IDB4MzgwNjA3QTI6IGRvX2NsaWVudF9yZXF1ZXN0IChzY2hlZHVsZXIuYzox MzcwKQo9PTY2Njc9PSAgICBieSAweDM4MDYxRDMwOiB2Z1BsYWluX3NjaGVkdWxlciAoc2NoZWR1 bGVyLmM6MTA2MSkKPT02NjY3PT0gICAgYnkgMHgzODA4NUU2RTogcnVuX2FfdGhyZWFkX05PUkVU VVJOIChzeXN3cmFwLWxpbnV4LmM6OTEpCj09NjY2Nz09ICAgIGJ5IDB4MzgwODYwOUE6IHZnTW9k dWxlTG9jYWxfc3RhcnRfdGhyZWFkX05PUkVUVVJOIChzeXN3cmFwLWxpbnV4LmM6MjE0KQo9PTY2 Njc9PSAgICBieSAweDM4MDhDNjlEOiA/Pz8gKGluIC91c3IvbGliNjQvdmFsZ3JpbmQvbWVtY2hl Y2stYW1kNjQtbGludXgpCj09NjY2Nz09ICAgIGJ5IDB4REVBREJFRUZERUFEQkVFRTogPz8/Cj09 NjY2Nz09ICAgIGJ5IDB4REVBREJFRUZERUFEQkVFRTogPz8/Cj09NjY2Nz09ICAgIGJ5IDB4REVB REJFRUZERUFEQkVFRTogPz8/CgpzY2hlZCBzdGF0dXM6CiAgcnVubmluZ190aWQ9NgoKVGhyZWFk IDE6IHN0YXR1cyA9IFZnVHNfV2FpdFN5cwo9PTY2Njc9PSAgICBhdCAweDMzOTM2MDdCMzU6IHB0 aHJlYWRfam9pbiAoaW4gL2xpYjY0L2xpYnB0aHJlYWQtMi41LnNvKQo9PTY2Njc9PSAgICBieSAw eDQzMDQzMTogc2xhcGRfZGFlbW9uIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQp Cj09NjY2Nz09ICAgIGJ5IDB4NDFFMjBBOiBtYWluIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4 ZWMvc2xhcGQpCgpUaHJlYWQgMjogc3RhdHVzID0gVmdUc19XYWl0U3lzCj09NjY2Nz09ICAgIGF0 IDB4MzM5MkVENDEwODogPz8/IChpbiAvbGliNjQvbGliYy0yLjUuc28pCj09NjY2Nz09ICAgIGJ5 IDB4NDMyN0JEOiBzbGFwZF9kYWVtb25fdGFzayAoaW4gL3Zhci9sZGFwL3NlcnZlci9saWJleGVj L3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDMzOTM2MDY3M0M6IHN0YXJ0X3RocmVhZCAoaW4gL2xp YjY0L2xpYnB0aHJlYWQtMi41LnNvKQo9PTY2Njc9PSAgICBieSAweDMzOTJFRDNEMUM6IGNsb25l IChpbiAvbGliNjQvbGliYy0yLjUuc28pCgpUaHJlYWQgMzogc3RhdHVzID0gVmdUc19XYWl0U3lz Cj09NjY2Nz09ICAgIGF0IDB4MzM5MzYwQUVFOTogcHRocmVhZF9jb25kX3dhaXRAQEdMSUJDXzIu My4yIChpbiAvbGliNjQvbGlicHRocmVhZC0yLjUuc28pCj09NjY2Nz09ICAgIGJ5IDB4NTQzNEU0 OiBsZGFwX2ludF90aHJlYWRfcG9vbF93cmFwcGVyIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4 ZWMvc2xhcGQpCj09NjY2Nz09ICAgIGJ5IDB4MzM5MzYwNjczQzogc3RhcnRfdGhyZWFkIChpbiAv bGliNjQvbGlicHRocmVhZC0yLjUuc28pCj09NjY2Nz09ICAgIGJ5IDB4MzM5MkVEM0QxQzogY2xv bmUgKGluIC9saWI2NC9saWJjLTIuNS5zbykKClRocmVhZCA0OiBzdGF0dXMgPSBWZ1RzX1dhaXRT eXMKPT02NjY3PT0gICAgYXQgMHgzMzkzNjBBRUU5OiBwdGhyZWFkX2NvbmRfd2FpdEBAR0xJQkNf Mi4zLjIgKGluIC9saWI2NC9saWJwdGhyZWFkLTIuNS5zbykKPT02NjY3PT0gICAgYnkgMHg1NDM0 RTQ6IGxkYXBfaW50X3RocmVhZF9wb29sX3dyYXBwZXIgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGli ZXhlYy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHgzMzkzNjA2NzNDOiBzdGFydF90aHJlYWQgKGlu IC9saWI2NC9saWJwdGhyZWFkLTIuNS5zbykKPT02NjY3PT0gICAgYnkgMHgzMzkyRUQzRDFDOiBj bG9uZSAoaW4gL2xpYjY0L2xpYmMtMi41LnNvKQoKVGhyZWFkIDU6IHN0YXR1cyA9IFZnVHNfV2Fp dFN5cwo9PTY2Njc9PSAgICBhdCAweDMzOTM2MEFFRTk6IHB0aHJlYWRfY29uZF93YWl0QEBHTElC Q18yLjMuMiAoaW4gL2xpYjY0L2xpYnB0aHJlYWQtMi41LnNvKQo9PTY2Njc9PSAgICBieSAweDU0 MzRFNDogbGRhcF9pbnRfdGhyZWFkX3Bvb2xfd3JhcHBlciAoaW4gL3Zhci9sZGFwL3NlcnZlci9s aWJleGVjL3NsYXBkKQo9PTY2Njc9PSAgICBieSAweDMzOTM2MDY3M0M6IHN0YXJ0X3RocmVhZCAo aW4gL2xpYjY0L2xpYnB0aHJlYWQtMi41LnNvKQo9PTY2Njc9PSAgICBieSAweDMzOTJFRDNEMUM6 IGNsb25lIChpbiAvbGliNjQvbGliYy0yLjUuc28pCgpUaHJlYWQgNjogc3RhdHVzID0gVmdUc19S dW5uYWJsZQo9PTY2Njc9PSAgICBhdCAweDRBMDVGMUQ6IHJlYWxsb2MgKHZnX3JlcGxhY2VfbWFs bG9jLmM6NDc2KQo9PTY2Njc9PSAgICBieSAweDMzOTJFNjkxQzM6IF9JT19tZW1fZmluaXNoIChp biAvbGliNjQvbGliYy0yLjUuc28pCj09NjY2Nz09ICAgIGJ5IDB4MzM5MkU2MENCNTogZmNsb3Nl QEBHTElCQ18yLjIuNSAoaW4gL2xpYjY0L2xpYmMtMi41LnNvKQo9PTY2Njc9PSAgICBieSAweDMz OTJFRDAxMzA6IF9fdnN5c2xvZ19jaGsgKGluIC9saWI2NC9saWJjLTIuNS5zbykKPT02NjY3PT0g ICAgYnkgMHgzMzkyRUQwNjZGOiBzeXNsb2cgKGluIC9saWI2NC9saWJjLTIuNS5zbykKPT02NjY3 PT0gICAgYnkgMHg0MzYwNzY6IGNvbm5lY3Rpb25fcmVhZF90aHJlYWQgKGluIC92YXIvbGRhcC9z ZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02NjY3PT0gICAgYnkgMHg1NDM0OEI6IGxkYXBfaW50X3Ro cmVhZF9wb29sX3dyYXBwZXIgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFwZCkKPT02 NjY3PT0gICAgYnkgMHgzMzkzNjA2NzNDOiBzdGFydF90aHJlYWQgKGluIC9saWI2NC9saWJwdGhy ZWFkLTIuNS5zbykKPT02NjY3PT0gICAgYnkgMHgzMzkyRUQzRDFDOiBjbG9uZSAoaW4gL2xpYjY0 L2xpYmMtMi41LnNvKQoKVGhyZWFkIDc6IHN0YXR1cyA9IFZnVHNfV2FpdFN5cwo9PTY2Njc9PSAg ICBhdCAweDMzOTM2MEFFRTk6IHB0aHJlYWRfY29uZF93YWl0QEBHTElCQ18yLjMuMiAoaW4gL2xp YjY0L2xpYnB0aHJlYWQtMi41LnNvKQo9PTY2Njc9PSAgICBieSAweDU0MzRFNDogbGRhcF9pbnRf dGhyZWFkX3Bvb2xfd3JhcHBlciAoaW4gL3Zhci9sZGFwL3NlcnZlci9saWJleGVjL3NsYXBkKQo9 PTY2Njc9PSAgICBieSAweDMzOTM2MDY3M0M6IHN0YXJ0X3RocmVhZCAoaW4gL2xpYjY0L2xpYnB0 aHJlYWQtMi41LnNvKQo9PTY2Njc9PSAgICBieSAweDMzOTJFRDNEMUM6IGNsb25lIChpbiAvbGli NjQvbGliYy0yLjUuc28pCgpUaHJlYWQgODogc3RhdHVzID0gVmdUc19XYWl0U3lzCj09NjY2Nz09 ICAgIGF0IDB4MzM5MzYwQUVFOTogcHRocmVhZF9jb25kX3dhaXRAQEdMSUJDXzIuMy4yIChpbiAv bGliNjQvbGlicHRocmVhZC0yLjUuc28pCj09NjY2Nz09ICAgIGJ5IDB4NTQzNEU0OiBsZGFwX2lu dF90aHJlYWRfcG9vbF93cmFwcGVyIChpbiAvdmFyL2xkYXAvc2VydmVyL2xpYmV4ZWMvc2xhcGQp Cj09NjY2Nz09ICAgIGJ5IDB4MzM5MzYwNjczQzogc3RhcnRfdGhyZWFkIChpbiAvbGliNjQvbGli cHRocmVhZC0yLjUuc28pCj09NjY2Nz09ICAgIGJ5IDB4MzM5MkVEM0QxQzogY2xvbmUgKGluIC9s aWI2NC9saWJjLTIuNS5zbykKClRocmVhZCA5OiBzdGF0dXMgPSBWZ1RzX1dhaXRTeXMKPT02NjY3 PT0gICAgYXQgMHgzMzkzNjBBRUU5OiBwdGhyZWFkX2NvbmRfd2FpdEBAR0xJQkNfMi4zLjIgKGlu IC9saWI2NC9saWJwdGhyZWFkLTIuNS5zbykKPT02NjY3PT0gICAgYnkgMHg1NDM0RTQ6IGxkYXBf aW50X3RocmVhZF9wb29sX3dyYXBwZXIgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9zbGFw ZCkKPT02NjY3PT0gICAgYnkgMHgzMzkzNjA2NzNDOiBzdGFydF90aHJlYWQgKGluIC9saWI2NC9s aWJwdGhyZWFkLTIuNS5zbykKPT02NjY3PT0gICAgYnkgMHgzMzkyRUQzRDFDOiBjbG9uZSAoaW4g L2xpYjY0L2xpYmMtMi41LnNvKQoKVGhyZWFkIDEwOiBzdGF0dXMgPSBWZ1RzX1dhaXRTeXMKPT02 NjY3PT0gICAgYXQgMHgzMzkzNjBBRUU5OiBwdGhyZWFkX2NvbmRfd2FpdEBAR0xJQkNfMi4zLjIg KGluIC9saWI2NC9saWJwdGhyZWFkLTIuNS5zbykKPT02NjY3PT0gICAgYnkgMHg1NDM0RTQ6IGxk YXBfaW50X3RocmVhZF9wb29sX3dyYXBwZXIgKGluIC92YXIvbGRhcC9zZXJ2ZXIvbGliZXhlYy9z bGFwZCkKPT02NjY3PT0gICAgYnkgMHgzMzkzNjA2NzNDOiBzdGFydF90aHJlYWQgKGluIC9saWI2 NC9saWJwdGhyZWFkLTIuNS5zbykKPT02NjY3PT0gICAgYnkgMHgzMzkyRUQzRDFDOiBjbG9uZSAo aW4gL2xpYjY0L2xpYmMtMi41LnNvKQoKCk5vdGU6IHNlZSBhbHNvIHRoZSBGQVEgaW4gdGhlIHNv dXJjZSBkaXN0cmlidXRpb24uCkl0IGNvbnRhaW5zIHdvcmthcm91bmRzIHRvIHNldmVyYWwgY29t bW9uIHByb2JsZW1zLgpJbiBwYXJ0aWN1bGFyLCBpZiBWYWxncmluZCBhYm9ydGVkIG9yIGNyYXNo ZWQgYWZ0ZXIKaWRlbnRpZnlpbmcgcHJvYmxlbXMgaW4geW91ciBwcm9ncmFtLCB0aGVyZSdzIGEg Z29vZCBjaGFuY2UKdGhhdCBmaXhpbmcgdGhvc2UgcHJvYmxlbXMgd2lsbCBwcmV2ZW50IFZhbGdy aW5kIGFib3J0aW5nIG9yCmNyYXNoaW5nLCBlc3BlY2lhbGx5IGlmIGl0IGhhcHBlbmVkIGluIG1f bWFsbG9jZnJlZS5jLgoKSWYgdGhhdCBkb2Vzbid0IGhlbHAsIHBsZWFzZSByZXBvcnQgdGhpcyBi dWcgdG86IHd3dy52YWxncmluZC5vcmcKCkluIHRoZSBidWcgcmVwb3J0LCBzZW5kIGFsbCB0aGUg YWJvdmUgdGV4dCwgdGhlIHZhbGdyaW5kCnZlcnNpb24sIGFuZCB3aGF0IE9TIGFuZCB2ZXJzaW9u IHlvdSBhcmUgdXNpbmcuICBUaGFua3MuCgo= --001636ed6965c05dfc049bfe938f--

1 0

Re: (ITS#6810) testing a fix.
by bruno.haleblian＠gmail.com 10 Feb '11

10 Feb '11

2011/2/9 =A0<masarati(a)aero.polimi.it>: > > That *should* never be NULL, AFAIK. =A0Is the issue reproducible? =A0If i= t is, > could you run the failing machine under valgrind --tool=3Dmemcheck > --leak-check=3Dfull? > > p. Thanks for your reply. As it's my first look in slapd code, I'm just trying to understand what's going wrong. You suspect memory (overwrite or something) corruption I guess. Unfortunately, crash is not easily reproducible. To make brief, crashes happen under "heavy" updates coming from scripts or EAI clients, after one ore more hours of load. For now, both machines are running under memcheck as you suggested. No crash so far, but some warnings at startup. Here's what : # valgrind --tool=3Dmemcheck --leak-check=3Dfull /var/ldap/server/libexec/slapd -d0 -h ldap://*:389 ldaps://*:636 -f /var/ldap/server/etc/openldap/slapd.conf -u ldap -g ldap | tee > /tmp/valgrind.out =3D=3D19951=3D=3D Memcheck, a memory error detector =3D=3D19951=3D=3D Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward = et al. =3D=3D19951=3D=3D Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyri= ght info =3D=3D19951=3D=3D Command: /var/ldap/server/libexec/slapd -d0 -h ldap://*:3= 89 ldaps://*:636 -f /var/ldap/server/etc/openldap/slapd.conf -u ldap -g ldap =3D=3D19951=3D=3D =3D=3D19951=3D=3D Warning: set address range perms: large range [0x3901d000= , 0x7901d000) (defined) =3D=3D19951=3D=3D Warning: set address range perms: large range [0xc9c4040, 0x2473c448) (defined) =3D=3D19951=3D=3D Conditional jump or move depends on uninitialised value(s= ) =3D=3D19951=3D=3D at 0x4F18132: __dbt_usercopy (in /var/ldap/berkeleydb/lib/libdb-4.8.so) =3D=3D19951=3D=3D by 0x4ED17BF: __lock_get_pp (in /var/ldap/berkeleydb/lib/libdb-4.8.so) =3D=3D19951=3D=3D by 0x4CD8B5: bdb_dn2id_lock (in /var/ldap/server/libex= ec/slapd) =3D=3D19951=3D=3D by 0x4CDDC3: bdb_dn2id (in /var/ldap/server/libexec/sl= apd) =3D=3D19951=3D=3D by 0x4C987F: bdb_cache_find_ndn (in /var/ldap/server/l= ibexec/slapd) =3D=3D19951=3D=3D by 0x4CD6B8: bdb_dn2entry (in /var/ldap/server/libexec= /slapd) =3D=3D19951=3D=3D by 0x4D160D: bdb_entry_get (in /var/ldap/server/libexe= c/slapd) =3D=3D19951=3D=3D by 0x497449: overlay_entry_get_ov (in /var/ldap/server/libexec/slapd) =3D=3D19951=3D=3D by 0x52B65E: syncprov_db_open (in /var/ldap/server/lib= exec/slapd) =3D=3D19951=3D=3D by 0x4971C6: over_db_open (in /var/ldap/server/libexec= /slapd) =3D=3D19951=3D=3D by 0x443998: backend_startup_one (in /var/ldap/server/libexec/slapd) =3D=3D19951=3D=3D by 0x443C52: backend_startup (in /var/ldap/server/libe= xec/slapd) =3D=3D19951=3D=3D Regards Bruno.

1 0

Re: (ITS#6753) Compare operation broken with attribute inheritance
by hyc＠symas.com 10 Feb '11

10 Feb '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (193.157.200.213) > Submitted by: hallvard > > > back-bdb, back-monitor: If attr A is ACL-protected and inherits from B, > one can still check its value with ldapcompare ... 'B:value'. > > back-config: Compare doesn't seem to support attribute inheritance. > > root DSE, cn=subschema: Inheritance works correctly. All Compare processing has been centralized in the frontend so all backends implement it uniformly now. -- -- 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

ITS#6017
by masarati＠aero.polimi.it 10 Feb '11

10 Feb '11

I notice that the contrib contrib/slapd-modules/samba4/pguid.c related to this ITS defines a "parentUUID" attribute 1.3.6.1.4.1.4203.666.1.59 NAME 'parentUUID' DESC 'the value of the entryUUID of the parent' EQUALITY UUIDMatch ORDERING UUIDOrderingMatch SYNTAX 1.3.6.1.1.16.1 USAGE dSAOperation SINGLE-VALUE NO-USER-MODIFICATION which is very similar to the "superiorUUID" attribute 1.3.6.1.4.1.4203.666.1.11 NAME 'superiorUUID' DESC 'UUID of the superior entry' EQUALITY UUIDMatch ORDERING UUIDOrderingMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation defined in servers/slapd/schema_prep.c; although this contrib is not currently used in samba4, I suggest "parentUUID" be defined as an alias of "superiorUUID", or vice-versa, so that "parentUUID" becomes the preferred form. p.

1 0

Re: (ITS#6827) SSL Unbind Hangs
by michael＠stroeder.com 10 Feb '11

10 Feb '11

masarati(a)aero.polimi.it wrote: >> Also a simple SSL bind and unbind without any modifications to the AD >> yields the >> same hanging problem. > > So far I don't see OpenLDAP specific issues here (assuming python-ldap is > linked to OpenLDAP's client library). Another user of the Debian package of python-ldap reported such a behaviour on the python-ldap-dev mailing list. The problem was solved by re-compiling OpenLDAP libs and python-ldap and link against OpenSSL instead of GnuTLS. (Sigh!) Ciao, Michael.

1 0

Re: (ITS#6827) SSL Unbind Hangs
by hyc＠symas.com 09 Feb '11

09 Feb '11

jason.colonno(a)blackskycomputing.com wrote: > Full_Name: Jason Colonno > Version: 2.4.23-0ubuntu3.4 > OS: Ubuntu 10.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.1.229.99) > > > When binding with a AD server using SSL, ldap functions work properly however > when the unbind function is called it hangs indefinitely. The point of the > function is to reset a user's passwords. > > AD Server is Windows Server 2008 R2. Ldp.exe testing of connecting with the > server does not have this problem since it does not use python-ldap. > > Sample Code: > bind_str = "ldaps://" + domain_controller + ":636/" > l = ldap.initialize(bind_str) > l.set_option( ldap.OPT_X_TLS_DEMAND, True ) > l.set_option( ldap.OPT_DEBUG_LEVEL, 255 ) > bind_str = "cn=" + binding_username + ",cn=Users,dc=" + domain_dc + > ",dc=" + domain_ext > l.simple_bind_s(bind_str, binding_password) > new_gen_passwd = generate_temp_pw() > unicode1 = unicode("\"" + new_gen_passwd + "\"", "iso-8859-1") > unicode2 = unicode1.encode("utf-16-le") > new_password = unicode2 > mod_attrs = [(ldap.MOD_REPLACE, 'unicodePwd', new_password)] > l.modify_s(username, mod_attrs) > l.unbind_s() > > Also a simple SSL bind and unbind without any modifications to the AD yields the > same hanging problem. > Sounds like a dup of ITS#6673, already fixed in HEAD/RE24. -- -- 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#6827) SSL Unbind Hangs
by masarati＠aero.polimi.it 09 Feb '11

09 Feb '11

> Full_Name: Jason Colonno > Version: 2.4.23-0ubuntu3.4 > OS: Ubuntu 10.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.1.229.99) > > > When binding with a AD server using SSL, ldap functions work properly > however > when the unbind function is called it hangs indefinitely. The point of the > function is to reset a user's passwords. > > AD Server is Windows Server 2008 R2. Ldp.exe testing of connecting with > the > server does not have this problem since it does not use python-ldap. > > Sample Code: > bind_str = "ldaps://" + domain_controller + ":636/" > l = ldap.initialize(bind_str) > l.set_option( ldap.OPT_X_TLS_DEMAND, True ) > l.set_option( ldap.OPT_DEBUG_LEVEL, 255 ) > bind_str = "cn=" + binding_username + ",cn=Users,dc=" + > domain_dc + > ",dc=" + domain_ext > l.simple_bind_s(bind_str, binding_password) > new_gen_passwd = generate_temp_pw() > unicode1 = unicode("\"" + new_gen_passwd + "\"", "iso-8859-1") > unicode2 = unicode1.encode("utf-16-le") > new_password = unicode2 > mod_attrs = [(ldap.MOD_REPLACE, 'unicodePwd', new_password)] > l.modify_s(username, mod_attrs) > l.unbind_s() > > Also a simple SSL bind and unbind without any modifications to the AD > yields the > same hanging problem. So far I don't see OpenLDAP specific issues here (assuming python-ldap is linked to OpenLDAP's client library). You can try the same operation using ldapmodify(1) and see if you can reproduce the problem using client tools. If you can't, the problem is likely unrelated to OpenLDAP. Otherwise, you should check whether it's python-ldap or AD specific. Unless you can narrow down the problem to libldap or OpenLDAP specific code, the issue does not belong to us. p.

1 0

Re: (ITS#6810) testing a fix.
by masarati＠aero.polimi.it 09 Feb '11

09 Feb '11

> Hi, all > just testing with that fix for now... > > --- openldap-2.4.23.orig/servers/slapd/overlays/syncprov.c > 2010-06-10 20:50:48.000000000 +0200 > +++ openldap-2.4.23.p1/servers/slapd/overlays/syncprov.c > 2011-02-08 19:33:10.000000000 +0100 > @@ -1292,7 +1292,8 @@ > } > } > > - if ( fc.fscope ) { > + /* (ITS#6810) make sure ors_filter != NULL here */ > + if ( fc.fscope && ss->s_op->ors_filter ) { > op2 = *ss->s_op; > oh = *op->o_hdr; > oh.oh_conn = ss->s_op->o_conn; That *should* never be NULL, AFAIK. Is the issue reproducible? If it is, could you run the failing machine under valgrind --tool=memcheck --leak-check=full? p.

1 0

(ITS#6827) SSL Unbind Hangs
by jason.colonno＠blackskycomputing.com 09 Feb '11

09 Feb '11

Full_Name: Jason Colonno Version: 2.4.23-0ubuntu3.4 OS: Ubuntu 10.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.1.229.99) When binding with a AD server using SSL, ldap functions work properly however when the unbind function is called it hangs indefinitely. The point of the function is to reset a user's passwords. AD Server is Windows Server 2008 R2. Ldp.exe testing of connecting with the server does not have this problem since it does not use python-ldap. Sample Code: bind_str = "ldaps://" + domain_controller + ":636/" l = ldap.initialize(bind_str) l.set_option( ldap.OPT_X_TLS_DEMAND, True ) l.set_option( ldap.OPT_DEBUG_LEVEL, 255 ) bind_str = "cn=" + binding_username + ",cn=Users,dc=" + domain_dc + ",dc=" + domain_ext l.simple_bind_s(bind_str, binding_password) new_gen_passwd = generate_temp_pw() unicode1 = unicode("\"" + new_gen_passwd + "\"", "iso-8859-1") unicode2 = unicode1.encode("utf-16-le") new_password = unicode2 mod_attrs = [(ldap.MOD_REPLACE, 'unicodePwd', new_password)] l.modify_s(username, mod_attrs) l.unbind_s() Also a simple SSL bind and unbind without any modifications to the AD yields the same hanging problem.

1 0

(ITS#6810) testing a fix.
by bruno.haleblian＠gmail.com 08 Feb '11

08 Feb '11

Hi, all just testing with that fix for now... --- openldap-2.4.23.orig/servers/slapd/overlays/syncprov.c 2010-06-10 20:50:48.000000000 +0200 +++ openldap-2.4.23.p1/servers/slapd/overlays/syncprov.c 2011-02-08 19:33:10.000000000 +0100 @@ -1292,7 +1292,8 @@ } } - if ( fc.fscope ) { + /* (ITS#6810) make sure ors_filter != NULL here */ + if ( fc.fscope && ss->s_op->ors_filter ) { op2 = *ss->s_op; oh = *op->o_hdr; oh.oh_conn = ss->s_op->o_conn; Regards, Bruno.

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by h.b.furuseth＠usit.uio.no 08 Feb '11

08 Feb '11

I see. Thanks. That saves some copyright head-scratching. -- Hallvard

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 07 Feb '11

07 Feb '11

Le 05/02/2011 00:37, hyc(a)symas.com a écrit : > michael(a)stroeder.com wrote: >> Could we have this overlay in contrib/ shipped with 2.4.24? >> That would be really nice. >> >> I've tested it with 2.4.23 and it still seems to work. > > Committed with changes in HEAD. Howard, Thanks for taking the time to clean this up and commit it. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

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

07 Feb '11

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Could we have this overlay in contrib/ shipped with 2.4.24? >>> That would be really nice. >>> >>> I've tested it with 2.4.23 and it still seems to work. >> >> Committed with changes in HEAD. > > Also in RE24. Thanks a lot! > > Any objections adding a slightly more complete Makefile (see attachment)? Yes, several objections. Post diffs that can be applied by the "patch" command, not the complete file. If you're going to add more rules, make them conform to the standard Makefiles. E.g. the correct macro is "prefix" not "PREFIX". Post diffs that actually work, your "OPT" macro is never referenced anywhere else in the Makefile so it's useless. The default prefix is always /usr/local. You can use whatever prefix you like in your personal copy, but stick with the defaults on anything you submit to us. > Ciao, Michael. > > > Makefile.lastbind > > > # Copyright 2009 Jonathan Clarke<jonathan(a)phillipoux.net>. > # All rights reserved. > # > # Redistribution and use in source and binary forms, with or without > # modification, are permitted only as authorized by the OpenLDAP > # Public License. > # > # A copy of this license is available in the file LICENSE in the > # top-level directory of the distribution or, alternatively, at > #<http://www.OpenLDAP.org/license.html>. > > PREFIX=/opt/openldap-RE24 > > CPPFLAGS+=-I../../../include -I../../../servers/slapd > CPPFLAGS+=-DSLAPD_OVER_LASTBIND=SLAPD_MOD_DYNAMIC > #LIBTOOL=libtool > LIBTOOL=../../../libtool > OPT=-g -O2 > CC=gcc > > > all: lastbind.la > > lastbind.lo: lastbind.c > $(LIBTOOL) --mode=compile $(CC) $(CPPFLAGS) -Wall -c $? > > lastbind.la: lastbind.lo > $(LIBTOOL) --mode=link $(CC) -version-info 0:0:0 \ > -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 -- -- 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#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 07 Feb '11

07 Feb '11

For the record. slapd-mtread.c started as a copy of slapd-read.c from the same source directory, and then minor modifications were incorporated into slapd-mtread.c to allow the code to perform specific MT operations. This was done to preserve the integrity of the existing test suite and all the existing test cases that already use slapd-read.c. Technically the original author is also the original author of slapd-read.c Doug Leavitt Oracle Corporation

1 0

Re: (ITS#6826) Apache htpasswd MD5 support [patch]
by hyc＠symas.com 07 Feb '11

07 Feb '11

djpohly(a)gmail.com wrote: > Alright, I have created a file contrib/slapd-modules/passwd/apr1.c which > implements this hash: > > http://openldap.pastebin.com/r2GzfveB > > I have tested it and confirmed that it works on several passwords > converted from an htpasswd file using the atol.pl script above. Thanks, added to HEAD with additional changes. -- -- 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#6826) Apache htpasswd MD5 support [patch]
by djpohly＠gmail.com 06 Feb '11

06 Feb '11

Alright, I have created a file contrib/slapd-modules/passwd/apr1.c which implements this hash: http://openldap.pastebin.com/r2GzfveB I have tested it and confirmed that it works on several passwords converted from an htpasswd file using the atol.pl script above.

1 0

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

05 Feb '11

This is a multi-part message in MIME format. --------------010407040507050306070700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Could we have this overlay in contrib/ shipped with 2.4.24? >> That would be really nice. >> >> I've tested it with 2.4.23 and it still seems to work. > > Committed with changes in HEAD. Also in RE24. Thanks a lot! Any objections adding a slightly more complete Makefile (see attachment)? Ciao, Michael. --------------010407040507050306070700 Content-Type: text/plain; name="Makefile.lastbind" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Makefile.lastbind" # Copyright 2009 Jonathan Clarke <jonathan(a)phillipoux.net>. # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted only as authorized by the OpenLDAP # Public License. # # A copy of this license is available in the file LICENSE in the # top-level directory of the distribution or, alternatively, at # <http://www.OpenLDAP.org/license.html>. PREFIX=/opt/openldap-RE24 CPPFLAGS+=-I../../../include -I../../../servers/slapd CPPFLAGS+=-DSLAPD_OVER_LASTBIND=SLAPD_MOD_DYNAMIC #LIBTOOL=libtool LIBTOOL=../../../libtool OPT=-g -O2 CC=gcc all: lastbind.la lastbind.lo: lastbind.c $(LIBTOOL) --mode=compile $(CC) $(CPPFLAGS) -Wall -c $? lastbind.la: lastbind.lo $(LIBTOOL) --mode=link $(CC) -version-info 0:0:0 \ -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 --------------010407040507050306070700--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs