Full_Name: Gavin Henry Version: 2.3.34 OS: FC6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Dear All, Just been playing iwth slapo-translucent, and ldapmodified an entry on the remote side successfully. However, when I search for that entry, after the first or second search, slapd aborts. I merely changed a birthday and title for my own ghenry entry Here my slapd.conf: ------------------------- include /usr/local/etc/openldap/schema/core.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb.la moduleload back_ldap.la moduleload translucent.la moduleload rwm.la database bdb directory /usr/local/var/openldap-data cachesize 10000 suffix "dc=suretecsystems,dc=com" rootdn "cn=manager,dc=suretecsystems,dc=com" rootpw secret index default eq index objectClass,uid,dc,o,ou overlay translucent overlay rwm uri ldap://192.168.10.103:389 lastmod off idassert-bind binddn="cn=manager,dc=suretecsystems,dc=com" credentials=secret rwm-map objectclass * * rwm-map attribute * * ------------------------- Using db-4.2.52 and the 5 patches. He's a gdb session: [Thread debugging using libthread_db enabled] [New Thread -1209051456 (LWP 4529)] @(#) $OpenLDAP: slapd 2.3.34 (Mar 20 2007 14:53:32) $ ghenry@suretec:/home/ghenry/openldap/openldap-2.3.34/servers/slapd WARNING: No dynamic config support for database bdb. WARNING: No dynamic config support for overlay rwm. WARNING: No dynamic config support for overlay translucent. bdb_db_open: unclean shutdown detected; attempting recovery. slapd starting [New Thread -1547441264 (LWP 4532)] conn=0 fd=15 ACCEPT from IP=127.0.0.1:33269 (IP=0.0.0.0:389) [New Thread -1557931120 (LWP 4534)] conn=0 op=0 BIND dn="" method=128 conn=0 op=0 RESULT tag=97 err=0 text= [New Thread -1569473648 (LWP 4535)] conn=0 op=1 SRCH base="dc=suretecsystems,dc=com" scope=2 deref=0 filter="(uid=ghenry)" request done: ld 0x8e0dd10 msgid 1 request done: ld 0x8e0dd10 msgid 2 conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=2 UNBIND conn=0 fd=15 closed *** glibc detected *** /usr/local/libexec/slapd: corrupted double-linked list: 0x08e19458 *** ======= Backtrace: ========= /lib/libc.so.6[0xb0448b] /lib/libc.so.6[0xb066f3] /lib/libc.so.6(__libc_calloc+0x8d)[0xb07bdd] /lib/libc.so.6(open_memstream+0x5d)[0xafce7d] /lib/libc.so.6(__vsyslog_chk+0x76)[0xb69656] /lib/libc.so.6(syslog+0x2a)[0xb69bfa] /usr/local/libexec/slapd[0x80687e5] /usr/local/libexec/slapd[0x8068c9c] /usr/local/lib/libldap_r-2.3.so.0[0x11b56d] /lib/libpthread.so.0[0xc133db] /lib/libc.so.6(clone+0x5e)[0xb6d26e] ======= Memory map: ======== 00110000-00148000 r-xp 00000000 fd:00 10953537 /usr/local/lib/libldap_r-2.3.so.0.2.22 00148000-0014a000 rwxp 00037000 fd:00 10953537 /usr/local/lib/libldap_r-2.3.so.0.2.22 0014a000-0014f000 rwxp 0014a000 00:00 0 0014f000-0015a000 r-xp 00000000 fd:00 10953351 /usr/local/lib/liblber-2.3.so.0.2.22 0015a000-0015b000 rwxp 0000a000 fd:00 10953351 /usr/local/lib/liblber-2.3.so.0.2.22 0015b000-0015f000 r-xp 00000000 fd:00 11025778 /usr/lib/sasl2/libcrammd5.so.2.0.22 0015f000-00160000 rwxp 00003000 fd:00 11025778 /usr/lib/sasl2/libcrammd5.so.2.0.22 00160000-0023b000 r-xp 00000000 fd:00 11031861 /usr/lib/sasl2/libsasldb.so.2.0.22 0023b000-0023d000 rwxp 000db000 fd:00 11031861 /usr/lib/sasl2/libsasldb.so.2.0.22 0023d000-00251000 r-xp 00000000 fd:00 820357 /usr/local/libexec/openldap/back_ldap-2.3.so.0.2.22 00251000-00253000 rwxp 00013000 fd:00 820357 /usr/local/libexec/openldap/back_ldap-2.3.so.0.2.22 00253000-0025e000 r-xp 00000000 fd:00 2290131 /lib/libgcc_s-4.1.1-20070105.so.1 0025e000-0025f000 rwxp 0000a000 fd:00 2290131 /lib/libgcc_s-4.1.1-20070105.so.1 0027c000-00282000 r-xp 00000000 fd:00 10928729 /usr/lib/libltdl.so.3.1.4 00282000-00283000 rwxp 00005000 fd:00 10928729 /usr/lib/libltdl.so.3.1.4 002e2000-002e9000 r-xp 00000000 fd:00 10929498 /usr/lib/libwrap.so.0.7.6 002e9000-002ea000 rwxp 00007000 fd:00 10929498 /usr/lib/libwrap.so.0.7.6 002ea000-003a5000 r-xp 00000000 fd:00 393521 /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so 003a5000-003a7000 rwxp 000bb000 fd:00 393521 /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so 003f3000-003fc000 r-xp 00000000 fd:00 2289320 /lib/libnss_files-2.5.so 003fc000-003fd000 r-xp 00008000 fd:00 2289320 /lib/libnss_files-2.5.so 003fd000-003fe000 rwxp 00009000 fd:00 2289320 /lib/libnss_files-2.5.so 004ca000-004ce000 r-xp 00000000 fd:00 11028143 /usr/lib/sasl2/liblogin.so.2.0.22 004ce000-004cf000 rwxp 00003000 fd:00 11028143 /usr/lib/sasl2/liblogin.so.2.0.22 00504000-00528000 r-xp 00000000 fd:00 820345 /usr/local/libexec/openldap/back_bdb-2.3.so.0.2.22 00528000-00529000 rwxp 00024000 fd:00 820345 /usr/local/libexec/openldap/back_bdb-2.3.so.0.2.22 00529000-00535000 rwxp 00529000 00:00 0 00695000-00696000 r-xp 00695000 00:00 0 [vdso] 0071d000-00721000 r-xp 00000000 fd:00 820437 /usr/local/libexec/openldap/translucent-2.3.so.0.2.22 00721000-00722000 rwxp 00003000 fd:00 820437 /usr/local/libexec/openldap/translucent-2.3.so.0.2.22 007fe000-00809000 r-xp 00000000 fd:00 11025782 /usr/lib/sasl2/libdigestmd5.so.2.0.22 00809000-0080a000 rwxp 0000b000 fd:00 11025782 /usr/lib/sasl2/libdigestmd5.so.2.0.22 00916000-00929000 r-xp 00000000 fd:00 2290139 /lib/libnsl-2.5.so 00929000-0092a000 r-xp 00012000 fd:00 2290139 /lib/libnsl-2.5.so 0092a000-0092b000 rwxp 00013000 fd:00 2290139 /lib/libnsl-2.5.so 0092b000-0092d000 rwxp 0092b000 00:00 0 0092f000-0093e000 r-xp 00000000 fd:00 2290132 /lib/libresolv-2.5.so 0093e000-0093f000 r-xp 0000e000 fd:00 2290132 /lib/libresolv-2.5.so 0093f000-00940000 rwxp 0000f000 fd:00 2290132 /lib/libresolv-2.5.so 00940000-00942000 rwxp 00940000 00:00 0 0099a000-0099e000 r-xp 00000000 fd:00 11021253 /usr/lib/sasl2/libanonymous.so.2.0.22 0099e000-0099f000 rwxp 00003000 fd:00 11021253 /usr/lib/sasl2/libanonymous.so.2.0.22 009a5000-009a7000 r-xp 00000000 fd:00 2290133 /lib/libcom_err.so.2.1 009a7000-009a8000 rwxp 00001000 fd:00 2290133 /lib/libcom_err.so.2.1 009aa000-00a2e000 r-xp 00000000 fd:00 10928447 /usr/lib/libkrb5.so.3.2 00a2e000-00a30000 rwxp 00084000 fd:00 10928447 /usr/lib/libkrb5.so.3.2 00a32000-00a39000 r-xp 00000000 fd:00 10928445 /usr/lib/libkrb5support.so.0.1 00a39000-00a3a000 rwxp 00006000 fd:00 10928445 /usr/lib/libkrb5support.so.0.1 00a3c000-00a61000 r-xp 00000000 fd:00 10928446 /usr/lib/libk5crypto.so.3.0 00a61000-00a62000 rwxp 00025000 fd:00 10928446 /usr/lib/libk5crypto.so.3.0 00a83000-00a9c000 r-xp 00000000 fd:00 2289282 /lib/ld-2.5.so 00a9c000-00a9d000 r-xp 00018000 fd:00 2289282 /lib/ld-2.5.so 00a9d000-00a9e000 rwxp 00019000 fd:00 2289282 /lib/ld-2.5.so 00aa0000-00bd7000 r-xp 00000000 fd:00 2289319 /lib/libc-2.5.so 00bd7000-00bd9000 r-xp 00137000 fd:00 2289319 /lib/libc-2.5.so 00bd9000-00bda000 rwxp 00139000 fd:00 2289319 /lib/libc-2.5.so 00bda000-00bdd000 rwxp 00bda000 00:00 0 00c08000-00c0a000 r-xp 00000000 fd:00 2289374 /lib/libdl-2.5.so 00c0a000-00c0b000 r-xp 00001000 fd:00 2289374 /lib/libdl-2.5.so 00c0b000-00c0c000 rwxp 00002000 fd:00 2289374 /lib/libdl-2.5.so 00c0e000-00c21000 r-xp 00000000 fd:00 2289321 /lib/libpthread-2.5.so 00c21000-00c22000 r-xp 00012000 fd:00 2289321 /lib/libpthread-2.5.so 00c22000-00c23000 rwxp 00013000 fd:00 2289321 /lib/libpthread-2.5.so 00c23000-00c25000 rwxp 00c23000 00:00 0 00c27000-00c39000 r-xp 00000000 fd:00 10928409 /usr/lib/libz.so.1.2.3 00c39000-00c3a000 rwxp 00011000 fd:00 10928409 /usr/lib/libz.so.1.2.3 00c49000-00c51000 r-xp 00000000 fd:00 820429 /usr/local/libexec/openldap/rwm-2.3.so.0.2.22 00c51000-00c52000 rwxp 00008000 fd:00 820429 /usr/local/libexec/openldap/rwm-2.3.so.0.2.22 00da4000-00da8000 r-xp 00000000 fd:00 11028147 /usr/lib/sasl2/libplain.so.2.0.22 00da8000-00da9000 rwxp 00003000 fd:00 11028147 /usr/lib/sasl2/libplain.so.2.0.22 06574000-06690000 r-xp 00000000 fd:00 2290134 /lib/libcrypto.so.0.9.8b 06690000-066a2000 rwxp 0011c000 fd:00 2290134 /lib/libcrypto.so.0.9.8b 066a2000-066a6000 rwxp 066a2000 00:00 0 066a8000-066d2000 r-xp 00000000 fd:00 10928450 /usr/lib/libgssapi_krb5.so.2.2 066d2000-066d3000 rwxp 00029000 fd:00 10928450 /usr/lib/libgssapi_krb5.so.2.2 066d5000-06716000 r-xp 00000000 fd:00 2290135 /lib/libssl.so.0.9.8b 06716000-0671a000 rwxp 00040000 fd:00 2290135 /lib/libssl.so.0.9.8b 06aeb000-06af0000 r-xp 00000000 fd:00 2290136 /lib/libcrypt-2.5.so 06af0000-06af1000 r-xp 00004000 fd:00 2290136 /lib/libcrypt-2.5.so 06af1000-06af2000 rwxp 00005000 fd:00 2290136 /lib/libcrypt-2.5.so 06af2000-06b19000 rwxp 06af2000 00:00 0 06dcb000-06de3000 r-xp 00000000 fd:00 10928451 /usr/lib/libsasl2.so.2.0.22 06de3000-06de4000 rwxp 00017000 fd:00 10928451 /usr/lib/libsasl2.so.2.0.22 08048000-0811d000 r-xp 00000000 fd:00 10953555 /usr/local/libexec/slapd 0811d000-08121000 rw-p 000d4000 fd:00 10953555 /usr/local/libexec/slapd 08121000-08124000 rw-p 08121000 00:00 0 08d12000-08e2d000 rw-p 08d12000 00:00 0 a1b00000-a1b21000 rw-p a1b00000 00:00 0 a1b21000-a1c00000 ---p a1b21000 00:00 0 a1c3a000-a1d3b000 rw-p a1c3a000 00:00 0 a1d3b000-a1d3c000 ---p a1d3b000 00:00 0 a1d3c000-a283d000 rw-p a1d3c000 00:00 0 a283d000-a283e000 ---p a283d000 00:00 0 a283e000-a323e000 rw-p a283e000 00:00 0 a323e000-a323f000 ---p a323e000 00:00 0 a323f000-a3c3f000 rw-p a323f000 00:00 0 a3c3f000-a3c45000 rw-s 00000000 fd:00 821479 /usr/local/var/openldap-data/__db.005 a3c45000-a3cb3000 rw-s 00000000 fd:00 821478 /usr/local/var/openldap-data/__db.004 a3cb3000-a3ef3000 rw-s 00000000 fd:00 821477 /usr/local/var/openldap-data/__db.003 a3ef3000-b7ef5000 rw-s 00000000 fd:00 820670 /usr/local/var/openldap-data/__db.002 b7ef5000-b7efa000 rw-p b7ef5000 00:00 0 b7f0e000-b7f12000 rw-s 00000000 fd:00 820669 /usr/local/var/openldap-data/__db.001 b7f12000-b7f13000 rw-p b7f12000 00:00 0 bfe20000-bfe36000 rw-p bfe20000 00:00 0 [stack] Program received signal SIGABRT, Aborted. [Switching to Thread -1569473648 (LWP 4535)] 0x00695402 in __kernel_vsyscall () (gdb) bt #0 0x00695402 in __kernel_vsyscall () #1 0x00ac8d40 in raise () from /lib/libc.so.6 #2 0x00aca591 in abort () from /lib/libc.so.6 #3 0x00afe33b in __libc_message () from /lib/libc.so.6 #4 0x00b0448b in malloc_consolidate () from /lib/libc.so.6 #5 0x00b066f3 in _int_malloc () from /lib/libc.so.6 #6 0x00b07bdd in calloc () from /lib/libc.so.6 #7 0x00afce7d in open_memstream () from /lib/libc.so.6 #8 0x00b69656 in __vsyslog_chk () from /lib/libc.so.6 #9 0x00b69bfa in syslog () from /lib/libc.so.6 #10 0x080687e5 in connection2anonymous () #11 0x08068c9c in connection2anonymous () #12 0x0011b56d in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:478 #13 0x00c133db in start_thread () from /lib/libpthread.so.0 #14 0x00b6d26e in clone () from /lib/libc.so.6 Please let me know what else is needed. 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@suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/
In re23 slapo-rwm should not be used in conjunction with other overlays; there is a number of reports about interoperability issues, and only recently Howard fixed (I should say "reworked") it in HEAD/re24. Can you reproduce the same issue with HEAD? p.
changed notes changed state Open to Feedback
<quote who="Pierangelo Masarati"> > In re23 slapo-rwm should not be used in conjunction with other overlays; > there > is a number of reports about interoperability issues, and only recently > Howard > fixed (I should say "reworked") it in HEAD/re24. Can you reproduce the > same > issue with HEAD? Will do later this week. That's strange though, as I merely followed the slapd-ldap(5) man page: suffixmassage, map, rewrite* These directives are no longer supported by back-ldap; their functionality is now delegated to the rwm overlay. Essentially, add a statement overlay rwm first, and prefix all rewrite/map statements with rwm- to obtain the original behavior. See slapo-rwm(5) for details. Maybe a man page patch is needed to stop others hitting this. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry@suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/
ghenry@suretecsystems.com wrote: > That's strange though, as I merely followed the slapd-ldap(5) man page: Slapo-rwm(5) works just fine by itself; the point is that when it was designed there was no cleanup hook in the callback structure, so it was __permmently replacing__ the original values of request DN and DN-valued attributes instead of __temporarily replace__ them and set the original values back when done. So it interacts poorly with other, more recent overlays. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
ando@sys-net.it wrote: > ghenry@suretecsystems.com wrote: > >> That's strange though, as I merely followed the slapd-ldap(5) man page: > > Slapo-rwm(5) works just fine by itself; the point is that when it was > designed there was no cleanup hook in the callback structure, so it was > __permmently replacing__ the original values of request DN and DN-valued > attributes instead of __temporarily replace__ them and set the original > values back when done. So it interacts poorly with other, more recent > overlays. Given that this particular rwm invocation isn't doing anything, it should be easy enough to just comment it out and see if the problem still occurs. Curious that your opening log says "No dynamic config support for database bdb." Are you sure you have a clean install here? -- -- 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/
<quote who="Howard Chu"> > Gavin Henry wrote: >> <quote who="hyc@symas.com"> > >>> Curious that your opening log says "No dynamic config support for >>> database bdb." Are you sure you have a clean install here? >> >> I thought that was weird to. This was setup on my laptop, no OpenLDAP >> from >> rpm or source ever installed. Fresh 2.3.34 and db-4.2.52 (5 patches). > > Yeah, false alarm. The presence of the rwm overlay taints the entire > stack. Isn't this because translucent doesn't support dynamic config, so disables bdb dynamic config? Everything is now working, with no crashes without rwm. I've not had chance to test HEAD yet. Gavin. > > -- > -- 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/ >
Gavin Henry wrote: > <quote who="Howard Chu"> >> Gavin Henry wrote: >>> <quote who="hyc@symas.com"> >>>> Curious that your opening log says "No dynamic config support for >>>> database bdb." Are you sure you have a clean install here? >>> I thought that was weird to. This was setup on my laptop, no OpenLDAP >>> from >>> rpm or source ever installed. Fresh 2.3.34 and db-4.2.52 (5 patches). >> Yeah, false alarm. The presence of the rwm overlay taints the entire >> stack. > > Isn't this because translucent doesn't support dynamic config, so disables > bdb dynamic config? > > Everything is now working, with no crashes without rwm. > > I've not had chance to test HEAD yet. Translucent does support dynamic config, but rwm doesn't. -- -- 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/
<quote who="Howard Chu"> > Gavin Henry wrote: >> <quote who="Howard Chu"> >>> Gavin Henry wrote: >>>> <quote who="hyc@symas.com"> >>>>> Curious that your opening log says "No dynamic config support for >>>>> database bdb." Are you sure you have a clean install here? >>>> I thought that was weird to. This was setup on my laptop, no OpenLDAP >>>> from >>>> rpm or source ever installed. Fresh 2.3.34 and db-4.2.52 (5 patches). >>> Yeah, false alarm. The presence of the rwm overlay taints the entire >>> stack. >> >> Isn't this because translucent doesn't support dynamic config, so >> disables >> bdb dynamic config? >> >> Everything is now working, with no crashes without rwm. >> >> I've not had chance to test HEAD yet. > > Translucent does support dynamic config, but rwm doesn't. Not in 2.3.34 as I understand it. translucent.c doesn't have and olc* things anyway. > > -- > -- 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/ >
Gavin Henry writes: ><quote who="Pierangelo Masarati"> >> In re23 slapo-rwm should not be used in conjunction with other >> overlays; there is a number of reports about interoperability issues, >> (...) > That's strange though, as I merely followed the slapd-ldap(5) man page: > (...) > Maybe a man page patch is needed to stop others hitting this. I'll insert "OpenLDAP 2.3, rwm should not be used in conjunction with other overlays." in slapo-rwm(5), slapd-ldap(5) and slapd-relay(5) unless someone has a better idea. Or since Pierangelo followed up with "it interacts poorly with other, more recent overlays." should it be "...unless you know what you are doing" in the backend docs and a more detailed instruction in slapo-rwm(5)? -- Regards, Hallvard
<quote who="Hallvard B Furuseth"> > Gavin Henry writes: >><quote who="Pierangelo Masarati"> >>> In re23 slapo-rwm should not be used in conjunction with other >>> overlays; there is a number of reports about interoperability issues, >>> (...) >> That's strange though, as I merely followed the slapd-ldap(5) man page: >> (...) >> Maybe a man page patch is needed to stop others hitting this. > > I'll insert "OpenLDAP 2.3, rwm should not be used in conjunction with > other overlays." in slapo-rwm(5), slapd-ldap(5) and slapd-relay(5) > unless someone has a better idea. > > Or since Pierangelo followed up with > "it interacts poorly with other, more recent overlays." If you stop ^^ here, then you might as well use your first sentence. > should it be "...unless you know what you are doing" in the backend docs > and a more detailed instruction in slapo-rwm(5)? Depends on the time you have I suppose. I presume this isn't the case in 2.4? If so, maybe we should use your first sentence and refer them to 2.4? > > -- > Regards, > Hallvard >
ghenry@suretecsystems.com wrote: > Depends on the time you have I suppose. > > I presume this isn't the case in 2.4? > > If so, maybe we should use your first sentence and refer them to 2.4? Referring people to 2.4 really isn't nice unless we have an actual release to refer them to. Which is another reason we need to get a 2.4 beta out ASAP. Since it looks like no activity has occurred on closing out the remaining devel ITSs perhaps we should just freeze the current tree and roll out 2.4.5 as-is. -- -- 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/
hyc@symas.com writes: > Referring people to 2.4 really isn't nice unless we have an actual > release to refer them to. Which is another reason we need to get a 2.4 > beta out ASAP. Since it looks like no activity has occurred on > closing out the remaining devel ITSs perhaps we should just freeze the > current tree and roll out 2.4.5 as-is. I'm working through some new and a few old issues now, as it happens. But I don't see any reason why that needs to hold up a beta. There's always time for another beta. -- Regards, Hallvard
<quote who="Howard Chu"> > ghenry@suretecsystems.com wrote: > >> Depends on the time you have I suppose. >> >> I presume this isn't the case in 2.4? >> >> If so, maybe we should use your first sentence and refer them to 2.4? > > Referring people to 2.4 really isn't nice unless we have an actual release > to > refer them to. Which is another reason we need to get a 2.4 beta out ASAP. True. Also, when I raised this ticket I wasn't part of the team, so I can take on the man page fix if Hallvard doesn't have time. > Since it looks like no activity has occurred on closing out the remaining > devel > ITSs perhaps we should just freeze the current tree and roll out 2.4.5 > as-is. I think that would peak users interest again too. > -- > -- 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/ >
Gavin Henry writes: > True. Also, when I raised this ticket I wasn't part of the team, so I > can take on the man page fix if Hallvard doesn't have time. I have time, a manpage fix doesn't require testing:-) I'm just unsure what it should say. Pierangelo's latest message kind of implied that it can be used with older overlays but not newer ones. -- Regards, Hallvard
<quote who="Hallvard B Furuseth"> > Gavin Henry writes: >> True. Also, when I raised this ticket I wasn't part of the team, so I >> can take on the man page fix if Hallvard doesn't have time. > > I have time, a manpage fix doesn't require testing:-) I'm just unsure > what it should say. Pierangelo's latest message kind of implied that it > can be used with older overlays but not newer ones. Should we say which ones? > > -- > Regards, > Hallvard >
ghenry@suretecsystems.com writes: >> I have time, a manpage fix doesn't require testing:-) I'm just unsure >> what it should say. Pierangelo's latest message kind of implied that it >> can be used with older overlays but not newer ones. >> Should we say which ones? Well, yes. Shouldn't suddenly tell people they shouldn't be doing what they are doing in cases when it's all right. But I don't know which ones. -- Hallvard
<quote who="Hallvard B Furuseth"> > ghenry@suretecsystems.com writes: >>> I have time, a manpage fix doesn't require testing:-) I'm just unsure >>> what it should say. Pierangelo's latest message kind of implied that >>> it >>> can be used with older overlays but not newer ones. >>> Should we say which ones? > > Well, yes. Shouldn't suddenly tell people they shouldn't be doing what > they are doing in cases when it's all right. But I don't know which > ones. Ping Pierangelo? > > -- > Hallvard >
changed notes
changed notes changed state Feedback to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
slapo-rwm/slapo-translucent slapo-rwm fixed in HEAD/RE24/RE23 slapo-translucent fixed in HEAD/RE24 slapo-translucent will not be fixed in RE23