- openldap-bugs - openldap.org

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by h.b.furuseth＠usit.uio.no 21 Aug '08

21 Aug '08

hyc(a)symas.com writes: > It would be smarter to just standardize OID macros for each of these > OIDs, the way X.500 did, and not require the humans reading these > specs to memorize these numeric OIDs... Yup. slapd/schema/syntaxes.schema? Syntax names like olsDirectoryString or just DirectoryString? (I don't know if OID macro names are a separate namespace or not.) > I don't see any straightforward way to modify our parser as you're > suggesting. Unless someone else feels like jumping in, I think we > should reject this ITS. back-config could accept attributeTypes:: base64("description with line endings and comments") if it doesn't already. Personally I wouldn't write such a file anytime soon, but someone who schema via some LDAP-friendly tool might. -- Hallvard

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> It might be helpful if the schema config file parser would accept lines with >> comments at the end separated by semicolon. > > The parser doesn't know anything about line endings. Remember, lines with > leading white space are continuations of the previous line. The schema parser > is just fed a single string as one long line, the line endings were removed > long before it ever got there. Maybe lines with ; could be truncated before passing it to the schema parser? I don't know if that has any impact on processing slapd.conf in general. The slapd.conf parser has to already know in advance that this part is a schema declaration (started by key-word objectclass etc.) and could change pre-processing? Ciao, Michael.

1 0

(ITS#5664) Deadlocks when writing in parallell (two processes)
by tom.bjorkholm＠aastra.com 21 Aug '08

21 Aug '08

Full_Name: Stelios Grigoriadis & Tom Björkholm Version: 2.3.39 OS: Novell SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) We get a lot of DB_LOCK_DEADLOCK when using client programs that for a period of time continuously writes to OpenLDAP. Version is 2.3.39. The information added is of the form: ebcmdCustomer=0+ebcmdDir=220xx,ou=AuthCodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com where xx varies. Snippet of the output: Mar 27 13:03:21 ldapt1 slapd[7589]: => bdb_dn2id_add: subtree (ebcmdCustomer=0+ebcmdDir=22037,ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) put failed: -30995 Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) Mar 27 13:03:26 ldapt1 slapd[7589]: => bdb_dn2id_add: parent (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert failed: -30995 Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) Mar 27 13:03:28 ldapt1 slapd[7589]: => bdb_dn2id_add: parent (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert failed: -30995 Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995) Mar 27 13:03:36 ldapt1 slapd[7589]: => bdb_dn2id_add: parent (ou=authcodes,ebcmdVersion=0,ebcmdProduct=ebcmd,dc=example,dc=com) insert failed: -30995 Mar 27 13:03:38 ldapt1 slapd[7589]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30995)

1 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon
by hyc＠symas.com 21 Aug '08

21 Aug '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.84.234) > > > It might be helpful if the schema config file parser would accept lines with > comments at the end separated by semicolon. The parser doesn't know anything about line endings. Remember, lines with leading white space are continuations of the previous line. The schema parser is just fed a single string as one long line, the line endings were removed long before it ever got there. > Example (derived from http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ > using mainly OIDs): > > attributetype ( 2.16.840.1.101.2.2.1.69 NAME 'transferStation' > EQUALITY 2.5.13.13 ; booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ; BOOLEAN > SINGLE-VALUE ) It would be smarter to just standardize OID macros for each of these OIDs, the way X.500 did, and not require the humans reading these specs to memorize these numeric OIDs... I don't see any straightforward way to modify our parser as you're suggesting. Unless someone else feels like jumping in, I think we should reject this ITS. -- -- 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#5663) Declaring substitute syntax as LDAP syntax
by michael＠stroeder.com 21 Aug '08

21 Aug '08

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.84.234) Sometimes one wants to add a custom schema which also defines LDAP syntaxes which are not supported yet but could be substituted by another LDAP syntax already implemented. Instead of changing SYNTAX of all attribute type declarations in the custom schema it might be handy if declaring a substitute LDAP syntax would be possible while still providing the original syntax declaration to the client which might know better what to do with it. Example for emulating custom LDAP syntax with PrintableString: ldapsyntax ( 1.3.6.1.4.1.5427.666.42.42.42 X-SUBST 1.3.6.1.4.1.1466.115.121.1.44 ) This should fail with parsing error if one trys to add a substitute syntax for a syntax already implemented.

1 0

(ITS#5662) Comments in schema declarations separated by semicolon
by michael＠stroeder.com 21 Aug '08

21 Aug '08

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.84.234) It might be helpful if the schema config file parser would accept lines with comments at the end separated by semicolon. Example (derived from http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ using mainly OIDs): attributetype ( 2.16.840.1.101.2.2.1.69 NAME 'transferStation' EQUALITY 2.5.13.13 ; booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ; BOOLEAN SINGLE-VALUE )

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther＠sendmail.com 20 Aug '08

20 Aug '08

I have an updated patch, but can't post it: ftp.openldap.org's incoming is full: ftp> cd incoming 250 CWD command successful. ftp> put guenther-080820.patch local: guenther-080820.patch remote: guenther-080820.patch 150 Opening BINARY mode data connection for 'guenther-080820.patch'. 100% |**************************************************| 9215 00:00 452 Error writing file: No space left on device. 9215 bytes sent in 0.13 seconds (66.79 KB/s) ftp> (Once we get a patch that looks good, I'll follow it with a patch for the docs.)

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 19 Aug '08

19 Aug '08

Philip Guenther wrote: > On Tue, 19 Aug 2008, Howard Chu wrote: >> guenther(a)sendmail.com wrote: > ... >>> TLS_PROTOCOL_MIN<major>,<minor> >> Let's use US convention<major>.<minor>... > > Ok. > >>> C: >>> struct ldap_tls_protocol { unsigned char major, minor; } val; >>> val.major = 3; val.minor=0; >>> ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN,&val); >> I would just use an int, and have the caller OR in the appropriate >> values. > > So: > /* force TLS 1.0 or later */ > ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN, (3<< 8) + 1); The set_option interface requires a pointer. So min = (3<<8)+1; ldap_set_option(ld, LDAP_OPT_X_TLS_PROTOCOL_MIN, &min); > > >> You could also define a few macros for the currently known versions. > > Preferences on the format of those macros? > > #define LDAP_OPT_X_TLS_PROTOCOL_SSLv2 (2<< 8) > #define LDAP_OPT_X_TLS_PROTOCOL_SSLv3 (3<< 8) > #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 ((3<< 8) + 1) > #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_1 ((3<< 8) + 2) > #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_2 ((3<< 8) + 3) > > ? > Drop the 'v' and I think it'll be fine -- -- 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#5655) add option for setting minimum TLS/SSL protocol
by guenther＠sendmail.com 19 Aug '08

19 Aug '08

On Tue, 19 Aug 2008, Howard Chu wrote: > guenther(a)sendmail.com wrote: ... > > TLS_PROTOCOL_MIN<major>,<minor> > > Let's use US convention <major>.<minor>... Ok. > > C: > > struct ldap_tls_protocol { unsigned char major, minor; } val; > > val.major = 3; val.minor=0; > > ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN,&val); > > I would just use an int, and have the caller OR in the appropriate > values. So: /* force TLS 1.0 or later */ ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN, (3 << 8) + 1); > You could also define a few macros for the currently known versions. Preferences on the format of those macros? #define LDAP_OPT_X_TLS_PROTOCOL_SSLv2 (2 << 8) #define LDAP_OPT_X_TLS_PROTOCOL_SSLv3 (3 << 8) #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 ((3 << 8) + 1) #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_1 ((3 << 8) + 2) #define LDAP_OPT_X_TLS_PROTOCOL_TLSv1_2 ((3 << 8) + 3) ? > What are the values for TLS1.1, 1.2, etc? So far, TLS 1.x == SSL version 3.(x+1). Philip Guenther

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 19 Aug '08

19 Aug '08

guenther(a)sendmail.com wrote: > On Fri, 15 Aug 2008, Philip Guenther wrote: > ... >> That said, it's more important to me that *some* option gets in so that I >> (and Sendmail) don't have to maintain forever a patch to add it. If >> someone 'official' will make a decision and simply state what the option >> should look like in its three forms (C API, ldap.conf, slapd config), I'll >> munge the patch to match. > > Any opinions? > > ldap.conf: > TLS_PROTOCOL_MIN<major>,<minor> Let's use US convention <major>.<minor>... > C: > struct ldap_tls_protocol { unsigned char major, minor; } val; > val.major = 3; val.minor=0; > ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN,&val); I would just use an int, and have the caller OR in the appropriate values. You could also define a few macros for the currently known versions. What are the values for TLS1.1, 1.2, etc? > > ? > > > (I'm running out of time to get _something_ into Sendmail's local copy, at > which point I'll just commit something there and have to leave you guys to > hack whatever you get around into the official repository.) > > > Philip Guenther > > > -- -- 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#5655) add option for setting minimum TLS/SSL protocol
by guenther＠sendmail.com 19 Aug '08

19 Aug '08

On Fri, 15 Aug 2008, Philip Guenther wrote: ... > That said, it's more important to me that *some* option gets in so that I > (and Sendmail) don't have to maintain forever a patch to add it. If > someone 'official' will make a decision and simply state what the option > should look like in its three forms (C API, ldap.conf, slapd config), I'll > munge the patch to match. Any opinions? ldap.conf: TLS_PROTOCOL_MIN <major>,<minor> C: struct ldap_tls_protocol { unsigned char major, minor; } val; val.major = 3; val.minor=0; ldap_set_option(ld, LDAP_OPT_TLS_PROTOCOL_MIN, &val); ? (I'm running out of time to get _something_ into Sendmail's local copy, at which point I'll just commit something there and have to leave you guys to hack whatever you get around into the official repository.) Philip Guenther

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ghenry＠OpenLDAP.org 19 Aug '08

19 Aug '08

----- "ali pouya" <ali.pouya(a)free.fr> wrote: > Hi Gavin; > > Below you find the answers to your questions : > > > Can we get your bdb version, your config and the logs of an empty > mirrormode > > node B pulling in the data loaded in mirrormode A (posted/hosted > online > > somewhere). > > The BDB version is 4.6.21. > You find here attached the file conf.tar.gz containing the > configuration of B. Thanks. > The file syncrepl.conf.simple works well, but the file > syncrepl.conf.double > garbles the contextCSN (I write more than 1000 entries per minute). > Do you want a log for the 10 million entries ? Which loglevel ? Nope, not yet. loglevel sync > The problem only happens if there are write operations on A, not if > the server A > is stationary. Also note that serverID is a *global* directive not per database. Move that out of "database bdb". > > Also, has this always happened on the same machine? What are the > specs of the > > servers? > > The problem happens on the stand by server : If I write on B the > contextCSN of > A gets corrupted (I have already tested this). > > My servers are quadri-processor Xeon 2.2 GHz. > I think this is not related to the hardware but the "year" part of > contextCSN is > not well protected against concurrent operations (?). > > > > > Is this a fresh install? > Yes for 2.4.11, but I use OpenLdap since 5 years for my different > projects. OK, well you should then know that "rootdn cn=admin,ou=ressources-dgi,ou=mefi,o=gouv,c=fr" by passes all ACLs, so you don't need: access to * by dn.base="cn=admin,ou=ressources-dgi,ou=mefi,o=gouv,c=fr" write -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Fwd: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ghenry＠OpenLDAP.org 19 Aug '08

19 Aug '08

------=_Part_5_5686568.1219150476998 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit For Ticket records. Please keep to openldap-its ----- Forwarded Message ----- From: "ali pouya" <ali.pouya(a)free.fr> To: ghenry(a)OpenLDAP.org Sent: Tuesday, 19 August, 2008 1:48:53 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror Hi Gavin; Below you find the answers to your questions : > Can we get your bdb version, your config and the logs of an empty mirrormode > node B pulling in the data loaded in mirrormode A (posted/hosted online > somewhere). The BDB version is 4.6.21. You find here attached the file conf.tar.gz containing the configuration of B. The file syncrepl.conf.simple works well, but the file syncrepl.conf.double garbles the contextCSN (I write more than 1000 entries per minute). Do you want a log for the 10 million entries ? Which loglevel ? The problem only happens if there are write operations on A, not if the server A is stationary. > > Also, has this always happened on the same machine? What are the specs of the > servers? The problem happens on the stand by server : If I write on B the contextCSN of A gets corrupted (I have already tested this). My servers are quadri-processor Xeon 2.2 GHz. I think this is not related to the hardware but the "year" part of contextCSN is not well protected against concurrent operations (?). > > Is this a fresh install? Yes for 2.4.11, but I use OpenLdap since 5 years for my different projects. Best Regards Ali > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/ ------=_Part_5_5686568.1219150476998 Content-Type: application/x-gzip; name=conf.tar.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=conf.tar.gz H4sIAJrAqkgAA+2Z3VMbNxDAeT39FRp4SELJfWI7YeYeaNym6aTUKSXN9E0+ybbSO+miD4Lb6f/e vTsbjI1rHLAZEv2YwWd97Z6kXa3WfrCzcUKg02rVn8D8Z/0cRWErbh1CwwTKO52wvYNbm1dtZ8dq QxTGO0pK83/tVtU/UvxAj0WmWJn7mRQDX/OizNn9yqgWuH14uHT9D8PW9fWPkk6Y7ODwftW4mW98 /ffQdP2x4jQNwxjhUslzTplKc0rKoyCIQj9qtf3EjzrJUfLiJcJmXLJUsYFienQsaI8pzbVBWDGj xuluFOPvdhHWjKhs1CeapbtZOlBQNOC5gYF3n8r+R5aZVznROt1/VjXOJIypbb96HLGCwL/sLy6G qRwMEO5zQQtmRpKmzRZtiqiAoUVavcOBtKCS1tKqjOnndMirkoIN4DMdSnt+MNEB3pYyYTjJdd0R oYdehAcE7D8nJa2Nf1MyVth/EiVT+0/gmIjB/qN2J3b2vw327gbawwv0lPzIjMZECEu4YpgynBPc ff1moSn0v7P8H3k24kxVUqpNzIdWEcOlqMU+uVTi15KJt93jHi7BQczIn21DmcYlUYZnNoch9eK7 bUD/95XzBHWPcOh3VkpckI+7xFSaKwEaM1xIygc8a2YAw6DRyyBsB3EYvljS/9gaZtWSEY7wcc5x T9ox2cz7c5HlljLPC6xWQS4zkgfMZAEcBqI6foLmMAgyqZjfPK/RR3Oxdi/oYqQalrAsUqzbuSxl zrPxut3gsMpkUdj15V3t1mlXtJfLYc7OWe49jxAqOYVD9/pI50QFyoqJ64cWiKihrpstbVW1QKv1 Ihkcvro+ThCixJDq+MdeIQWHWb0q8vq0jzRT50y96Xox0nYw4BeeNwkUKm9LhefB2U5owcXtDve6 W/nZw94/p6c/Hf8bvbMn3T+S8tO7bu9lYn7Jxh9k+1X+5/c/x+97rQ+vEQWrz0CvsRdA0EMtNzoA xYJKy9XvCvEHu5i8ah2tlJIL40XNsYbbIdq7oTgKbzGNOS9Al8nYqzfDbAiPCq6UVGDGMO9SICRh jnMyxlWrKrRD04fnV9rhWr1Kt8tKDdMNLgA2U1N5VSNkCWsBIZT3+29nP1yVK5ZLQkd8WvEtx1WP hfn7H5W2v+X7XwR/c/Ff0m63XPy3DRbuf9F93P/Cx3X/W+sK3HJXYMdXw5z/34iM2+f/Kv8fgf+P D2N3/98KLv/3bTs/f/aqsSEZK+2/fThv/2Encva/DZrVx5gKn12QzKxrTtjwgqVW1OMwijX/e+Yr QpPxvWvjw14TYP3Mqk1KATd2Ma6GI2WZTxJauvo+m+L7EnEPvWb3iT+TxdiUjFX3v6QdLeb/3f1v K9w9f73AlvP/V7yFGKRJ4td7GlvDc67hKyVC45zhjNBGndn893We4vzJ8dLfA55tQP/Z/H/7xiz/ ch5//h/VS+XNhIMHEJup8avTk+bh7OxN1/M89gntNU2pINkpUxC+ndiiz5TX1DaVllPPu1aSiWnB QRVcflXO+x7wZzP2G5Kxyv/HnXjO/8dhEjr/vw1Qs/zYSEyMUTq1mqkemOFnqSiqbLw/Bk8uxbiQ Fny6NaNpKQRbk7vdehGjYoTeNMZlvLayCxhyuvtFgd0y2etHpJ8VxILTofYxzBBDM5O5f5OUNX7K mhNwj7o+9mWbzvVDW47D4XA4HA6Hw+FwOBwOh8PhcDgcDofD4XA4HA6Hw+FwOBwPx39608HTAFAA AA== ------=_Part_5_5686568.1219150476998--

1 0

Trans.: Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ali.pouya＠free.fr 19 Aug '08

19 Aug '08

----- Message transféré de ali.pouya(a)free.fr ----- Date : Tue, 19 Aug 2008 14:48:53 +0200 De : ali.pouya(a)free.fr Adresse de retour :ali.pouya@free.fr Sujet : Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror À : ghenry(a)OpenLDAP.org Hi Gavin; Below you find the answers to your questions : > Can we get your bdb version, your config and the logs of an empty mirrormode > node B pulling in the data loaded in mirrormode A (posted/hosted online > somewhere). The BDB version is 4.6.21. You find here attached the file conf.tar.gz containing the configuration of B. The file syncrepl.conf.simple works well, but the file syncrepl.conf.double garbles the contextCSN (I write more than 1000 entries per minute). Do you want a log for the 10 million entries ? Which loglevel ? The problem only happens if there are write operations on A, not if the server A is stationary. > > Also, has this always happened on the same machine? What are the specs of the > servers? The problem happens on the stand by server : If I write on B the contextCSN of A gets corrupted (I have already tested this). My servers are quadri-processor Xeon 2.2 GHz. I think this is not related to the hardware but the "year" part of contextCSN is not well protected against concurrent operations (?). > > Is this a fresh install? Yes for 2.4.11, but I use OpenLdap since 5 years for my different projects. Best Regards Ali > ----- Fin du message transféré -----

1 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror
by ghenry＠OpenLDAP.org 19 Aug '08

19 Aug '08

> I think there is a documentation issue for OpenLdap 2.4.11 : > The chapter 17.4.4 of the Admin Guide recommends configuring TWO > sycrepl > directives for each mirror side. If I do so, the contextCSN of the > stand by > mirror gets corrupted very easily. But if I confugure the mirrors > with only ONE > syncrepl directive it's OK. The documentation is correct. > The test environment : > I have a test directory with two mirrors A (sid=1) and B (sid=2) > configured as > recommended in the Admin's Guide, and a replica C connected to A. > The directory contains 10 million objects, and I use the server A for > writing > 500 000 new ones. > > Very often and without any apparent reason the contextCSN in the > memory of B > gets suddenly corrupted while those of A and C are OK. > In this situation the contextCSN of B gets stuck but B continues to > receive data > from A. > > The value of contextCSN in base 64 is : > > contextCSN: 20080727021429.070493Z#000000#000#000000 > contextCSN:: +HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA== perl -MMIME::Base64 -e 'print decode_base64("+HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA=="), "\n";' does look very funny :-( Can we get your bdb version, your config and the logs of an empty mirrormode node B pulling in the data loaded in mirrormode A (posted/hosted online somewhere). Also, has this always happened on the same machine? What are the specs of the servers? Is this a fresh install? -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#5661) contextCSN gets corrupted on the stand by mirror
by ali.pouya＠free.fr 19 Aug '08

19 Aug '08

Full_Name: Ali Pouya Version: 2.4.11 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) I think there is a documentation issue for OpenLdap 2.4.11 : The chapter 17.4.4 of the Admin Guide recommends configuring TWO sycrepl directives for each mirror side. If I do so, the contextCSN of the stand by mirror gets corrupted very easily. But if I confugure the mirrors with only ONE syncrepl directive it's OK. The test environment : I have a test directory with two mirrors A (sid=1) and B (sid=2) configured as recommended in the Admin's Guide, and a replica C connected to A. The directory contains 10 million objects, and I use the server A for writing 500 000 new ones. Very often and without any apparent reason the contextCSN in the memory of B gets suddenly corrupted while those of A and C are OK. In this situation the contextCSN of B gets stuck but B continues to receive data from A. The value of contextCSN in base 64 is : contextCSN: 20080727021429.070493Z#000000#000#000000 contextCSN:: +HYDCTA4MDIwMzM3MTguMzAwMTExWiMwMDAwMDAjMDAxIzAwMDAwMA== I note that only the part indicating the year (2008) is garbled. May be this part is handled differently ? At service shutdown B writes the corrupt contextCSN to the disk. At service startup B reads the corrupt contextCSN from the disk and begins to scan ALL of the data base. Also it sends a sync request to A (a persitent search containing the corrupt contextCSN in the control field) causing A to scan the WHOLE data base. The replica C remains safe. If I reverse the roles of A and B the corruption occurs on A (always on the stand by mirror). I have already encountered the contextCSN corruption problem in OpenLdap 2.3 and this was one of my reasons to migrate to 2.4.11. Thanks for your HELP Best Regards Ali Pouya

1 0

(ITS#5660) SHA-2 hash support
by jeff＠atlassian.com 18 Aug '08

18 Aug '08

Full_Name: Jeff Turner Version: 2.3.30 OS: Linux URL: http://confluence.atlassian.com/download/attachments/162431971/openldap-sha… Submission from: (NULL) (203.63.130.33) OpenLDAP currently supports MD5, CRYPT and SHA1 hash formats. I needed support for SHA-512, so I have created a module to support SHA512, and the other SHA-2 formats (SHA256 and SHA384). I'd be happy for it to be included in OpenLDAP's contrib/slapd-modules/passwd/ directory. Code suitable for inclusion is linked in the ticket URL, and there is a fuller description of its use in the included README, or at http://confluence.atlassian.com/display/JIRAEXT/OpenLDAP+support+for+SHA-2+… As for the code, it is a thin module wrapper on an unmodified version of the BSD-licenced sha2.{c,h} by Aaron Gifford: http://www.aarongifford.com/computers/sha.html This also appears to be the SHA2 implementation used by OpenBSD. Please let me know if you have any questions.

1 0

(ITS#5659) patch for collect overlay
by brett.maxfield＠gmail.com 17 Aug '08

17 Aug '08

Full_Name: Brett Maxfield Version: HEAD OS: Linux suse 2.6.22.18-0.2-xen #1 SMP 2008-06-09 13:53:20 +0200 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/brett-maxfield-080817.tgz Submission from: (NULL) (220.245.180.135) Fixes bug with overlay system where it would inherit/collect attributes to the entry that was supplying those attributes, causing duplicate attributes in that node. Also add a alternate config format for easy entry, eg old format: overlay collect collectinfo <dn> <attribute> and now in addition to above also supports : overlay collect collectinfo <dn> <attribute1>,<attribute2>,<attributeN>

1 0

Re: (ITS#5658) slapo-perl symbol updates
by rra＠stanford.edu 15 Aug '08

15 Aug '08

rra(a)stanford.edu writes: > It's a general change to the libperl API and may not only affect HPPA. > You're apparently now required to call those macros, and in the future > they may have more effects. Here is a patch, untested alas because I don't have time at the moment to set up something with back-perl. It compiles. I'm not fully sure that the handling of embedded and argc is correct. Perl 5.10 (and some earlier versions) require calling some additional macros around Perl interpreter setup and shutdown. Not doing these calls causes problems on HPPA at least, and may affect other platforms in the future. This patch adds the additional code modelled on the perlembed man page and a working patch for INN. Debian Bug#495069 ITS #5658 --- openldap.orig/servers/slapd/back-perl/close.c +++ openldap/servers/slapd/back-perl/close.c @@ -30,6 +30,9 @@ { perl_destruct(PERL_INTERPRETER); perl_free(PERL_INTERPRETER); +#ifdef PERL_SYS_TERM + PERL_SYS_TERM(); +#endif PERL_INTERPRETER = NULL; ldap_pvt_thread_mutex_destroy( &perl_interpreter_mutex ); --- openldap.orig/servers/slapd/back-perl/init.c +++ openldap/servers/slapd/back-perl/init.c @@ -37,6 +37,7 @@ ) { char *embedding[] = { "", "-e", "0" }; + int argc = 3; bi->bi_open = NULL; bi->bi_config = 0; @@ -77,9 +78,15 @@ ldap_pvt_thread_mutex_init( &perl_interpreter_mutex ); +#ifdef PERL_SYS_INIT3 + PERL_SYS_INIT3(&argc, &embedding, (char **)NULL); +#endif PERL_INTERPRETER = perl_alloc(); perl_construct(PERL_INTERPRETER); - perl_parse(PERL_INTERPRETER, perl_back_xs_init, 3, embedding, (char **)NULL); +#ifdef PERL_EXIT_DESTRUCT_END + PL_exit_flags |= PERL_EXIT_DESTRUCT_END; +#endif + perl_parse(PERL_INTERPRETER, perl_back_xs_init, argc, embedding, (char **)NULL); perl_run(PERL_INTERPRETER); return 0; } -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5658) slapo-perl symbol updates
by rra＠stanford.edu 15 Aug '08

15 Aug '08

quanah(a)OpenLDAP.org writes: > Full_Name: Quanah Gibson-Mount > Version: 2.4.11 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.109.79.65) > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495069 > > Not sure how much we care about hppa architecture. It's a general change to the libperl API and may not only affect HPPA. You're apparently now required to call those macros, and in the future they may have more effects. What we did for INN was add: #ifdef PERL_SYS_INIT3 PERL_SYS_INIT3(&argc, &argv, &env); #endif before perl_alloc, #ifdef PERL_EXIT_DESTRUCT_END PL_exit_flags |= PERL_EXIT_DESTRUCT_END; #endif after perl_construct, and: #ifdef PERL_SYS_TERM PERL_SYS_TERM(); #endif after perl_free. See man perlembed; with Perl 5.10, its example now reads: int main(int argc, char **argv, char **env) { PERL_SYS_INIT3(&argc,&argv,&env); my_perl = perl_alloc(); perl_construct(my_perl); PL_exit_flags |= PERL_EXIT_DESTRUCT_END; perl_parse(my_perl, NULL, argc, argv, (char **)NULL); perl_run(my_perl); perl_destruct(my_perl); perl_free(my_perl); PERL_SYS_TERM(); } Notice that we don't use the "env" pointer. Normally handed to "perl_parse" as its final argument, "env" here is replaced by "NULL", which means that the current environment will be used. The macros PERL_SYS_INIT3() and PERL_SYS_TERM() provide system-specific tune up of the C runtime environment necessary to run Perl interpreters; since PERL_SYS_INIT3() may change "env", it may be more appropriate to provide "env" as an argument to perl_parse(). -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

(ITS#5658) slapo-perl symbol updates
by quanah＠OpenLDAP.org 15 Aug '08

15 Aug '08

Full_Name: Quanah Gibson-Mount Version: 2.4.11 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.109.79.65) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495069 Not sure how much we care about hppa architecture. As described in the 'perlembed' document, programs embedding Perl must use the PERL_SYS_INIT3() and PERL_SYS_TERM() macros to provide system-specific tune up of the C runtime environment necessary to run Perl interpreters. Your package has been identified as failing this: - at least one of the binary packages built from the source depends on libperl5.10 - the unpacked source matches 'perl_parse' but not 'PERL_SYS_INIT3' As a consequence, the embedded Perl interpreter is most probably broken on the hppa architecture, where PERL_SYS_INIT3() is needed for initializing lock structures. Without this, calling perl_parse() will hang inside pthread_mutex_lock(). See #486069 for more information.

1 0

(ITS#5657) Broken symlinks in /etc/ssl/certs prevent ssl connection
by Martin.vGagern＠gmx.net 15 Aug '08

15 Aug '08

Full_Name: Martin von Gagern Version: 2.3.43 OS: Gentoo Linux URL: https://bugs.gentoo.org/show_bug.cgi?id=234816 Submission from: (NULL) (84.188.31.84) On systems with broken symlinks in the default certificate directory of openssl, I found it impossible to establish an ldaps connection with openldap. I originally reported this issue as https://bugs.gentoo.org/show_bug.cgi?id=234816 I first encountered this when I got informed by luma that I could not connect to a server. I then reproduced this on the command line: $ ldapsearch -H ldaps://ldap.domain.tld ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ ldapsearch -d 15 -H ldaps://ldap.domain.tld ... ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS: could not load client CA list (file:`',dir:`/etc/ssl/certs/'). TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line pem_lib.c:647 ... previous line repeated 13 times ... TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:356 TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:358 ldap_perror ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Sadly it does not say what file can't be opened. The "no start line" errors seem to be non-fatal. The fopen error in bss_file.c from dev-libs/openssl on the other hand seems to cause the connection to fail. Root of the cause seemed to be several broken symlinks in /etc/ssl/certs. Steps to solve the issue by removing those links: # find /etc/ssl/certs -type l ! -xtype f ! -xtype d -ok rm -f {} \; Steps to reproduce the issue, provided you have an SSL-Enabled LDAP server: # ln -s bar.pem /etc/ssl/certs/foo.pem $ ldapsearch -d 15 -H ldaps://ldap.domain.tld Ideally openldap should trat these errors as non-fatal, the way s_client does, so that such a broken symlink won't prevent all connections. If that path towards solution proves infeasible (as the openssl function SSL_add_dir_cert_subjects_to_stack seems to behave this way and adding all files manually might be a pain), at least there should be some error message telling the user that the problem lies in the local SSL certificates setup, not really in the network connection or remote configuration. By the way, I'm using openssl version 0.9.8h.

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 14 Aug '08

14 Aug '08

On Thu, 14 Aug 2008, Michael Ströder wrote: > Philip Guenther wrote: ... > > They also have the "SSLProtocol" directive, further down on that page. > > Then I'd vote for doing it exactly like this with one option (space- or > comma-separated list of protocols). As I mentioned in the ITS, I think treating the various protocol versions as independently choosable is a Bad Thing, as it permits broken settings with no corresponding gain. That said, it's more important to me that *some* option gets in so that I (and Sendmail) don't have to maintain forever a patch to add it. If someone 'official' will make a decision and simply state what the option should look like in its three forms (C API, ldap.conf, slapd config), I'll munge the patch to match. Philip Guenther

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ghenry＠OpenLDAP.org 14 Aug '08

14 Aug '08

----- "ali pouya" <ali.pouya(a)free.fr> wrote: > Gavin Henry <ghenry(a)suretecsystems.com> wrote : > > > ali.pouya(a)free.fr wrote: > > > Why do you change serverID? > In a configuration with two mirrors I have to set two different IDs. > The problem > is that the replica defaults to serverID=0, whilst I understood that > the replica > does not need a serverID. > > So you're saying serverID=0, serverID=1, serverID=2 makes a > difference > > from serverID=1, serverID=2, serverID=3? > > > > They only have to be unique. > > > > Yes. Let me put the problem another way : > > In 2.4.11 each time you start slapd (master as well as replica) it > scans (reads) > all of the objects being more recent than its contextCSN value having > ITS OWN > serverID. Wouldn't it be bettre that it scans only the objects more > recent thant > the moste recent value of the contextCSN ? > If y have millions of such entries the scanning taks too long. > Is this a bug or a normal feature ? This is intended: servers/slapd/overlays/syncprov.c in HEAD 615 | case FIND_MAXCSN: 616 | | cf.f_choice = LDAP_FILTER_GE; 617 | | /* If there are multiple CSNs, use the one with our serverID */ 618 | | for ( i=0; i<si->si_numcsns; i++) { 619 | | | if ( slap_serverID == si->si_sids[i] ) { 620 | | | | maxid = i; 621 | | | | break; 622 | | | } 623 | | } 624 | | if ( i == si->si_numcsns ) { 625 | | | /* No match: this is multimaster, and none of the content in the DB 626 | | | * originated locally. Treat like no CSN. 627 | | | */ 628 | | | return LDAP_NO_SUCH_OBJECT; 629 | | } > > > There are no writes above, you've only shown searches. > > Yes there are no writes because this is an extract of the startup > log. > > > How many times do you restart slapd and why? > > In production I restart slapd once a day for backup. But the problem > is that if > I restart it for any reason I have to wait to much for the service to > be > available. A cold backup of the bdb dir I take it. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5656) Bind operations with translucent overlay
by mateusz.kijowski＠gmail.com 14 Aug '08

14 Aug '08

Full_Name: Mateusz Kijowski Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.126.222.22) In some use scenarios, it is useful if the translucent overlay does not forward bind operation requests to the remote server when there are values for userPassword attribute in the local database. It would be nice if this could be enabled or disabled by a configuration option. For consistency, enabling this behavior should also affect the PASSMOD extended operation to modify the local value of userPassword.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs