openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 06 Jul '09

06 Jul '09

--001636c5b1542f27b3046e045d1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > > Although with a slapd without debug symbols it works ok, there's an assert > that fails in slapd_clr_write method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): > > (gdb) bt > #0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 > #1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 > #2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 > #3 0x000000000043e447 in slapd_clr_write (s=<value optimized out>, wake=0) > at daemon.c:939 > #4 0x00000000004422dc in connection_write (s=403) at connection.c:1855 > #5 0x00000000004410e6 in slapd_daemon_task (ptr=<value optimized out>) at > daemon.c:2567 > #6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 > #7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 > #8 0x0000000000000000 in ?? () > > Hello, The problem still reproduces, all connection hangups after a weekend overloading the server.. Regards --001636c5b1542f27b3046e045d1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"borde= r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-le= ft: 1ex;"><div class=3D"gmail_quote"><div><br>Although with a slapd without= debug symbols it works ok, there's an assert that fails in slapd_clr_w= rite method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"):<br> <br><font size=3D"3">(gdb) bt <br>#0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 <br>#1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 <br>#2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 <br>#3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out&= gt;, wake=3D0) at daemon.c:939 <br>#4 0x00000000004422dc in connection_write (s=3D403) at connection.c:18= 55 <br>#5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized = out>) at daemon.c:2567 <br>#6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 <br>#7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 <br>#8 0x0000000000000000 in ?? ()</font><br><br></div></div></blockquote>= <div><br>Hello,<br> <br> The problem still reproduces, all connection hangups after a weekend overlo= ading the server..<br> <br> Regards<br>=C2=A0</div></div><br> --001636c5b1542f27b3046e045d1b--

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 03 Jul '09

03 Jul '09

h.b.furuseth(a)usit.uio.no wrote: > The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd > and OpenSSL: > > passwd.c:660: error: expected declaration specifiers or '...' before '(' token > passwd.c:660: error: expected declaration specifiers or '...' before '&' token > passwd.c:661: error: conflicting types for 'DES_set_key' > /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' > > Preprocessor output for passwd.c shows that this in passwd.c: > static void > des_set_key( des_key *key, unsigned char *keyData) { ... } > conflicts with this macro from /usr/include/openssl/des_old.h: > #define des_set_key(k,ks) DES_set_key((k),&(ks)) > which when expanded tries to conflict with this prototype from > /usr/include/openssl/des.h: > int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); > Fixed in HEAD. We should probably update from the old (des_*) to new (DES_*) as well. Already did this for the identical code in smbk5pwd.c... -- -- 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#5696) Patch - support Mozilla NSS for crypto operations
by h.b.furuseth＠usit.uio.no 03 Jul '09

03 Jul '09

The latest liblutil/passwd.c breaks with ./configure --enable-lmpasswd and OpenSSL: passwd.c:660: error: expected declaration specifiers or '...' before '(' token passwd.c:660: error: expected declaration specifiers or '...' before '&' token passwd.c:661: error: conflicting types for 'DES_set_key' /usr/include/openssl/des.h:222: error: previous declaration of 'DES_set_key' Preprocessor output for passwd.c shows that this in passwd.c: static void des_set_key( des_key *key, unsigned char *keyData) { ... } conflicts with this macro from /usr/include/openssl/des_old.h: #define des_set_key(k,ks) DES_set_key((k),&(ks)) which when expanded tries to conflict with this prototype from /usr/include/openssl/des.h: int DES_set_key(const_DES_cblock *key,DES_key_schedule *schedule); -- Hallvard

1 0

(ITS#6196) back-config: multiple olcDbIndex Attributes can be added for the same Attributetype
by ralf＠OpenLDAP.org 03 Jul '09

03 Jul '09

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.223.21) Submitted by: ralf With ldapmodify I can add the following LDIF to cn=config: ------------------------------- dn: olcDatabase={1}hdb,cn=config add: olcdbindex olcdbindex: cn pres olcdbindex: cn eq ------------------------------- The server accepts it and seems to work fine after that. Restarting the server however fails after that. Error message is: 'duplicate index definition for attr "cn"' The ldapmodify should have returned that error already IMO. I am currently working on a fix. Should appear soon in HEAD.

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 03 Jul '09

03 Jul '09

--001636c5acf83a095e046dc7f0ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Wed, Jul 1, 2009 at 7:02 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, June 29, 2009 10:15 AM +0200 Jorge Perez Burgos < > jorge.perez(a)adaptia.net> wrote: > > Hello, >> >> I still reproduce this problem with 2.4.17-prerelease. I have a client >> that request a lof of operations at the same time through a connection. >> The slapd seems to overload and finally close the connection sending a >> reset to the client and when this happens the connection hungs eating the >> CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the >> same point of the first trace sent in this report. >> > > This should now really be fixed in HEAD and RE24. Please test. Although with a slapd without debug symbols it works ok, there's an assert that fails in slapd_clr_write method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): (gdb) bt #0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 #1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 #2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000043e447 in slapd_clr_write (s=<value optimized out>, wake=0) at daemon.c:939 #4 0x00000000004422dc in connection_write (s=403) at connection.c:1855 #5 0x00000000004410e6 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2567 #6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 #7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 #8 0x0000000000000000 in ?? () Best Regards --001636c5acf83a095e046dc7f0ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, Jul 1, 2009 at 7:02 PM, Quanah Gibson-Mo= unt <span dir=3D"ltr"><<a href=3D"mailto:quanah@zimbra.com" target=3D"_b= lank">quanah(a)zimbra.com</a>></span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt= 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div>--On Monday, June 29, 2009 10:15 AM +0200 Jorge Perez = Burgos <<a href=3D"mailto:jorge.perez@adaptia.net" target=3D"_blank">jor= ge.perez(a)adaptia.net</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hello,<br> <br> I still reproduce this problem with 2.4.17-prerelease. I have a client<br> that request a lof of operations at the same time through a connection.<br> The slapd seems to overload and finally close the connection sending a<br> reset to the client and when this happens the connection hungs eating the<b= r> CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the<br> same point of the first trace sent in this report.<br> </blockquote> <br></div></div> This should now really be fixed in HEAD and RE24. =C2=A0Please test.</block= quote><div><br>Although with a slapd without debug symbols it works ok, the= re's an assert that fails in slapd_clr_write method, ("assert( SLA= P_SOCK_IS_ACTIVE( s ))"):<br> <br><font size=3D"3">(gdb) bt <br>#0 0x00002ae8cf1c7d45 in raise () from /lib64/libc.so.6 <br>#1 0x00002ae8cf1c9140 in abort () from /lib64/libc.so.6 <br>#2 0x00002ae8cf1c1286 in __assert_fail () from /lib64/libc.so.6 <br>#3 0x000000000043e447 in slapd_clr_write (s=3D<value optimized out&= gt;, wake=3D0) at daemon.c:939 <br>#4 0x00000000004422dc in connection_write (s=3D403) at connection.c:18= 55 <br>#5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<value optimized = out>) at daemon.c:2567 <br>#6 0x00002ae8ce656143 in start_thread () from /lib64/libpthread.so.0 <br>#7 0x00002ae8cf258b8d in clone () from /lib64/libc.so.6 <br>#8 0x0000000000000000 in ?? ()</font><br><br><br>Best Regards<br></div= ></div><br> --001636c5acf83a095e046dc7f0ae--

1 0

Re: (ITS#6195) Replications with 2.3.43 master to 2.4.16 slave is failing
by quanah＠zimbra.com 02 Jul '09

02 Jul '09

--On Thursday, July 02, 2009 3:40 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > So, it appears to me that even though it must have at some point accepted > the first change, the entry on the server is not truly updated to reflect > that for some reason? That, or it "skipped" that change for reasons > unknown to me. Adding to the mystery, is what the server believes the entry looks like, even across restarts: dn: uid=acyen,cn=accounts,dc=stanford,dc=edu suSeasSunetID: acyen suDialinStatus: active suCreateAgent: AccountSlog suService: dialin suService: afs suService: leland suService: email suService: pts suService: seas suService: kerberos suEmailAdmin: acyen suSeasUriRouteTo: /~acyen suName: XXXXXXX uid: acyen suNameLF: XXXXXXXX suSeasStatus: active suKerberosStatus: active suEntryStatus: active suAccountStatus: active krb5PrincipalName: XXXXXXXX suSeasLocal: XXXXXXXXX suEmailAccountType: personal suAfsStatus: active suEmailStatus: active suMailDrop: XXXXXXXXX suCreateAPI: JNDI suKrb4Name: XXXXXXXXXX suPtsStatus: active suLelandStatus: active gecos: XXXXXX cn: XXXXXXX suAfsHomeDirectory: /afs/ir/users/a/c/acyen suPtsUid: 28906 loginShell: /bin/tcsh uidNumber: 28906 gidNumber: 37 homeDirectory: /afs/ir/users/a/c/acyen objectClass: posixAccount objectClass: suPtsService objectClass: suAccount objectClass: suOperational objectClass: suAfsService objectClass: suEmailService objectClass: suLelandService objectClass: suDialinService objectClass: suKerberosService objectClass: suSeasService suIdentifies: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,d c=edu seeAlso: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu owner: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu description: XXXXXXXXXX suEmailQuota: 1000 suDescription: XXXXXXXXXX structuralObjectClass: suAccount entryUUID: bd300052-dbd5-102c-8575-cd5814f999c3 creatorsName: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu createTimestamp: 20080701162309Z modifiersName: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu modifyTimestamp: 20090210171734Z entryCSN: 20090702065034.772554Z#000000#000#000000 entryDN: uid=acyen,cn=accounts,dc=stanford,dc=edu subschemaSubentry: cn=Subschema hasSubordinates: FALSE The first change, which we'd think had gone across given it is stuck on the second change, never appears to have been applied, but nothing was ever logged about this. The attributes and objectClass that were supposed to be deleted are still present. The value changes that were supposed to occur haven't. Now, the entryCSN is: 20090702065034.772554Z#000000#000#000000 vs the change time which is: 20090702070150.000014Z so clearly, the entry has never been updated with the change. Yet it *should* have been. How did we end up skipping a change from the accesslog db???? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6195) Replications with 2.3.43 master to 2.4.16 slave is failing
by quanah＠zimbra.com 02 Jul '09

02 Jul '09

--On Thursday, July 02, 2009 10:15 PM +0000 whm(a)stanford.edu wrote: > It looks like there is an attempt to remove objectclass=posixaccount > without removing gecos at the same time. The slapd -d -1 output of this system is quite interesting. First, here's the changelogs from the master. Note that there are *two* of them. In the first one, "gecos" is deleted: dn: reqStart=20090702070150.000014Z,cn=accesslog objectClass: auditModify reqStart: 20090702070150.000014Z reqEnd: 20090702070150.000016Z reqType: modify reqSession: 12280 reqAuthzID: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu reqDN: uid=acyen,cn=Accounts,dc=Stanford,dc=edu reqResult: 0 reqMod: gecos:- reqMod: cn:- reqMod: description:- reqMod: loginShell:- reqMod: uidNumber:- reqMod: gidNumber:- reqMod: homeDirectory:- reqMod: objectClass:= suPtsService reqMod: objectClass:= suAccount reqMod: objectClass:= suOperational reqMod: objectClass:= suAfsService reqMod: objectClass:= suEmailService reqMod: objectClass:= suLelandService reqMod: objectClass:= suDialinService reqMod: objectClass:= suKerberosService reqMod: objectClass:= suSeasService reqMod: suAfsStatus:= frozen reqMod: suSeasStatus:= frozen reqMod: suEmailStatus:= frozen reqMod: suLelandStatus:= frozen reqMod: suIdentifies:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=S tanford,dc=edu reqMod: seeAlso:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanfo rd,dc=edu reqMod: owner:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford ,dc=edu reqMod: suDialinStatus:= frozen reqMod: suPtsStatus:= frozen reqMod: suDescription:= XXXXXXX reqMod: entryCSN:= 20090702070150Z#000002#00#000000 reqMod: modifiersName:= cn=slog-accounts,cn=service,cn=applications,dc=stanfor d,dc=edu reqMod: modifyTimestamp:= 20090702070150Z So, you can see gecos is clearly deleted here. In fact, it is the very first thing deleted. The second change is where things are failing: dn: reqStart=20090702075511.000006Z,cn=accesslog objectClass: auditModify reqStart: 20090702075511.000006Z reqEnd: 20090702075511.000007Z reqType: modify reqSession: 13583 reqAuthzID: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu reqDN: uid=acyen,cn=Accounts,dc=Stanford,dc=edu reqResult: 0 reqMod: krb5PrincipalName:- reqMod: suKrb4Name:- reqMod: suKerberosStatus:- reqMod: objectClass:= suPtsService reqMod: objectClass:= suAccount reqMod: objectClass:= suOperational reqMod: objectClass:= suAfsService reqMod: objectClass:= suEmailService reqMod: objectClass:= suLelandService reqMod: objectClass:= suDialinService reqMod: objectClass:= suSeasService reqMod: suIdentifies:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=S tanford,dc=edu reqMod: seeAlso:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanfo rd,dc=edu reqMod: owner:= suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford ,dc=edu reqMod: suDescription:= XXXXXXX reqMod: suService:= dialin reqMod: suService:= afs reqMod: suService:= leland reqMod: suService:= email reqMod: suService:= pts reqMod: suService:= seas reqMod: suAccountStatus:= inactive reqMod: entryCSN:= 20090702075511Z#000000#00#000000 reqMod: modifiersName:= cn=slog-accounts,cn=service,cn=applications,dc=stanfor d,dc=edu reqMod: modifyTimestamp:= 20090702075511Z Now, the replica was loaded from an LDIF taken on 2009/07/01, so it should have taken both of these changes just fine: dn: dc=stanford,dc=edu objectClass: dcObject objectClass: organization o: Stanford University dc: stanford l: Palo Alto structuralObjectClass: organization entryUUID: e67c08ca-adc9-102a-8f07-03156481d080 creatorsName: cn=manager,dc=stanford,dc=edu modifiersName: cn=manager,dc=stanford,dc=edu createTimestamp: 20060722123236Z modifyTimestamp: 20060722123236Z contextCSN: 20090701110754Z#000000#00#000000 The slapd -d -1 log shows it is clearly processing the second change and failing there: 0000: 82 04 37 04 2c 72 65 71 53 74 61 72 74 3d 32 30 ..7.,reqStart=20 0010: 30 39 30 37 30 32 30 37 35 35 31 31 2e 30 30 30 090702075511.000 0020: 30 30 36 5a 2c 63 6e 3d 61 63 63 65 73 73 6c 6f 006Z,cn=accesslo 0030: 67 30 82 04 05 30 13 04 07 72 65 71 54 79 70 65 g0...0...reqType 0040: 31 08 04 06 6d 6f 64 69 66 79 30 33 04 05 72 65 1...modify03..re 0050: 71 44 4e 31 2a 04 28 75 69 64 3d 61 63 79 65 6e qDN1*.(uid=acyen 0060: 2c 63 6e 3d 41 63 63 6f 75 6e 74 73 2c 64 63 3d ,cn=Accounts,dc= 0070: 53 74 61 6e 66 6f 72 64 2c 64 63 3d 65 64 75 30 Stanford,dc=edu0 0080: 82 03 87 04 06 72 65 71 4d 6f 64 31 82 03 7b 04 .....reqMod1..{. 0090: 13 6b 72 62 35 50 72 69 6e 63 69 70 61 6c 4e 61 .krb5PrincipalNa 00a0: 6d 65 3a 2d 04 0c 73 75 4b 72 62 34 4e 61 6d 65 me:-..suKrb4Name 00b0: 3a 2d 04 12 73 75 4b 65 72 62 65 72 6f 73 53 74 :-..suKerberosSt 00c0: 61 74 75 73 3a 2d 04 1a 6f 62 6a 65 63 74 43 6c atus:-..objectCl 00d0: 61 73 73 3a 3d 20 73 75 50 74 73 53 65 72 76 69 ass:= suPtsServi 00e0: 63 65 04 17 6f 62 6a 65 63 74 43 6c 61 73 73 3a ce..objectClass: 00f0: 3d 20 73 75 41 63 63 6f 75 6e 74 04 1b 6f 62 6a = suAccount..obj 0100: 65 63 74 43 6c 61 73 73 3a 3d 20 73 75 4f 70 65 ectClass:= suOpe 0110: 72 61 74 69 6f 6e 61 6c 04 1a 6f 62 6a 65 63 74 rational..object 0120: 43 6c 61 73 73 3a 3d 20 73 75 41 66 73 53 65 72 Class:= suAfsSer (etc). bdb_modify_internal: 0x00074e3f: uid=acyen,cn=accounts,dc=stanford,dc=edu <= acl_access_allowed: granted to database root bdb_modify_internal: delete krb5PrincipalName bdb_modify_internal: delete suKrb4Name bdb_modify_internal: delete suKerberosStatus bdb_modify_internal: replace objectClass bdb_modify_internal: replace suIdentifies bdb_modify_internal: replace seeAlso bdb_modify_internal: replace owner bdb_modify_internal: replace suDescription bdb_modify_internal: replace suService bdb_modify_internal: replace suAccountStatus bdb_modify_internal: replace entryCSN bdb_modify_internal: replace modifiersName bdb_modify_internal: replace modifyTimestamp oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suPtsService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suAccount" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suOperational" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suAfsService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suEmailService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suLelandService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suDialinService" oc_check_required entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), objectClass "suSeasService" oc_check_allowed type "suSeasSunetID" oc_check_allowed type "suDialinStatus" oc_check_allowed type "suCreateAgent" oc_check_allowed type "suEmailAdmin" oc_check_allowed type "suSeasUriRouteTo" oc_check_allowed type "suName" oc_check_allowed type "uid" oc_check_allowed type "suNameLF" oc_check_allowed type "suSeasStatus" oc_check_allowed type "suEntryStatus" oc_check_allowed type "suSeasLocal" oc_check_allowed type "suEmailAccountType" oc_check_allowed type "suAfsStatus" oc_check_allowed type "suEmailStatus" oc_check_allowed type "suMailDrop" oc_check_allowed type "suCreateAPI" oc_check_allowed type "suPtsStatus" oc_check_allowed type "suLelandStatus" oc_check_allowed type "structuralObjectClass" oc_check_allowed type "entryUUID" oc_check_allowed type "creatorsName" oc_check_allowed type "createTimestamp" oc_check_allowed type "gecos" Entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), attribute 'gecos' not allowed entry failed schema check: attribute 'gecos' not allowed hdb_modify: modify failed (65) So, it appears to me that even though it must have at some point accepted the first change, the entry on the server is not truly updated to reflect that for some reason? That, or it "skipped" that change for reasons unknown to me. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 02 Jul '09

02 Jul '09

This is a cryptographically signed message in MIME format. --------------ms090702060406060604010109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> Full_Name: Rich Megginson >> Version: current CVS HEAD (as of July 2, 2009) >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.16-moznss-20090702.patch >> >> This is a new patch - diffs from older patch >> 1) Implements tls_m.c MozNSS crypto - including parsing of openssl-style >> cipher suite configuration - things still missing >> 1a) support for multiple MozNSS initialize - work is being done upstream >> to support this >> 1b) support for reading PEM files - there is now a PEM PKCS11 module in >> Fedora which is being incorporated into NSS upstream > > Thanks, I've committed most of this patch. I've omitted the SHA1/MD5 > patches since I think it's better to use our bundled version uniformly > for password hashing. > > For doc purposes, it's simple for us to point people at openssl.org or > gnutls.org; what's a canonical URL to direct people to for MozNSS? I'm not sure - looks like migration is underway to both https://wiki.mozilla.org/NSS and https://developer.mozilla.org/en/NSS but they both refer back to the old "homepage" at http://www.mozilla.org/projects/security/pki/nss/ > >> 2) removes pkg-config stuff from configure.in - user must specify >> include path and lib path in environment > > Ok. The configure patches are in too, so moznss may be selected. But I > think we'll wait on making this generally available until we know what > the story will be for PEM and multi-init. Ok --------------ms090702060406060604010109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwNzAyMjIzNDQyWjAjBgkqhkiG9w0BCQQxFgQUBzW+vw+d Q7cfKi6VjU3nO4/Q+WcwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQB7RxgkWvk/Ve15UeL2O2vKELQZrH6PZWNKgAJx qbGMwrGIlZK4PBV4gIelgjnYJ7DGGTmNck0OCsFg6t9a7jPHPZNJZoNsCw/OZKQsh0vELmvC +dTAFn37JWKV5Td/1KWnDcWpR1XW3Vb7pw/rIs4kFr2IPSMWvKrnMzOQULqAfVrXiI0E0kky +sS3wiTKSb2m5XnsXdfkiHsOrqNkkOXk3Bf8sSS6PhZzwSsEiOuC7xHFTnQq56UCLWNdltEP acZggyGp4eTOxSDwcoEqpdpi91s6YcGoIWbLgsC21446js3qpG5QoR2HTLUqCOPkeA+LZtho Q/rrhJwlvXZlw/7SAAAAAAAA --------------ms090702060406060604010109--

1 0

(ITS#6195) Replications with 2.3.43 master to 2.4.16 slave is failing
by whm＠stanford.edu 02 Jul '09

02 Jul '09

Full_Name: Bill MacAllister Version: 2.3.43+ and 2.4.16+ OS: debian 4 and 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) I have a master server that is running 2.3.43 and a slave running 2.4.16. When the master/replica databases are created an entry has an objectclass=posixaccount and gecos=some-name. When the objectclass/gecos is deleted from the master entry replication on the slave fails with: Jul 2 11:16:46 ldap-liv1 slapd[30523]: Entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), attribute 'gecos' not allowed Jul 2 11:16:46 ldap-liv1 slapd[30523]: entry failed schema check: attribute 'gecos' not allowed Jul 2 11:16:46 ldap-liv1 slapd[30523]: null_callback : error code 0x41 Jul 2 11:16:46 ldap-liv1 slapd[30523]: syncrepl_message_to_op: rid=000 be_modify uid=acyen,cn=Accounts,dc=Stanford,dc=edu (65) Jul 2 11:16:46 ldap-liv1 slapd[30523]: do_syncrepl: rid=000 rc 65 retrying Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 fd=13 ACCEPT from IP=171.67.22.24:42094 (IP=0.0.0.0:389) Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=0 BIND dn="" method=128 Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=0 RESULT tag=97 err=0 text= Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=1 SRCH base="dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=*)" Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 op=2 UNBIND Jul 2 11:17:04 ldap-liv1 slapd[30523]: conn=368 fd=13 closed Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 fd=13 ACCEPT from IP=171.67.16.36:35971 (IP=0.0.0.0:389) Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=0 BIND dn="" method=128 Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=0 RESULT tag=97 err=0 text= Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=1 SRCH base="dc=stanford,dc=edu" scope=0 deref=0 filter="(objectClass=*)" Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 op=2 UNBIND Jul 2 11:17:28 ldap-liv1 slapd[30523]: conn=369 fd=13 closed Jul 2 11:17:28 ldap-liv1 slapd[30523]: connection_read(13): no connection! Jul 2 11:17:46 ldap-liv1 slapd[30523]: Entry (uid=acyen,cn=accounts,dc=stanford,dc=edu), attribute 'gecos' not allowed Jul 2 11:17:46 ldap-liv1 slapd[30523]: entry failed schema check: attribute 'gecos' not allowed Jul 2 11:17:46 ldap-liv1 slapd[30523]: null_callback : error code 0x41 Jul 2 11:17:46 ldap-liv1 slapd[30523]: syncrepl_message_to_op: rid=000 be_modify uid=acyen,cn=Accounts,dc=Stanford,dc=edu (65) Jul 2 11:17:46 ldap-liv1 slapd[30523]: do_syncrepl: rid=000 rc 65 retrying It looks like there is an attempt to remove objectclass=posixaccount without removing gecos at the same time. I have re-created the slave database a second time just to make sure there was nothing that I missed with the initial load.

1 0

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by hyc＠symas.com 02 Jul '09

02 Jul '09

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: current CVS HEAD (as of July 2, 2009) > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-moznss-20090702.patch > > This is a new patch - diffs from older patch > 1) Implements tls_m.c MozNSS crypto - including parsing of openssl-style > cipher suite configuration - things still missing > 1a) support for multiple MozNSS initialize - work is being done upstream > to support this > 1b) support for reading PEM files - there is now a PEM PKCS11 module in > Fedora which is being incorporated into NSS upstream Thanks, I've committed most of this patch. I've omitted the SHA1/MD5 patches since I think it's better to use our bundled version uniformly for password hashing. For doc purposes, it's simple for us to point people at openssl.org or gnutls.org; what's a canonical URL to direct people to for MozNSS? > 2) removes pkg-config stuff from configure.in - user must specify > include path and lib path in environment Ok. The configure patches are in too, so moznss may be selected. But I think we'll wait on making this generally available until we know what the story will be for PEM and multi-init. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs