openldap-bugs

openldap-bugs@openldap.org

1 participants
21146 discussions

(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 08 Feb '07

08 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 08 Feb '07

08 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 08 Feb '07

08 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

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

08 Feb '07

<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. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. 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#4837) SunLDAP to OpenLDAP migration problem
by rklein＠deep-field.com 08 Feb '07

08 Feb '07

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.

1 0

Re: (ITS#4834) DN matching rules should be indexed
by h.b.furuseth＠usit.uio.no 08 Feb '07

08 Feb '07

Howard Chu writes: > That's a good idea but would require more work to define indexer > functions for each matching rule before we could do anything further. I was thinking to only support it for existing indexer functions. Would 'index cn :caseExactMatch' require a new indexer function? > My reason for posting this ITS is that we already have the index > available for the DN relativeMatch rules, so we should be taking > advantage of them. Fair enough. -- Regards, Hallvard

1 0

Re: (ITS#4836) dynamic configuration support for ppolicy
by hyc＠symas.com 08 Feb '07

08 Feb '07

bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: OPENLDAP_REL_ENG_2_3 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.25.211.20) > > > Dynamic configuration would remove the need for restarting slapd in many > situations (add a schema, add an index), however sites requiring ppolicy on any > database in running in the same slapd cannot use dynamic configuration since > ppolicy in REL_ENG_2_3 does not have dynamic configuration support. > > ppolicy in HEAD does have such support, but the version from head does not > compile on REL_ENG_2_3, and various bugfixes since it was originally added > depend on features in HEAD. > It would be useful to have dynamic configuration support for ppolicy in > REL_ENG_2_3. "Would be useful" doesn't sound like a bug report to me, and RE23 really shouldn't be receiving enhancements at this stage of its cycle. I've added the necessary patches to RE23, but understand that requests of this sort are much less likely to be honored going forward. New code will be in 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs