- openldap-bugs - openldap.org

Re: ITS#2240
by ghenry＠suretecsystems.com 13 Feb '07

13 Feb '07

<quote who="Howard Chu"> > Gavin Henry wrote: >> hyc(a)symas.com said the following on 12/02/07 11:04: >>> 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. >> >> >> I can't see any of these in man3 at: >> >> http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/?hideattic=1&sortbyda… >> >> Am I looking in the wrong place? > > They all show up for me... > > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-sockbuf.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-types.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_bind.3 > (ITS#3349) > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_controls.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_memory.3 > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_open.3 > (ITS#4662) > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_tls.3 > Must have been "early morning blind eyes" ;-) Thanks.

1 0

(ITS#4842) Can slapd run with only one thread to operate
by seuler.shi＠gmail.com 13 Feb '07

13 Feb '07

Full_Name: Seuler.Shi Version: 2.3.30 OS: SUSE server 9.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) The threads parameter in slapd.conf can not be configured below 2. I pretend to eleminate this limit by removing the folloing code in servers\slapd\bconfig.c file ================================================================= if ( c->value_int < 2 ) { snprintf( c->msg, sizeof( c->msg ), "threads=%d smaller than minimum value 2", c->value_int ); Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); return 1; } else if ( c->value_int > 2 * SLAP_MAX_WORKER_THREADS ) { snprintf( c->msg, sizeof( c->msg ), "warning, threads=%d larger than twice the default (2*%d=%d); YMMV", c->value_int, SLAP_MAX_WORKER_THREADS, 2 * SLAP_MAX_WORKER_THREADS ); Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 ); } ==================================================================== After rebuilding the modified code, the slapd can not operate request and return. I have tried another method: build the code with configuring --without--threads, the newly bebuilt code can start but can not accpet request and return and segment fault error, then the slapd crashes. How to modify the code to eleminate limit of the minimum number of threads? Thanks a lot!

1 0

Re: ITS#2240
by hyc＠symas.com 13 Feb '07

13 Feb '07

Gavin Henry wrote: > hyc(a)symas.com said the following on 12/02/07 11:04: >> 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. > > > I can't see any of these in man3 at: > > http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/?hideattic=1&sortbyda… > > Am I looking in the wrong place? They all show up for me... http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-sockbuf.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/lber-types.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_bind.3 (ITS#3349) http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_controls.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_memory.3 http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_open.3 (ITS#4662) http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/ldap_tls.3 -- -- 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#2240
by ghenry＠suretecsystems.com 13 Feb '07

13 Feb '07

hyc(a)symas.com said the following on 12/02/07 11:04: > 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. I can't see any of these in man3 at: http://www.openldap.org/devel/cvsweb.cgi/doc/man/man3/?hideattic=1&sortbyda… Am I looking in the wrong place? 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

RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il 12 Feb '07

12 Feb '07

Sure. New core dumps and binary file is at http://mariska.inter.net.il/~imriz/slapd-core.tar.gz Please notice that the previous dump was from FreeBSD ports (OpenLDAP version 2.3.33). This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the following configure options: ./configure --with-threads=posix --with-tls=openssl --enable-dynamic --without-cyrus-sasl --enable-modules --localstatedir=/var/ db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable-ldap=mod --enable-meta=mod --enable-rewrite --enable-null=mod --enabl e-monitor=mod --enable-proxycache --disable-syncprov --enable-bdb=mod --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- prefix=/usr/local --enable-debug -----Original Message----- From: Howard Chu [mailto:openldap-its@OpenLDAP.org] Sent: Tuesday, February 13, 2007 1:14 AM To: Imri Zvik Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) It looks like this core is from a binary without debug symbols present, can you recompile with debugging enabled and get a new stack trace and core file?

1 0

(ITS#4841) slapd+pcache keeps crashing on FreeBSD 6.2
by imriz＠co.zahav.net.il 12 Feb '07

12 Feb '07

Full_Name: Imri Zvik Version: 2.3.33 OS: FreeBSD 6.2 URL: http://mariska.inter.net.il/~imriz/75624-slapd.core Submission from: (NULL) (213.8.76.159) slapd keeps crashing every couple of hours, backtrace is as follows: (gdb) bt #0 0xa83ae58a in strcasecmp () from /lib/libc.so.6 #1 0x080a934c in an_find () #2 0x080d59bd in overlay_init () #3 0x080d61dc in overlay_init () #4 0x080c837d in overlay_op_walk () #5 0x080c8599 in overlay_op_walk () #6 0x080c8616 in overlay_op_walk () #7 0x0806ebc3 in fe_op_search () #8 0x0806e6e2 in do_search () #9 0x0806c147 in connection_done () #10 0xa816b936 in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.3.so.2 #11 0xa83025cf in pthread_create () from /usr/lib/libthr.so.2 #12 0x00000000 in ?? () complete core dump is provided.

1 0

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 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

(ITS#4836) dynamic configuration support for ppolicy
by bgmilne＠staff.telkomsa.net 08 Feb '07

08 Feb '07

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.

1 0

Re: (ITS#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

kurt(a)OpenLDAP.org wrote: > On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > >> h.b.furuseth(a)usit.uio.no wrote: >>> Suggestion: Generalize a bit and support the slapd.conf statement >>> >>> index attr :matchingRule >>> >>> Can be used with the extended filter (attr:matchingRule:=foo), >>> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >>> >> That's a good idea but would require more work to define indexer >> functions >> for each matching rule before we could do anything further. 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. > > I note that dn2id is only useful for entryDN matching. For > matching of arbitrary DN attributes, additional indexing would > be needed. True. For the examples I've seen, this is good enough, and it's trivial to support it. > It may be possible/reasonable to integrate indexing > for this with component matching indexing... which, of course, > needs work. Yes, and time... -- -- 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#4834) DN matching rules should be indexed
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Suggestion: Generalize a bit and support the slapd.conf statement >> >> index attr :matchingRule >> >> Can be used with the extended filter (attr:matchingRule:=foo), >> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >> > That's a good idea but would require more work to define indexer > functions > for each matching rule before we could do anything further. 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. I note that dn2id is only useful for entryDN matching. For matching of arbitrary DN attributes, additional indexing would be needed. It may be possible/reasonable to integrate indexing for this with component matching indexing... which, of course, needs work. -- Kurt > > -- > -- 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#4556 ditStructureRules
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 7, 2007, at 11:22 PM, hyc(a)symas.com wrote: > I've often thought about adding support here, but it looks like an > all-or-nothing proposition. I.e., when you have a server that uses > ditStructureRules, you must actually define a full set of rules > otherwise you > cannot add any user entries to the directory at all. This would be > a pretty > drastic change for people accustomed to the current behavior, where > you can > put any entry you like anywhere you like. Beginners have a hard > enough time > just getting their first two entries into the directory; requiring > the use of > ditStructureRules would seem to just make a bad situation worse. It may be possible to do something similar to what was done for ditContentRules, which are also all or none in X.500 (no rules defined means no use of aux objectcleasses in X.500). In OpenLDAP, no rules means any use of auxiliary classes is okay. But if you add a rule, any rule, then these defined rules must be followed. -- Kurt > > Possibly we could make it a configurable option - enable them with a > per-database setting, defaulting to off to preserve the current > behavior. > Fully aligning with X.500 practices would have to wait for a new > generation > of server. E.g., we currently support the use of subdatabases using > subordinate/glue. These provide some of the notion of X.500 > Administrative > Areas, except their definitions reside in the cn=config tree, not as > subentries of the main DIT. Providing full subentry-based > administration > would be a major change in how the server is operated and how the > DIT is > administered. Something for OpenLDAP 3.0. > -- > -- 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#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

h.b.furuseth(a)usit.uio.no wrote: > Suggestion: Generalize a bit and support the slapd.conf statement > > index attr :matchingRule > > Can be used with the extended filter (attr:matchingRule:=foo), > or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. > That's a good idea but would require more work to define indexer functions for each matching rule before we could do anything further. 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. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs