openldap-bugs July 2009

openldap-bugs@openldap.org

49 participants
166 discussions

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 06 Jul '09

06 Jul '09

--On Monday, July 06, 2009 6:07 PM +0000 jorge.perez(a)adaptia.net wrote: > Hi, > > Sorry for the HTML email. > > With the debug symbols there's an assert that fails in slapd_clr_write > method, ("assert( SLAP_SOCK_IS_ACTIVE( s ))"): Thanks. The hang should really be fixed now. :P Please re-sync RE24 and test again. Thank you! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6197) ldap_err2string()/ldap_perror() strangeness
by h.b.furuseth＠usit.uio.no 06 Jul '09

06 Jul '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_err2string() and ldap_perror() use ldap_int_error(), which walks an array looking for the result code. That's silly, I'll replace it with a macroized switch statement unless someone protests. Compilers will usually turn that into a binary search or better. A prebuilt hash would be better, but would complicate source code maintenance. I might do that someday if anyone cares. Also don't see why ldap_perror() outputs a less informative error string than ldap_err2string() for unknown result codes. ldap_perror says "unknown result code" (with lowercase initial), while err2string says "Unknown <API error/(extension) error/(private extension) error/error". Looks like ldap_perror() could be improved by calling ldap_err2string(). (Yes I know ldap_perror is deprecated. See if I care, I like it.)

1 0

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

06 Jul '09

Hi, Sorry for the HTML email. With the debug symbols 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=3D<value optimized out>, wake=3D0) at daemon.c:939 #4 0x00000000004422dc in connection_write (s=3D403) at connection.c:1855 #5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<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 ?? () Without debug symbols, using gdb to attach to the process it can be seen all the threads hang on the pthread_cond_wait in send_ldap_ber method in result.c. Best regards. On Mon, Jul 6, 2009 at 7:29 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wro= te: > > --On Monday, July 06, 2009 7:22 AM +0000 jorge.perez(a)adaptia.net wrote: > >> --001636c5b1542f27b3046e045d1b >> Content-Type: text/plain; charset=3DUTF-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=3D<value optimized out>, >>> # wake=3D0) >>> at daemon.c:939 >>> # 4 0x00000000004422dc in connection_write (s=3D403) at connection.c:18= 55 >>> # 5 0x00000000004410e6 in slapd_daemon_task (ptr=3D<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.. > > Can you please stop writing HTML email? thanks. ;) > > Also, can you please re-compile with debugging symbols available, and pro= vide a backtrace of the hung server? :) > > Thanks, > Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: =C2=A0the leader in open source messaging and collaboration

1 0

Re: (ITS#5836) hung writers
by quanah＠zimbra.com 06 Jul '09

06 Jul '09

--On Monday, July 06, 2009 7:22 AM +0000 jorge.perez(a)adaptia.net wrote: > --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.. Can you please stop writing HTML email? thanks. ;) Also, can you please re-compile with debugging symbols available, and provide a backtrace of the hung server? :) Thanks, 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 hyc＠symas.com 06 Jul '09

06 Jul '09

rmeggins(a)redhat.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms020502060206020809020001 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Hallvard B Furuseth 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); >> >> > I think Howard was going to omit the passwd.c changes. I applied the DES changes, and dropped the SHA1 changes. The version now in HEAD also avoids this naming conflict. -- -- 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 rmeggins＠redhat.com 06 Jul '09

06 Jul '09

This is a cryptographically signed message in MIME format. --------------ms020502060206020809020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hallvard B Furuseth 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); > > I think Howard was going to omit the passwd.c changes. --------------ms020502060206020809020001 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 ATAcBgkqhkiG9w0BCQUxDxcNMDkwNzA2MTUwNTE5WjAjBgkqhkiG9w0BCQQxFgQUEhRXD3S8 y7XRMK4qRv/cvAGaP7MwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQAsIFbd928YyHFnVXHDB6vIbO0MX7chq9nDKj4l HeCgXft1yEARDQ8ra3s4hApdNnE1PicCx2yrmPuQivjRo7tsZ2CCIBvH8aIrbxhEa0ZJ2USC pTgNIG2lk1cFiQ7c09NZSFwuU+s0Vp5M7b+U68VkJ+UV1WLeslYJT3QubNvz91C5uVeldQQ/ gPjbKVS74MN1bCDtPfHMIkhvSSR4Fmv8/89ZEAjYHE4m02ppr4ij8foA62jdESzJ2RXDdl7q spoxNwUqBKKJnlO11+40BXlWH2Vr+ssPoyEczDwfYbQkYnUNmgQKaNjp2Bs8sZAj0CpdhRI/ mhCTUoQQXZHSVBOPAAAAAAAA --------------ms020502060206020809020001--

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2009