openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

ITS#2240
by hyc＠symas.com 12 Feb '07

12 Feb '07

I've written up all of the remaining missing pages noted in this ITS. Someone else should review the docs to double-check and see if anything was omitted. I'll leave it up to someone else to add to RE23 if desired, otherwise we'll just leave these for RE24. -- -- Howard Chu Chief Architect, 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#4840) Typo in comment within ldap.h
by hyc＠symas.com 12 Feb '07

12 Feb '07

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: not relevant here > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.29.37) > > >>From ldap.h: > > -------------------------------------------------------------------------- > LDAP_F( void ) > ldap_value_free LDAP_P(( /* deprecated, use ldap_values_free_len */ > char **vals )); > #endif > -------------------------------------------------------------------------- > > I guess the comment should mention "ldap_value_free_len". > ^^ > > Ciao, Michael. Fixed in HEAD... Same typo is in RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4840) Typo in comment within ldap.h
by michael＠stroeder.com 12 Feb '07

12 Feb '07

Full_Name: Michael Ströder Version: HEAD OS: not relevant here URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.29.37) >From ldap.h: -------------------------------------------------------------------------- LDAP_F( void ) ldap_value_free LDAP_P(( /* deprecated, use ldap_values_free_len */ char **vals )); #endif -------------------------------------------------------------------------- I guess the comment should mention "ldap_value_free_len". ^^ Ciao, Michael.

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by hyc＠symas.com 11 Feb '07

11 Feb '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > I'm seeing occasional failures of syncrepl-related tests in HEAD. In case of > test043, results differend once, but after repeating the test everything went > smoth. > > In some cases test045 resulted in a core dump: > In this case, numcsns is 8 because syncprov incorrectly tested for > BER_BVISEMPTY() instead of BER_BVISNULL when creating the csn array: Good catch. > Fixing that still results in a test failure, but without core dump: > apparently, none of the modifications made it into the consumer. > After another try, things just go smooth again... keep testing. We need to change these fixed delays for replication into explicit checks like you did for test049. Otherwise it will take too long to loop the tests enough times to trigger an error... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4839) syncrepl-related tests fail randomly
by ando＠sys-net.it 10 Feb '07

10 Feb '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I'm seeing occasional failures of syncrepl-related tests in HEAD. In case of test043, results differend once, but after repeating the test everything went smoth. In some cases test045 resulted in a core dump: (gdb) bt #0 0x00418060 in memchr () from /lib/tls/libc.so.6 #1 0x080f5eef in slap_parse_csn_sid (csn=0x87b6798) at ldapsync.c:128 #2 0x080f5fa1 in slap_parse_csn_sids (csns=0x87b6778, numcsns=8) at ldapsync.c:148 #3 0x081ce0c6 in syncprov_db_open (be=0x8770bd0) at syncprov.c:2544 #4 0x080f31de in over_db_func (be=0x8770bd0, which=db_open) at backover.c:61 #5 0x080f35dd in over_db_open (be=0x8770bd0) at backover.c:173 #6 0x0808e1d1 in backend_startup_one (be=0x8770bd0) at backend.c:212 #7 0x0808e65e in backend_startup (be=0x8770bd0) at backend.c:303 #8 0x080b578a in slap_startup (be=0x0) at init.c:248 #9 0x08062ee1 in main (argc=8, argv=0xbffa3554) at main.c:919 In this case, numcsns is 8 because syncprov incorrectly tested for BER_BVISEMPTY() instead of BER_BVISNULL when creating the csn array: (gdb) p a->a_vals[0]@8 $2 = {{ bv_len = 40, bv_val = 0x87deb60 "20070210093621.965471Z#000000#000#000000" }, { bv_len = 7566177, bv_val = 0x0 }, { bv_len = 24, bv_val = 0x11 "" }, { bv_len = 1820143995, bv_val = 0x706164 "�s����F���\211L$\004\213E\b\211\004$�\037���\205�\211E�\017\204\r����\033���=�\206��tb\213M�\213\001�@\030\002\215v" }, { bv_len = 541392999, bv_val = 0x21 "" }, { bv_len = 142432232, bv_val = 0x65 "" }, { bv_len = 142470176, bv_val = 0x0 }, { bv_len = 142305208, bv_val = 0x0 }} Fixing that still results in a test failure, but without core dump: bash-3.00$ SLAPD_DEBUG=stats ./run test045 Cleaning up test run directory leftover from previous run. Running ./scripts/test045-syncreplication-proxied... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Starting proxy slapd on TCP/IP port 9013... Using ldapsearch to check that proxy slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... 1 < Comparing retrieved entries from master and slave... 2 > Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 15 seconds for syncrepl to receive changes... 2 < Comparing retrieved entries from master and slave... test failed - master and slave databases differ apparently, none of the modifications made it into the consumer. After another try, things just go smooth again... keep testing. p.

1 0

Re: (ITS#4838) test027-emptydn fails with current had
by hyc＠symas.com 09 Feb '07

09 Feb '07

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.156.155) > > > It seems to fail since that last commit to back-bdb. The slapd instance starts > fine, but the ldapsearch with an empty base fails with NO_SUCH_OJBECT. > > Running ./scripts/test027-emptydn... > running defines.sh > Running slapadd to build "dc=example,dc=com" slapd database... > Running slapadd to build empty DN slapd database... > Starting slapd on TCP/IP port 9011... > Testing slapd empty DN handling... > Searching database... > ldapsearch failed (32)! Thanks, fixed. All tests pass. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4838) test027-emptydn fails with current had
by rhafer＠suse.de 09 Feb '07

09 Feb '07

Full_Name: Ralf Haferkamp Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.156.155) It seems to fail since that last commit to back-bdb. The slapd instance starts fine, but the ldapsearch with an empty base fails with NO_SUCH_OJBECT. Running ./scripts/test027-emptydn... running defines.sh Running slapadd to build "dc=example,dc=com" slapd database... Running slapadd to build empty DN slapd database... Starting slapd on TCP/IP port 9011... Testing slapd empty DN handling... Searching database... ldapsearch failed (32)!

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by kurt＠OpenLDAP.org 09 Feb '07

09 Feb '07

On Feb 8, 2007, at 5:12 PM, rklein(a)deep-field.com wrote: > "The passwords from SunONE are stored in SSHA format. This means that > for each password a salt has been generated. The password + salt is > encoded > using > SHA1 algorithm. That encoded string + salt is stored in the > password field. > > Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE > uses an 8 byte salt and OpenLDAP uses a 4 byte salt. For hash generation, yes. But the hash checking code will compute the salt size on a per check basis. > So, when OpenLDAP looks at the password strings, it gets the wrong > salt, > and will fail to decode the password." Conclusion doesn't follow. Have you actually tested this? I believe it just works. -- Kurt

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by ghenry＠suretecsystems.com 09 Feb '07

09 Feb '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="rklein(a)deep-field.com"> >> We want to migrate from using SunLDAP to using OpenLDAP. This involves >> migrating >> the existing user data from SunLDAP to OpenLDAP. We were able to do this >> successfully, however, we found an incompatibility in password >> encryption. >> Specifically: >> >> "The passwords from SunONE are stored in SSHA format. This means that >> for each password a salt has been generated. The password + salt is >> encoded >> using >> SHA1 algorithm. That encoded string + salt is stored in the password >> field. >> >> Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE >> uses an 8 byte salt and OpenLDAP uses a 4 byte salt. >> >> So, when OpenLDAP looks at the password strings, it gets the wrong salt, >> and will fail to decode the password." >> >> We're therefore requesting that OpenLDAP provide an option for an 8 byte >> salt >> for the SSHA encryption that is compatible with the SunONE encryption. >> This will >> allow us to convert to OpenLDAP without requiring all of our users to >> reset >> their passwords. Thanks. >> > > Hi, > > Sorry, I don't mean to point out the obvious, but OpenLDAP is an Open > Source project which means the source code is available for you to patch. > However, you can edit passwd.c: libraries/liblutil/passwd.c and change the salt to 8 yourself: #define SALT_SIZE 4 See how you get on. Gavin.

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by quanah＠stanford.edu 09 Feb '07

09 Feb '07

--On Thursday, February 08, 2007 5:12 PM +0000 rklein(a)deep-field.com wrote: > Full_Name: Ruth Klein > Version: 2.3.24 > OS: Solaris 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.247.247.122) > > > We want to migrate from using SunLDAP to using OpenLDAP. This involves > migrating the existing user data from SunLDAP to OpenLDAP. We were able > to do this successfully, however, we found an incompatibility in password > encryption. Specifically: > > "The passwords from SunONE are stored in SSHA format. This means that > for each password a salt has been generated. The password + salt is > encoded using > SHA1 algorithm. That encoded string + salt is stored in the password > field. > Both SunONE and OpenLDAP support SSHA, however, it seems that SunONE > uses an 8 byte salt and OpenLDAP uses a 4 byte salt. > > So, when OpenLDAP looks at the password strings, it gets the wrong salt, > and will fail to decode the password." > > We're therefore requesting that OpenLDAP provide an option for an 8 byte > salt for the SSHA encryption that is compatible with the SunONE > encryption. This will allow us to convert to OpenLDAP without requiring > all of our users to reset their passwords. Thanks. It should be as simple as changing: passwd.c:#define SALT_SIZE 4 to passwd.c:#define SALT_SIZE 8 One of the nice things about open source... In any case, perhaps this should be considered an enhancement request for an option in slapd.conf to set the salt size there. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

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