Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com
masarati(a)aero.polimi.it wrote:
>> With your patch the response control is now decoded correctly and it
>> behaves
>> as expected for all operations except Modify DN Operation:
>> It returns empty value lists for all attributes no matter how deleteoldrdn
>> is
>> set. The DN returned is correct.
>
> I suspect ors_attrsonly is set by mistake. Please try this:
>
> + myop.ors_attrsonly = 0;
With your last patch everything works as expected now. Thanks a lot.
Ciao, Michael.
12 years, 5 months
Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it
> Pierangelo Masarati wrote:
>> On 06/07/2011 12:58 PM, michael(a)stroeder.com wrote:
>>> Any chance this will be fixed?
>>>
>>> It would be very handy for sync processes to get back the entryUUID
>>> generated
>>> by OpenLDAP of a new entry in an AddResponse without having to read the
>>> new
>>> entry once more.
>>
>> If I get things right, what seems to be missing is a
>> LDAP_RES_SEARCH_ENTRY tag
>> right before encoding the search entry, something like
> > [..patch snipped..]
>
> Thanks!
>
> With your patch the response control is now decoded correctly and it
> behaves
> as expected for all operations except Modify DN Operation:
> It returns empty value lists for all attributes no matter how deleteoldrdn
> is
> set. The DN returned is correct.
>
> Here's the trace log from the Python script:
>
> ----------------------------- snip -----------------------------
> *** ldap://localhost:2071/ - SimpleLDAPObject.rename
> (('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2',
> None,
> 0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{})
> => result: 5
> *** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0,
> 0),{})
> => result: (109, [], 5, [('1.3.6.1.1.13.2', 0,
> 'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')])
> resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local
> resp_ctrls[0].entry:
> {'cn': [],
> 'createTimestamp': [],
> 'creatorsName': [],
> 'entryCSN': [],
> 'entryDN': [],
> 'entryUUID': [],
> 'gidNumber': [],
> 'hasSubordinates': [],
> 'homeDirectory': [],
> 'modifiersName': [],
> 'modifyTimestamp': [],
> 'objectClass': [],
> 'structuralObjectClass': [],
> 'subschemaSubentry': [],
> 'uid': [],
> 'uidNumber': []}
> ----------------------------- snip -----------------------------
I suspect ors_attrsonly is set by mistake. Please try this:
--- a/servers/slapd/result.c
+++ b/servers/slapd/result.c
@@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs )
#endif
if ( op->o_res_ber ) {
/* read back control */
- rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name );
+ rc = ber_printf( ber, "t{O{" /*}}*/,
+ LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name );
} else {
rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid,
LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name );
@@ -1744,6 +1745,7 @@ int slap_read_controls(
myop.o_res_ber = ber;
myop.o_callback = NULL;
myop.ors_slimit = 1;
+ myop.ors_attrsonly = 0;
rc = slap_send_search_entry( &myop, rs );
if( rc ) return rc;
12 years, 5 months
Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com
Pierangelo Masarati wrote:
> On 06/07/2011 12:58 PM, michael(a)stroeder.com wrote:
>> Any chance this will be fixed?
>>
>> It would be very handy for sync processes to get back the entryUUID generated
>> by OpenLDAP of a new entry in an AddResponse without having to read the new
>> entry once more.
>
> If I get things right, what seems to be missing is a LDAP_RES_SEARCH_ENTRY tag
> right before encoding the search entry, something like
> [..patch snipped..]
Thanks!
With your patch the response control is now decoded correctly and it behaves
as expected for all operations except Modify DN Operation:
It returns empty value lists for all attributes no matter how deleteoldrdn is
set. The DN returned is correct.
Here's the trace log from the Python script:
----------------------------- snip -----------------------------
*** ldap://localhost:2071/ - SimpleLDAPObject.rename
(('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2', None,
0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{})
=> result: 5
*** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0, 0),{})
=> result: (109, [], 5, [('1.3.6.1.1.13.2', 0,
'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')])
resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local
resp_ctrls[0].entry:
{'cn': [],
'createTimestamp': [],
'creatorsName': [],
'entryCSN': [],
'entryDN': [],
'entryUUID': [],
'gidNumber': [],
'hasSubordinates': [],
'homeDirectory': [],
'modifiersName': [],
'modifyTimestamp': [],
'objectClass': [],
'structuralObjectClass': [],
'subschemaSubentry': [],
'uid': [],
'uidNumber': []}
----------------------------- snip -----------------------------
Ciao, Michael.
12 years, 5 months
Re: (ITS#6878) ppcache segfault with tavl_delete
by hyc＠symas.com
Tyler Gates wrote:
> After applying the patches for ITS #6848 and ITS #6898 I still get crashes.
> Here's the latest:
Looks like a double-free. Can you reproduce this consistently? If so, what are
the steps? can you run slapd under valgrind and reproduce this?
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xae1edb70 (LWP 6121)]
> 0xb76e2430 in __kernel_vsyscall ()
> (gdb)
> (gdb)
> (gdb) bt
> #0 0xb76e2430 in __kernel_vsyscall ()
> #1 0xb71b4651 in *__GI_raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2 0xb71b7a82 in *__GI_abort () at abort.c:92
> #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** glibc
> detected *** %s: %s: 0x%s ***\n") at
> ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, str=0x6
> <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266
> #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value
> optimized out>) at malloc.c:4794
> #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at malloc.c:3738
> #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2
> #8 0xb768acaf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2
> #9 0xb768acf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2
> #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at
> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148
> #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at
> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198
> #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac,
> newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at cache.c:1238
> #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at modify.c:662
> #14 0xb6d52e81 in remove_query_data (op=<value optimized out>,
> query_uuid=<value optimized out>)
> at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829
> #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, arg=0xb955e018) at
> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520
> #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2
> #17 0xb72e996e in start_thread (arg=0xae1edb70) at pthread_create.c:300
> #18 0xb7257a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
> (gdb) continue
> Continuing.
> [Thread 0xaddecb70 (LWP 6122) exited]
> [Thread 0xae1edb70 (LWP 6121) exited]
> [Thread 0xae7f0b70 (LWP 6120) exited]
> [Thread 0xaedf3b70 (LWP 6119) exited]
> [Thread 0xaf2f5b70 (LWP 6118) exited]
> [Thread 0xaf7f7b70 (LWP 6117) exited]
> [Thread 0xafbf8b70 (LWP 6116) exited]
> [Thread 0xafff9b70 (LWP 6115) exited]
> [Thread 0xb04fbb70 (LWP 6114) exited]
> [Thread 0xb08fcb70 (LWP 6113) exited]
> [Thread 0xb582ab70 (LWP 5868) exited]
> [Thread 0xb5320b70 (LWP 5869) exited]
> [Thread 0xb4e1eb70 (LWP 5870) exited]
> [Thread 0xb4a1db70 (LWP 5871) exited]
> [Thread 0xb461cb70 (LWP 5872) exited]
> [Thread 0xb421bb70 (LWP 5873) exited]
> [Thread 0xb5c2bb70 (LWP 5867) exited]
>
> Program terminated with signal SIGABRT, Aborted.
> The program no longer exists.
> (gdb)
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 5 months
(ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com
Full_Name: Paul Rogers
Version: 2.4.23
OS: Solaris 8 / 10
URL:
Submission from: (NULL) (77.245.78.130)
Objective: Compile OpenLDAP with SSL and TLS support against the latest OpenSSL
library that is statically compiled so it is easier to port between secure
systems.
Operating System: Solaris 8 and 10, but could affect others (not tested).
Compiled static libraries additional to the system: OpenSSL 0.9.8r
Issue: When compiling OpenLDAP with openssl support for TLS / SSL, the configure
script doesn't have a logic check to see if RSAglue and rsaref libraries should
be used (now deprecated in OpenSSL) at line 19408.
There are other places in configure where a check is made to see if $need_rsaref
is set to yes. This needs applying to line 19408 also.
Workaround: Manually change configure at line 19408 to LIBS="-lssl -lcrypto
$LIBS" if you need to explicitly compile with OpenSSL TLS / SSL support.
Evidence and command executed (from Solaris 10 but same thing occurred on
Solaris 8 also):
$ CC="/usr/sfw/bin/gcc" LIBS="-lssl -lcrypto -lresolv -lgen -lnsl -lsocket"
LDFLAGS="-L/workingdir/openssl-0.9.8r/build-SOLARIS/usr/local/openssl-0.9.8r/lib
-R/workingdir/openssl-0.9.8r/build-SOLARIS/usr/local/openssl-0.9.8r/lib"
CPPFLAGS="-I/workingdir/openssl-0.9.8r/build-SOLARIS/usr/local/openssl-0.9.8r/include"
./configure --prefix=/workingdir/openldap-2.4.23/build-SOLARIS/usr/local/openldap-2.4.23
--disable-slapd --disable-shared --disable-dynamic --with-tls=openssl
--with-ssl
Configuring OpenLDAP 2.4.23-Release ...
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
...
(other checks)
...
checking struct sockaddr_storage... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for SSL_library_init in -lssl... no
checking for ssl3_accept in -lssl... no
configure: error: Could not locate TLS/SSL package
12 years, 6 months
Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com
After applying the patches for ITS #6848 and ITS #6898 I still get crashes.
Here's the latest:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xae1edb70 (LWP 6121)]
0xb76e2430 in __kernel_vsyscall ()
(gdb)
(gdb)
(gdb) bt
#0 0xb76e2430 in __kernel_vsyscall ()
#1 0xb71b4651 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb71b7a82 in *__GI_abort () at abort.c:92
#3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** glibc
detected *** %s: %s: 0x%s ***\n") at
../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4 0xb71f5591 in malloc_printerr (action=<value optimized out>, str=0x6
<Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266
#5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value
optimized out>) at malloc.c:4794
#6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at malloc.c:3738
#7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2
#8 0xb768acaf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2
#9 0xb768acf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2
#10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at
/tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148
#11 0xb7743efb in attrs_free (a=0xb6dcc06c) at
/tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198
#12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac,
newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at cache.c:1238
#13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at modify.c:662
#14 0xb6d52e81 in remove_query_data (op=<value optimized out>,
query_uuid=<value optimized out>)
at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829
#15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, arg=0xb955e018) at
/tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520
#16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2
#17 0xb72e996e in start_thread (arg=0xae1edb70) at pthread_create.c:300
#18 0xb7257a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) continue
Continuing.
[Thread 0xaddecb70 (LWP 6122) exited]
[Thread 0xae1edb70 (LWP 6121) exited]
[Thread 0xae7f0b70 (LWP 6120) exited]
[Thread 0xaedf3b70 (LWP 6119) exited]
[Thread 0xaf2f5b70 (LWP 6118) exited]
[Thread 0xaf7f7b70 (LWP 6117) exited]
[Thread 0xafbf8b70 (LWP 6116) exited]
[Thread 0xafff9b70 (LWP 6115) exited]
[Thread 0xb04fbb70 (LWP 6114) exited]
[Thread 0xb08fcb70 (LWP 6113) exited]
[Thread 0xb582ab70 (LWP 5868) exited]
[Thread 0xb5320b70 (LWP 5869) exited]
[Thread 0xb4e1eb70 (LWP 5870) exited]
[Thread 0xb4a1db70 (LWP 5871) exited]
[Thread 0xb461cb70 (LWP 5872) exited]
[Thread 0xb421bb70 (LWP 5873) exited]
[Thread 0xb5c2bb70 (LWP 5867) exited]
Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb)
--
Tyler Gates
Systems Administrator
Castle Branch Inc.
910-815-3880 ext 7230
tjgates(a)castlebranch.com
This e-mail message, including any attachments, may contain private,
confidential, and privileged information for the restricted use of the
intended recipient(s). If you are not the intended recipient(s), you
may NOT use, disclose, copy, or disseminate this information. Please
notify the sender by return e-mail of this misdirected correspondence
and destroy all copies of the original message including all attachments.
Your cooperation is appreciated.
12 years, 6 months
Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by masarati＠aero.polimi.it
The problem seems to be that unique_modify() calls unique_search() passing
it an Operation that contains the assertion, which fails within the
search. The failure is propagated back to the modification. The
assertion control should not apply to internal operations performed by the
unique overlay. The solution to me is not straightforward, apart from
explicitly removing the assert control when calling unique_search(). I
understand this solution is by no means general; similar problems may
surface in other overlays and with other controls.
p.
12 years, 6 months
Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by hyc＠symas.com
Tyler Gates wrote:
> Howard,
> Does the most recent patch to ITS #6948 'ITS#6948 partial revert
> of #6837, unnecessary' replace the first patch 'ITS#6948 fix ITS#6837
> patch' ?
No.
> On Sun, Jun 5, 2011 at 10:04 PM, Tyler Gates<tgates81(a)gmail.com> wrote:
>> Thanks Howard, it working perfectly again. This also resolves my other
>> ITS, #6891.
>>
>> On 06/05/2011 04:36 PM, Howard Chu wrote:
>>> tgates81(a)gmail.com wrote:
>>>> Full_Name: Tyler Gates
>>>> Version: 2.4.25
>>>> OS: Ubuntu 10.04 LTS
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (65.184.61.44)
>>>>
>>>>
>>>> I've been fighting with a strange issue related to a backend database
>>>> using a
>>>> pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming
>>>> there was
>>>> just something wrong with my cn=config I decided to start back fresh
>>>> using
>>>> slapd.conf instead.
>>>> Once I got the config working just fine I used slaptest to convert
>>>> the config to
>>>> a new cn=config. Unfortunately when I tried using -F cn=config
>>>> instead of my -f
>>>> slapd.conf, slapd failed with the same old message:
>>>
>>> Looks like this was broken by the patch for ITS#6837. Working on a new
>>> fix.
>>>>
>>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning,
>>>> database 0 (hdb) has no suffix
>>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one:
>>>> starting
>>>> "(unknown)"
>>>> May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix.
>>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one
>>>> (type=hdb,
>>>> suffix="(null)"): bi_db_open failed! (-1)
>>>> May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated
>>>>
>>>>
>>>> The backend database has never required me specify a suffix since it
>>>> is already
>>>> specified in the ldap overlay and when I try to add it in I get slapd
>>>> trying to
>>>> open the database twice which results in the second instance having
>>>> access
>>>> issues thus rendering all of the database inaccessible to queries.
>>>>
>>>> I'm assuming there has been a configuration change in cn=config for this
>>>> particular layout but slaptest has not been updated. Below is a copy
>>>> of the flat
>>>> file I used that worked fine but failed once converted to cn=config
>>>> using
>>>> slaptest -f slapd.conf -F /etc/ldap/slapd.d/
>>>>
>>>> root@directory-proxy:~# grep "^[^#]"
>>>> /etc/ldap/slapd.conf.back_ldap_ppcache
>>>> include /etc/ldap/schema/core.schema
>>>> include /etc/ldap/schema/cosine.schema
>>>> include /etc/ldap/schema/nis.schema
>>>> include /etc/ldap/schema/inetorgperson.schema
>>>> include /etc/ldap/schema/openldap.schema
>>>> include /etc/ldap/schema/sudo.schema
>>>> include /etc/ldap/schema/autofs.schema
>>>> include /etc/ldap/schema/ppolicy.schema
>>>> include /etc/ldap/schema/qmail.schema
>>>> include /etc/ldap/schema/puppet.schema
>>>> pidfile /var/run/slapd/slapd.pid
>>>> argsfile /var/run/slapd/slapd.args
>>>> modulepath /usr/lib/ldap
>>>> moduleload back_ldap
>>>> moduleload back_hdb
>>>> moduleload pcache
>>>> moduleload ppolicy
>>>> TLSCertificateFile /etc/ldap/ssl/slapd.crt
>>>> TLSCertificateKeyFile /etc/ldap/ssl/slapd.key
>>>> TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt
>>>> loglevel -1
>>>> allow bind_anon_dn
>>>> database config
>>>> rootdn cn=admin,cn=config
>>>> rootpw secret
>>>> access to * by
>>>> dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
>>>> manage by * break
>>>> database ldap
>>>> suffix "dc=domain,dc=com"
>>>> rootdn "cn=Manager,dc=domain,dc=com"
>>>> rootpw secret
>>>> uri "ldaps://directory1.domain.com
>>>> ldaps://directory2.domain.com"
>>>> overlay pcache
>>>> proxycache hdb 100000 3 1000 100
>>>> proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory
>>>> loginShell gecos description memberUid uniqueMember objectClass
>>>> proxyAttrset 1 cn automountInformation
>>>> proxyAttrset 2 cn mail
>>>> proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800
>>>> proxyTemplate (&(objectClass=)(uid=)) 0 1800
>>>> proxyTemplate (&(objectClass=)(cn=)) 0 1800
>>>> proxyTemplate (&(objectClass=)) 0 1800
>>>> proxyTemplate (objectClass=) 0 1800
>>>> proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900
>>>> proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900
>>>> proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800
>>>> proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800
>>>> proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600
>>>> proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600
>>>> proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600
>>>> proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200
>>>> directory /var/lib/ldap
>>>> cachesize 1000
>>>> idletimeout 600
>>>> idlcachesize 3000
>>>> index objectClass eq
>>>> index cn,mail,surname,givenname eq,subinitial
>>>> index uidNumber,gidNumber,memberuid,member,uniqueMember eq
>>>> index uid eq,subinitial
>>>> index nisMapName,automountInformation eq
>>>> index userPassword,homeDirectory,loginShell,gecos,description eq
>>>> index pcacheQueryID eq
>>>>
>>>>
>>>
>>>
>>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 6 months
Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com
Howard,
Does the most recent patch to ITS #6948 'ITS#6948 partial revert
of #6837, unnecessary' replace the first patch 'ITS#6948 fix ITS#6837
patch' ?
On Sun, Jun 5, 2011 at 10:04 PM, Tyler Gates <tgates81(a)gmail.com> wrote:
> Thanks Howard, it working perfectly again. This also resolves my other
> ITS, #6891.
>
> On 06/05/2011 04:36 PM, Howard Chu wrote:
>> tgates81(a)gmail.com wrote:
>>> Full_Name: Tyler Gates
>>> Version: 2.4.25
>>> OS: Ubuntu 10.04 LTS
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (65.184.61.44)
>>>
>>>
>>> I've been fighting with a strange issue related to a backend database
>>> using a
>>> pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming
>>> there was
>>> just something wrong with my cn=config I decided to start back fresh
>>> using
>>> slapd.conf instead.
>>> Once I got the config working just fine I used slaptest to convert
>>> the config to
>>> a new cn=config. Unfortunately when I tried using -F cn=config
>>> instead of my -f
>>> slapd.conf, slapd failed with the same old message:
>>
>> Looks like this was broken by the patch for ITS#6837. Working on a new
>> fix.
>>>
>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning,
>>> database 0 (hdb) has no suffix
>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one:
>>> starting
>>> "(unknown)"
>>> May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix.
>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one
>>> (type=hdb,
>>> suffix="(null)"): bi_db_open failed! (-1)
>>> May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated
>>>
>>>
>>> The backend database has never required me specify a suffix since it
>>> is already
>>> specified in the ldap overlay and when I try to add it in I get slapd
>>> trying to
>>> open the database twice which results in the second instance having
>>> access
>>> issues thus rendering all of the database inaccessible to queries.
>>>
>>> I'm assuming there has been a configuration change in cn=config for this
>>> particular layout but slaptest has not been updated. Below is a copy
>>> of the flat
>>> file I used that worked fine but failed once converted to cn=config
>>> using
>>> slaptest -f slapd.conf -F /etc/ldap/slapd.d/
>>>
>>> root@directory-proxy:~# grep "^[^#]"
>>> /etc/ldap/slapd.conf.back_ldap_ppcache
>>> include /etc/ldap/schema/core.schema
>>> include /etc/ldap/schema/cosine.schema
>>> include /etc/ldap/schema/nis.schema
>>> include /etc/ldap/schema/inetorgperson.schema
>>> include /etc/ldap/schema/openldap.schema
>>> include /etc/ldap/schema/sudo.schema
>>> include /etc/ldap/schema/autofs.schema
>>> include /etc/ldap/schema/ppolicy.schema
>>> include /etc/ldap/schema/qmail.schema
>>> include /etc/ldap/schema/puppet.schema
>>> pidfile /var/run/slapd/slapd.pid
>>> argsfile /var/run/slapd/slapd.args
>>> modulepath /usr/lib/ldap
>>> moduleload back_ldap
>>> moduleload back_hdb
>>> moduleload pcache
>>> moduleload ppolicy
>>> TLSCertificateFile /etc/ldap/ssl/slapd.crt
>>> TLSCertificateKeyFile /etc/ldap/ssl/slapd.key
>>> TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt
>>> loglevel -1
>>> allow bind_anon_dn
>>> database config
>>> rootdn cn=admin,cn=config
>>> rootpw secret
>>> access to * by
>>> dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
>>> manage by * break
>>> database ldap
>>> suffix "dc=domain,dc=com"
>>> rootdn "cn=Manager,dc=domain,dc=com"
>>> rootpw secret
>>> uri "ldaps://directory1.domain.com
>>> ldaps://directory2.domain.com"
>>> overlay pcache
>>> proxycache hdb 100000 3 1000 100
>>> proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory
>>> loginShell gecos description memberUid uniqueMember objectClass
>>> proxyAttrset 1 cn automountInformation
>>> proxyAttrset 2 cn mail
>>> proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800
>>> proxyTemplate (&(objectClass=)(uid=)) 0 1800
>>> proxyTemplate (&(objectClass=)(cn=)) 0 1800
>>> proxyTemplate (&(objectClass=)) 0 1800
>>> proxyTemplate (objectClass=) 0 1800
>>> proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900
>>> proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900
>>> proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800
>>> proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800
>>> proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600
>>> proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600
>>> proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600
>>> proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200
>>> directory /var/lib/ldap
>>> cachesize 1000
>>> idletimeout 600
>>> idlcachesize 3000
>>> index objectClass eq
>>> index cn,mail,surname,givenname eq,subinitial
>>> index uidNumber,gidNumber,memberuid,member,uniqueMember eq
>>> index uid eq,subinitial
>>> index nisMapName,automountInformation eq
>>> index userPassword,homeDirectory,loginShell,gecos,description eq
>>> index pcacheQueryID eq
>>>
>>>
>>
>>
>
12 years, 6 months
Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it
On 06/07/2011 12:58 PM, michael(a)stroeder.com wrote:
> Any chance this will be fixed?
>
> It would be very handy for sync processes to get back the entryUUID generated
> by OpenLDAP of a new entry in an AddResponse without having to read the new
> entry once more.
If I get things right, what seems to be missing is a
LDAP_RES_SEARCH_ENTRY tag right before encoding the search entry,
something like
diff --git a/servers/slapd/result.c b/servers/slapd/result.c
index 0803f7f..3a21fb5 100644
--- a/servers/slapd/result.c
+++ b/servers/slapd/result.c
@@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs )
#endif
if ( op->o_res_ber ) {
/* read back control */
- rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name );
+ rc = ber_printf( ber, "t{O{" /*}}*/,
+ LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name );
} else {
rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid,
LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name );
but I'd like to have some feedback.
p.
12 years, 6 months