- openldap-bugs - openldap.org

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 04 Nov '08

04 Nov '08

On 4 Nov 2008, at 09:26, Pierangelo Masarati wrote: > toby(a)inf.ed.ac.uk wrote: >> Hi there, is there any further debugging I could usefully carry >> out for this issue, or does it need someone who understands the >> code a bit better? > > It's not a debugging problem, but rather a design issue. The > current design makes use of the first AVA of the filter to decide > how two filters are compared. In your case, the first component is > common to all filters, so only the first occurrence of a search with > that template can be cached. This fact, to my knowledge, is > undocumented, but there's little to do except redesign this weighing > criterium. As I already pointed out, you need to make the most > significant filter AVA appear first in your filter template. Unless > anyone voluteers for a complete redesign [*] of this portion of > slapo-pcache(5), I take your ITS as a request to document this > aspect of template design. > > p. > > [*] a complete redesign could also get rid of strict ordering of > filter AVAs, allow "static" portions of the filter (something like > (&(objectClass=person)(uid=)) and so) and other relatively > unfriendly aspects of slapo-pcache(5) configuration. The problem with changing the ordering in the template is that it then doesn't match the real lookups that occur and so the entries aren't cached - this is something over which I have no control - e.g. queries generated by 'ls -l', or by somebody logging into the machine, etc, etc. This is why we have the filters this way. e.g. sshing into one of our scientific linux 5.2 hosts generates the following lookups: [sybies]toby: grep 'query template' ~/tmp/pcache-login |cut -d' ' -f13| sort|uniq -c 1 (&(objectClass=)(cn=)) 2 (&(objectClass=)(|(memberUid=)(uniqueMember=))) 28 (&(objectClass=)(uid=)) 5 (&(objectClass=)(uidNumber=)) 26 (&(objectClass=)(uniqueMember=)) [sybies]toby: Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by ando＠sys-net.it 04 Nov '08

04 Nov '08

toby(a)inf.ed.ac.uk wrote: > Hi there, is there any further debugging I could usefully carry out > for this issue, or does it need someone who understands the code a bit > better? It's not a debugging problem, but rather a design issue. The current design makes use of the first AVA of the filter to decide how two filters are compared. In your case, the first component is common to all filters, so only the first occurrence of a search with that template can be cached. This fact, to my knowledge, is undocumented, but there's little to do except redesign this weighing criterium. As I already pointed out, you need to make the most significant filter AVA appear first in your filter template. Unless anyone voluteers for a complete redesign [*] of this portion of slapo-pcache(5), I take your ITS as a request to document this aspect of template design. p. [*] a complete redesign could also get rid of strict ordering of filter AVAs, allow "static" portions of the filter (something like (&(objectClass=person)(uid=)) and so) and other relatively unfriendly aspects of slapo-pcache(5) configuration. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5787) few improvements
by ando＠sys-net.it 04 Nov '08

04 Nov '08

Few improvements here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-cf-2008-11-04.tar.gz> (allow digit substitutions, introduced to avoid collisions). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5789) using IP address in CN with GnuTLS
by leva＠ecentrum.hu 04 Nov '08

04 Nov '08

Full_Name: LÉVAI Dániel Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.131.56.68) I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system. The GnuTLS version is 2.4.2. So I'm having a lot of problems using OpenLDAP with GnuTLS, and I've decided to take another route in troubleshooting; I've recreated my cert/key pair, using my machine's ip address in the CN field. The weirdest thing happened: $ ldapsearch -d 1 -ZZWx '(objectclass=*)' -H ldap://192.168.1.3 ldap_url_parse_ext(ldap://192.168.1.3) ldap_create ldap_url_parse_ext(ldap://192.168.1.3:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.1.3:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x6120a0 msgid 1 wait4msg ld 0x6120a0 msgid 1 (infinite timeout) wait4msg continue ld 0x6120a0 msgid 1 all 1 ** ld 0x6120a0 Connections: * host: 192.168.1.3 port: 389 (default) refcnt: 2 status: Connected last used: Fri Oct 31 22:36:46 2008 ** ld 0x6120a0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x6120a0 request count 1 (abandoned 0) ** ld 0x6120a0 Response Queue: Empty ld 0x6120a0 response count 0 ldap_chkResponseList ld 0x6120a0 msgid 1 all 1 ldap_chkResponseList returns ld 0x6120a0 NULL ldap_int_select read1msg: ld 0x6120a0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x6120a0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120a0 0 new referrals read1msg: mark request completed, ld 0x6120a0 msgid 1 request done: ld 0x6120a0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: hostname (192.168.1.3) does not match common name in certificate (192.168.1.3). ldap_err2string ldap_start_tls: Connect error (-11) So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that? And please allow me include some additional information, which was told me by Philip Guenther on openldap-software@: "It appears the routine used with GNUtls refuses to match IP addresses against a CN subjects component, thus explaining that weird message. (In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname doesn't look like an IPv6 or IPv4 address, while the subject CN test needs 'len1' to be the same as the length of the CN value.)" Daniel

1 0

Re: (ITS#5701) connection.c asserting during test008
by hyc＠symas.com 03 Nov '08

03 Nov '08

ando(a)sys-net.it wrote: > richton(a)nbcs.rutgers.edu wrote: > >> Rare connection.c assertion during test008s of RE24. Here are three different >> examples: > >> [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn >> = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" > > >> [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = >> 0x1005c1b98), line 187 in "rww.c" > >> [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = >> 0x1005c1b98), line 185 in "rww.c" > > > Sorry, I overlooked the fact that all those issues are occurring from > within back-monitor. In all cases, it's within code that loops through > the connection array using connection_{first,next,close}(). Apparently, > those calls are used in the right way. Can you print more information > about those connections? E.g. c->c_struct_state, and *index from within > connection_next()? Or even better, the whole *c structure? Looks like it may be related to #5586. -- -- Howard Chu CTO, 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#5749) client didn't send its own certificate to the server
by hyc＠symas.com 03 Nov '08

03 Nov '08

bugs(a)shiva.hostoffice.hu wrote: > Full_Name: Gabor Mayer > Version: 2.4.11 > OS: debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.120.131.147) > > > i discovered it when i turned on the peer verification at server side. > > i'm using the following configuration at client side: > > ldap.conf: > > BASE dc=example,dc=org > URI ldaps://ldap.example.org > > TLS_CACERT /etc/ldap/server.crt > > /root/.ldaprc: > > TLS_CERT /etc/ldap/client.crt > TLS_KEY /etc/ldap/client.key > > i tried TLS_CERT& TLS_KEY in ldap.conf and in .ldaprc without success. > > i tested it with ldapsearch -x and i got the following debug message at server > if the TLSVerifyClient was turned on: > > TLS trace: SSL3 alert write:fatal:handshake failure > TLS trace: SSL_accept:error in SSLv3 read client certificate B > TLS: can't accept. > TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return > a certificate s3_srvr.c:2455 > > i captured the tcp flow at client side and i saw the server's certificate only. > the client didn't send its own certificate to the server! Works for me on Ubuntu 8.10 using GNUtls 2.4.1. I suggest you contact the Debian folks about this. This ITS will be closed. -- -- Howard Chu CTO, 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#5739) "host:port" does not work
by h.b.furuseth＠usit.uio.no 03 Nov '08

03 Nov '08

hyc(a)symas.com writes: > OpenLDAP has been this way since at least 2003, no one else has > cared since then... No, it works with 2.3.43. And "LDAPHOST=ldap:3890 ldapwhoami -x" still works in HEAD. It's ldap_url_desc2str() in libraries/libldap/url.c which changed to assume IPv6 if strchr( u->lud_host, ':' ). -- Hallvard

1 0

Re: (ITS#5739) "host:port" does not work
by hyc＠symas.com 03 Nov '08

03 Nov '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Why are you reporting this? "-h" has always been documented to only >> accept a hostname, > > No. Look at man ldap_init: > (...) each host may optionally by of the form host:port. If > present, the :port overrides the port parameter (...) > > So sometimes this option is called hostport. > > It's been that way since umich ldap 3.2. > Perhaps so, but... clients/tools/common.c: 1.1 (hallvard 12-Dec-02): if( ( ldaphost != NULL || ldapport ) && ( ldapuri == NULL ) ) { 1.26 (kurt 14-Dec-03): /* construct URL */ 1.26 (kurt 14-Dec-03): LDAPURLDesc url; 1.26 (kurt 14-Dec-03): memset( &url, 0, sizeof(url)); 1.26 (kurt 14-Dec-03): 1.26 (kurt 14-Dec-03): url.lud_scheme = "ldap"; 1.26 (kurt 14-Dec-03): url.lud_host = ldaphost; 1.26 (kurt 14-Dec-03): url.lud_port = ldapport; 1.26 (kurt 14-Dec-03): url.lud_scope = LDAP_SCOPE_DEFAULT; 1.26 (kurt 14-Dec-03): 1.26 (kurt 14-Dec-03): ldapuri = ldap_url_desc2str( &url ); OpenLDAP has been this way since at least 2003, no one else has cared since then... -- -- Howard Chu CTO, 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#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 03 Nov '08

03 Nov '08

OK, thank you. I didn't see this configuration directive in the admin guide... > # need to inform slapd that this DB is subordinate > subordinate

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by hyc＠symas.com 03 Nov '08

03 Nov '08

Guillaume Rousse wrote: > Howard Chu a écrit : >> How did you create this situation? I can't test a fix without some way >> to break the DB in the first place, and generally the DB doesn't fail... > I just upgraded to 2.4.12, as described at > http://www.openldap.org/lists/openldap-software/200810/msg00087.html. OK, fixed now in HEAD. -- -- Howard Chu CTO, 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#5788) Search does not work with nested naming contexts
by ando＠sys-net.it 03 Nov '08

03 Nov '08

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.4.11 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.78.0.137) > > > I want to run a directory server with a "c=fr" suffix, and a replicated subtree: > "ou=test,o=myorg,c=fr". > To do this, I define two bdb databases, the first one with a > "ou=test,o=myorg,c=fr" suffix, the second one with a "c=fr" suffix. > But when I perform a search, the entries from the first base are not returned. > For example, search with base "o=myorg,c=fr" and scope one level returns > "ou=test2,o=myorg,c=fr" but not "ou=test,o=myorg,c=fr" whereas search with base > "ou=test,o=myorg,c=fr" returns the entry. > If this is a configuration problem, please tell me what is wrong. > > Here follows my slapd.conf file: > > include schema/core.schema > include schema/cosine.schema > include schema/inetorgperson.schema > pidfile slapd.pid > argsfile slapd.args > access to * attrs=userPassword > by self write > by anonymous auth > by * none > access to * > by self write > by users read > by anonymous read > by * none > database bdb > suffix "ou=test,o=myorg,c=fr" # need to inform slapd that this DB is subordinate subordinate > rootdn "cn=manager,c=fr" > updatedn "cn=replicator,ou=test,o=myorg,c=fr" > cachesize 20000 > checkpoint 10000 10 > directory db1 > index objectClass,entryCSN,entryUUID eq > index cn,sn eq,sub > database bdb > suffix "c=fr" > rootdn "cn=manager,c=fr" > rootpw {SSHA}IcRbIFvDVZ9j6g8hWK9bbgo7xhSrMMTf > cachesize 20000 > checkpoint 10000 10 > directory db2 > index objectClass,entryCSN,entryUUID eq > index cn,sn eq,sub > > p.

1 0

(ITS#5788) Search does not work with nested naming contexts
by emmanuel.duru＠atosorigin.com 03 Nov '08

03 Nov '08

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.78.0.137) I want to run a directory server with a "c=fr" suffix, and a replicated subtree: "ou=test,o=myorg,c=fr". To do this, I define two bdb databases, the first one with a "ou=test,o=myorg,c=fr" suffix, the second one with a "c=fr" suffix. But when I perform a search, the entries from the first base are not returned. For example, search with base "o=myorg,c=fr" and scope one level returns "ou=test2,o=myorg,c=fr" but not "ou=test,o=myorg,c=fr" whereas search with base "ou=test,o=myorg,c=fr" returns the entry. If this is a configuration problem, please tell me what is wrong. Here follows my slapd.conf file: include schema/core.schema include schema/cosine.schema include schema/inetorgperson.schema pidfile slapd.pid argsfile slapd.args access to * attrs=userPassword by self write by anonymous auth by * none access to * by self write by users read by anonymous read by * none database bdb suffix "ou=test,o=myorg,c=fr" rootdn "cn=manager,c=fr" updatedn "cn=replicator,ou=test,o=myorg,c=fr" cachesize 20000 checkpoint 10000 10 directory db1 index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub database bdb suffix "c=fr" rootdn "cn=manager,c=fr" rootpw {SSHA}IcRbIFvDVZ9j6g8hWK9bbgo7xhSrMMTf cachesize 20000 checkpoint 10000 10 directory db2 index objectClass,entryCSN,entryUUID eq index cn,sn eq,sub

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 03 Nov '08

03 Nov '08

Hi there, is there any further debugging I could usefully carry out for this issue, or does it need someone who understands the code a bit better? Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5745) slapcat doesn't return correct error status for bdb fatal error
by Guillaume.Rousse＠inria.fr 03 Nov '08

03 Nov '08

Howard Chu a écrit : > Guillaume.Rousse(a)inria.fr wrote: >> Full_Name: Guillaume Rousse >> Version: 2.4.12 >> OS: >> URL: >> Submission from: (NULL) (193.55.250.67) >> >> >> [root@etoile ~]# slapcat -b dc=msr-inria,dc=inria,dc=fr >> ... >> bdb(dc=msr-inria,dc=inria,dc=fr): pthread lock failed: Invalid argument >> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: Invalid argument >> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: DB_RUNRECOVERY: Fatal error, run >> database recovery >> bdb(dc=msr-inria,dc=inria,dc=fr): PANIC: fatal region error detected; run >> recovery >> bdb_db_close: database "dc=msr-inria,dc=inria,dc=fr": close failed: >> DB_RUNRECOVERY: Fatal error, run database recovery (-30975) >> [root@etoile ~]# echo $? >> 0 >> >> It makes a bit difficult to know if slapcat-based backup were successful. > > How did you create this situation? I can't test a fix without some way > to break the DB in the first place, and generally the DB doesn't fail... I just upgraded to 2.4.12, as described at http://www.openldap.org/lists/openldap-software/200810/msg00087.html. -- Guillaume Rousse Service des Moyens Informatiques INRIA Saclay - Ile de France Tel: 01 69 35 69 62

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 02 Nov '08

02 Nov '08

Ali Pouya wrote: > Howard Chu a écrit : >> The startup scan is only performed inside the syncprov overlay. If >> server C is only a consumer, then it does not need the syncprov overlay. >> > Yes, you are right for the point 1). Thank you. > > But I'm also bothered with the point 2) reproduced below : > > .... > 2) If I do only one write operation on B, then I get two contextCSN values, > which is normal. > > But il this case slapd on B scans, at each startup, all objecs written on A > after the write operation on B. > The log and the effect are similar to those explained above. I see. This has been fixed for back-bdb/hdb in HEAD. If the database was shut down cleanly before, there will be no scan on the next startup. -- -- Howard Chu CTO, 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#5786) too many arguments to function slap_get_commit_csn
by hyc＠symas.com 02 Nov '08

02 Nov '08

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.100.88) > > > HEAD synced, invoked configure after make distclean > > cd overlays; make -w static > make[3]: Entering directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' > gcc -g -O4 -I../../../include -I../../../include -I.. -I./.. > -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -c -o > syncprov.o syncprov.c > syncprov.c: In function syncprov_op_response: > syncprov.c:1612: error: too many arguments to function slap_get_commit_csn > syncprov.c:1621: error: too many arguments to function slap_get_commit_csn > make[3]: *** [syncprov.o] Error 1 > make[3]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' > make[2]: *** [liboverlays.a] Error 2 > make[2]: Leaving directory > `/usr/src/michael/openldap/HEAD/openldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers' > make: *** [all-common] Error 1 Incomplete commit. Fixed now. -- -- Howard Chu CTO, 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#5787) Implement support for "Codice Fiscale" syntax
by ando＠sys-net.it 02 Nov '08

02 Nov '08

Further info is available here: <http://www.openldap.org/faq/data/cache/1471.html> p.

1 0

(ITS#5787) Implement support for "Codice Fiscale" syntax
by ando＠sys-net.it 02 Nov '08

02 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/cf.tar.gz Submission from: (NULL) (81.72.89.40) Submitted by: ando This module registers the "Codice Fiscale" syntax, derived from directoryString, and makes it compatible with the caseExactMatch matchingRule. It also defines a "codiceFiscale" attribute and the "codiceFiscaleBase" and "codiceFiscaleObject" objectClasses. I believe this software and these schema items will probably be mainly useful to Italian users and developers of OpenLDAP software. This software has been developed by myself, based on publicly available information. It is released under the OpenLDAP license for use with OpenLDAP software. p.

1 0

Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 02 Nov '08

02 Nov '08

See also <http://www.openldap.org/lists/openldap-devel/200811/msg00000.html> and specifically <http://www.openldap.org/lists/openldap-devel/200811/msg00006.html> dontUseCopy needs to be fixed, but specific "disallow" flags could be added to alter per-RFC4511 behavior. p.

1 0

(ITS#5786) too many arguments to function slap_get_commit_csn
by michael＠stroeder.com 02 Nov '08

02 Nov '08

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.100.88) HEAD synced, invoked configure after make distclean cd overlays; make -w static make[3]: Entering directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' gcc -g -O4 -I../../../include -I../../../include -I.. -I./.. -I/usr/include -I/usr/include -I/usr/include -I/usr/include -DDEVEL -c -o syncprov.o syncprov.c syncprov.c: In function syncprov_op_response: syncprov.c:1612: error: too many arguments to function slap_get_commit_csn syncprov.c:1621: error: too many arguments to function slap_get_commit_csn make[3]: *** [syncprov.o] Error 1 make[3]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd/overlays' make[2]: *** [liboverlays.a] Error 2 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 02 Nov '08

02 Nov '08

michael(a)stroeder.com wrote: > ando(a)sys-net.it wrote: >> The "dontUseCopy" control requires criticality to be TRUE. While this is the >> desirable value, > > Why is this a desirable value? The answer Kurt gave on ldap-ext mailing > list just mentioned direct mapping to X.511 dontUseCopy option. Because. If you need to avoid using copy, then you strongly need it. If it's just a wish, then don't use it, assuming the DSA you contact will do no more than what it can to provide you valid data. You would otherwise be misuing the control. >> a DUA could use the control with the criticality set to FALSE. Yes, perfectly legitimate (from a DSA's point of view, as per RFC4511) but contrary to the control's specification (and, IMHO, to common sense). > As I stated on ldap-ext mailing list in this case I'd simply accept a > best effort on the DSA side. IMHO you already get the best effort by not using the control. > So sending "dontUseCopy" control with > criticality FALSE would mean: If the DSA supports this control it should > *process* it according to what's specified in > draft-zeilenga-ldap-dontusecopy. Otherwise ignore it. No. The spec looks broken to me, because it contradicts RFC4511 (from the DSA's point of view). The DUA must use TRUE to comply with dontUseCopy. If it doesn't, then the DSA can do its best to honor it, but nothing more. If the DSA finds out it can chain a request, but this would cost resources, it could return a referral, or simply ignore the control. All of these behaviors would comply with criticality to FALSE. > The main problem is that a DUA cannot determine in advance whether a DSA > supports a certain control for a certain backend. It turned out in > practice that looking a supportedControl in rootDSE does not have any > meaning at all. You got a clear answer: the only ultimate way to know is to try. If you use FALSE, you'll never know. > IMO yet another control does not solve this. It does: you add dontUseCopy with criticality set to TRUE; you add the whatFailed control; if dontUseCopy fails, you'd know for sure. Then you don't need to use it any more, as using it with FALSE would make no sense. >> For full conformance with RFC4511, if the control is syntactically well-formed >> and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST >> ignore it if not recognized, but CANNOT question the fact that the value of >> criticality is violating the control's specification. > > I'm not sure whether this statement can be made generally. I'd wish so > and I'd rephrase "accept it" to "process it". With "accept" I mean: "recognize it"; with "process" I'd mean "apply it to the operation". If you set criticality to FALSE and the DSA does not recognize it, the DSA will just ignore it. If the DSA recognizes it, it is at the DSA's discretion to either apply it or not, based on what the DSA considers best (including interoperability with the specific operation, with other extensions, with resource consumption and any other consideration about the opportunity to process it). I'm pretty sure you agree that elaving so much discretion to the DSA about something related to data integrity does not differ too much from not using the control at all. p.

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 02 Nov '08

02 Nov '08

Howard Chu a écrit : > > The startup scan is only performed inside the syncprov overlay. If > server C is only a consumer, then it does not need the syncprov overlay. > Yes, you are right for the point 1). Thank you. But I'm also bothered with the point 2) reproduced below : .... 2) If I do only one write operation on B, then I get two contextCSN values, which is normal. But il this case slapd on B scans, at each startup, all objecs written on A after the write operation on B. The log and the effect are similar to those explained above. Best Regards Ali

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by hyc＠symas.com 02 Nov '08

02 Nov '08

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.11 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > I have a test directory with two mirrors A and B and a replica C connected to > A. > I usaually use server A for write operations. > > I encounter the following problems : > > > 1) If the data base is initiated in stand alone (so serverID defaults to zero) > and then I set serverIDs 1 and 2 for A and B then each time I start up slapd on > C it scans all of the objects writtent on A afterwards, producing the followin > log for each object : The startup scan is only performed inside the syncprov overlay. If server C is only a consumer, then it does not need the syncprov overlay. -- -- Howard Chu CTO, 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#5709) slapd sync provider skips some objects
by hyc＠symas.com 02 Nov '08

02 Nov '08

hyc(a)symas.com wrote: > sylvain.thomas(a)gmail.com wrote: >> On 10/30/08, Gavin Henry<ghenry(a)openldap.org> wrote: >>> Can you upload these zip attachments to our ftp server or somewhere else >>> with online >>> access please. Then we can test. >>> >> I have uploaded the two files to your ftp server (incoming folder). > > I can confirm that the problem is easily reproducable. Fixed now in HEAD. A couple of bad assumptions from 1.234-1.236... -- -- Howard Chu CTO, 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#5785) dontUseCopy in slapd requires criticality to be TRUE
by michael＠stroeder.com 01 Nov '08

01 Nov '08

ando(a)sys-net.it wrote: > > The "dontUseCopy" control requires criticality to be TRUE. While this is the > desirable value, Why is this a desirable value? The answer Kurt gave on ldap-ext mailing list just mentioned direct mapping to X.511 dontUseCopy option. > a DUA could use the control with the criticality set to FALSE. As I stated on ldap-ext mailing list in this case I'd simply accept a best effort on the DSA side. So sending "dontUseCopy" control with criticality FALSE would mean: If the DSA supports this control it should *process* it according to what's specified in draft-zeilenga-ldap-dontusecopy. Otherwise ignore it. The main problem is that a DUA cannot determine in advance whether a DSA supports a certain control for a certain backend. It turned out in practice that looking a supportedControl in rootDSE does not have any meaning at all. IMO yet another control does not solve this. > For full conformance with RFC4511, if the control is syntactically well-formed > and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST > ignore it if not recognized, but CANNOT question the fact that the value of > criticality is violating the control's specification. I'm not sure whether this statement can be made generally. I'd wish so and I'd rephrase "accept it" to "process it". Ciao, Michael.

1 0

(ITS#5785) dontUseCopy in slapd requires criticality to be TRUE
by ando＠sys-net.it 01 Nov '08

01 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The "dontUseCopy" control requires criticality to be TRUE. While this is the desirable value, a DUA could use the control with the criticality set to FALSE. For full conformance with RFC4511, if the control is syntactically well-formed and criticality is set to FALSE, slapd MUST accept it if recognized, or MUST ignore it if not recognized, but CANNOT question the fact that the value of criticality is violating the control's specification. p. PS: other controls with similar requirements for the DUA accept any value for criticality (e.g. RFC4370).

1 0

(ITS#5784) [enhancement] add support for "What Failed?" LDAP control
by ando＠sys-net.it 01 Nov '08

01 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando I'm about to add support for what I termed the "What Failed?" LDAP control, which allows to request detailed information about what extension caused the failure of a request. The commit includes a preliminary version of what I intend to submit as an I.D. shortly. p.

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by hyc＠symas.com 31 Oct '08

31 Oct '08

sylvain.thomas(a)gmail.com wrote: > On 10/30/08, Gavin Henry<ghenry(a)openldap.org> wrote: >> Can you upload these zip attachments to our ftp server or somewhere else >> with online >> access please. Then we can test. >> > > I have uploaded the two files to your ftp server (incoming folder). I can confirm that the problem is easily reproducable. Adding a debug message here diff -u -r1.248 syncprov.c --- syncprov.c 17 Oct 2008 15:40:49 -0000 1.248 +++ syncprov.c 31 Oct 2008 21:06:56 -0000 @@ -1638,6 +1638,7 @@ si->si_sids[i] = sid; } } else { + Debug( LDAP_DEBUG_SYNC, "Empty maxcsn for %s\n", op->o_req_dn.bv_val, 0, 0 ); /* internal ops that aren't meant to be replicated */ ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); return SLAP_CB_CONTINUE; shows that some of the missing entries are caused by this situation, but not necessarily all. Still investigating. -- -- Howard Chu CTO, 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#5781) syncrepl doing delete/add on items without equality
by rubin＠physics.umn.edu 31 Oct '08

31 Oct '08

Patched in servers/slapd/syncrepl.c rev 1.418 http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/syncrepl.c.diff?r1=1… I applied the patch to 2.4.11 and verified it does solve the problem. Thanks!

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 31 Oct '08

31 Oct '08

On 10/30/08, Gavin Henry <ghenry(a)openldap.org> wrote: > Can you upload these zip attachments to our ftp server or somewhere else > with online > access please. Then we can test. > >> I have uploaded the two files to your ftp server (incoming folder). Best regards Sylvain Thomas

1 0

(ITS#5783) Possible DB corruption
by moya＠latertulia.org 31 Oct '08

31 Oct '08

Full_Name: Maykel Moya Version: 2.4.11 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.55.135.211) It's second time that I have bitten by this: Oct 31 07:49:24 swage slapd[4308]: PROXIED attributeDescription "DC" inserted. After that I'm unable to bind against the DSA. The problem has arise in two independent systems. Steps to reproduce: 1. Create a minor db (like Debian does), a dc=foo,dc=org node and a cn=admin,rootdn node 2. Migrate to cn=config 3. Edit cn=config I've added olcTLSCACertificateFile / olcTLSCertificateFile / olcTLSCertificateKeyFiel attributes 4. Restart the server After restarting I see the PROXIED error. I'd wrote to the list before [1][2] but the same thing has come in another system. Regards, maykel [1] http://www.openldap.org/lists/openldap-software/200808/msg00170.html [2] http://www.openldap.org/lists/openldap-software/200808/msg00170.html

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 31 Oct '08

31 Oct '08

------=_Part_29321_8395269.1225438991374 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline it would appear attribute lists containing * (all not operational attributes) and + (all operational attributes), are being dropped by "rwm-map attribute *" or they are not being expanded to attributes first, for whatever reason. the ldapsearch <blah blah> "(objectclass=*)" cn * + works without "rwm-map attrubute *", but stops working with "rwm-map attribute *" put back also, if you explicitly request attributes, you will get them, with our without "rwm-map attribute *" ie: ldapsearch <blah blah> "(objectclass=*)" cn sn entryUUID returns attrubutes which are allowed, but not showing via * and/or + ------=_Part_29321_8395269.1225438991374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline it would appear attribute lists containing * (all not operational attributes) and + (all operational attributes), are being dropped by "rwm-map attribute *" or they are not being expanded to attributes first, for whatever reason. the ldapsearch <blah blah> "(objectclass=*)" cn * + works without "rwm-map attrubute *", but stops working with "rwm-map attribute *" put back also, if you explicitly request attributes, you will get them, with our without "rwm-map attribute *" ie: ldapsearch <blah blah> "(objectclass=*)" cn sn entryUUID returns attrubutes which are allowed, but not showing via * and/or + ------=_Part_29321_8395269.1225438991374--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 31 Oct '08

31 Oct '08

------=_Part_28816_12585104.1225436998930 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline trying some different things with the last release. very interesting that rwm-map works with operational attributes, i can see hasSubordinates, subschemaSubentry, entryUUID but not the other non-operational attributes such as cn, sn, etc., do not show.. # these dont rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # these work rwm-map attribute hasSubordinates * rwm-map attribute subschemaSubentry * rwm-map attribute entryUUID * # this enabled rwm-map attribute * On Tue, Oct 21, 2008 at 3:55 PM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > Not clear what the problem is, now. The above configuration seems to work > as intended as far as attribute mapping is concerned. The fact that > "rwm-map objectclass *" no longer kills the objectClass attribuet was fixed > some time ago (the fix is in 2.4.12). What kills the allowed objectClass > values is a bug in evaluating what values are preserved. If you don't put > any "rwm-map objectclass" rule, it works as expected. > > I'm fixing this other bug. > > ------=_Part_28816_12585104.1225436998930 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline trying some different things with the last release. very interesting that rwm-map works with operational attributes, i can see hasSubordinates, subschemaSubentry, entryUUID but not the other non-operational attributes such as cn, sn, etc., do not show.. # these dont<div class="Ih2E3d"> rwm-map attribute cn * rwm-map attribute sn * </div>rwm-map attribute givenName *<div class="Ih2E3d"> rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * </div># these work rwm-map attribute hasSubordinates * rwm-map attribute subschemaSubentry * rwm-map attribute entryUUID * # this enabled rwm-map attribute * <div class="gmail_quote">On Tue, Oct 21, 2008 at 3:55 PM, Pierangelo Masarati <<a href="mailto:ando@sys-net.it">ando(a)sys-net.it</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Not clear what the problem is, now.  The above configuration seems to work as intended as far as attribute mapping is concerned.  The fact that "rwm-map objectclass *" no longer kills the objectClass attribuet was fixed some time ago (the fix is in 2.4.12).  What kills the allowed objectClass values is a bug in evaluating what values are preserved.  If you don't put any "rwm-map objectclass" rule, it works as expected. I'm fixing this other bug. </blockquote></div> ------=_Part_28816_12585104.1225436998930--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 31 Oct '08

31 Oct '08

[please reply to the ITS] Brett @Google wrote: > trying some different things with the last release. > > very interesting that rwm-map works with operational attributes, i can see > hasSubordinates, subschemaSubentry, entryUUID but not the other > non-operational attributes. Odd. > > # these dont > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute givenName * > rwm-map attribute mail * > rwm-map attribute c * > rwm-map attribute o * > rwm-map attribute ou * > > # these work > rwm-map attribute hasSubordinates * > rwm-map attribute subschemaSubentry * > rwm-map attribute entryUUID * > > # this enabled > rwm-map attribute * Some operational attrs are generated and not stored in the entry (hasSubordinates, entryDN, subschemaSubentry, ...). As a consequence, they are not yet present in the entry when overlays see it during response. slapo-rwm(5), in the operational() hook, could muck with generated operational attrs. Currently, it remaps names, but does not consider removing disallowed attributes, AFAIR. I do not favor mucking too much with operational attrs, as they are... operational. I agree about the opportunity to rewrite the entryDN in order to support virtual views (what slapo-rwm(5) should actually do is replace any occurrence of entryDN in a SearchResultEntry with the entry's DN, if it differs), but probably we should disallow, for example, rewriting of creatorsName and modifiersName. If there is anywhing you want to hide to clients, you should rather use ACLs. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5778) slapd crashes while adding multipe attributes
by ando＠sys-net.it 31 Oct '08

31 Oct '08

snowyurik(a)gmail.com wrote: > ------=_Part_36644_12214634.1225420991107 > Content-Type: text/plain; charset=KOI8-R > Content-Transfer-Encoding: base64 > Content-Disposition: inline > > SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiksIGlm > IGkgdXNlIGJzZC1tYWtlIGZvcgpidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1dCBn > b2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksCmluIGNhc2UgaSB1c2UgZ251 > LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC4KCkluIGJvdGggc2l0dWF0aW9uLCBp > IGdldCBubyBlcnJvcnMuCgpNYXliZSBJIGRvIHNvbWV0aGluZyB3cm9uZywgYnV0IGkgc2hvdWxk > IGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcwpjYXNlLCBpc24ndCBpdD8KMjAwOC8xMC8z > MCBQaWVyYW5nZWxvIE1hc2FyYXRpIDxhbmRvQHN5cy1uZXQuaXQ+Cgo+IODSycog78jPzsnOIHdy > b3RlOgo+Cj4+IFNvcnJ5Lgo+Pgo+PiBUaGlzIGlzIGJlY2F1c2Ugb2YgRnJlZUJTRCBwb3J0cyBj > b2xsZWN0aW9uLiBJJ2xsIHRyeSB0byBpbnN0YWxsIHRoZQo+PiBsYXRlc3QKPj4gcmVsZWFzZS4g > V2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vlaywg > YW5kIHRlbGwKPj4gaWYgdGhlIHByb2JsZW0gZXhpc3Q/Cj4+Cj4KPiBBcyB5b3UgbGlrZS4gICBC > dXQgcGxlYXNlIHJlcGx5IHRvIDxvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPiwgbm90IHRvIG15 > Cj4gcGVyc29uYWwgYWRkcmVzcy4KPgo+IHAuCj4KPgo+IEluZy4gUGllcmFuZ2VsbyBNYXNhcmF0 > aQo+IE9wZW5MREFQIENvcmUgVGVhbQo+Cj4gU3lzTmV0IHMuci5sLgo+IHZpYSBEb3NzaSwgOCAt > IDI3MTAwIFBhdmlhIC0gSVRBTElBCj4gaHR0cDovL3d3dy5zeXMtbmV0Lml0Cj4gLS0tLS0tLS0t > LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBPZmZpY2U6ICArMzkgMDIgMjM5OTgzMDkKPiBN > b2JpbGU6ICArMzkgMzMzIDQ5NjMxNzIKPiBGYXg6ICAgICArMzkgMDM4MiA0NzY0OTcKPiBFbWFp > bDogICBhbmRvQHN5cy1uZXQuaXQKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t > LQo+Cj4K > ------=_Part_36644_12214634.1225420991107 > Content-Type: text/html; charset=KOI8-R > Content-Transfer-Encoding: base64 > Content-Disposition: inline > > PHA+SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiks > IGlmIGkgdXNlIGJzZC1tYWtlIGZvciBidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1 > dCBnb2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksIGluIGNhc2UgaSB1c2Ug > Z251LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC48L3A+PHA+SW4gYm90aCBzaXR1 > YXRpb24sIGkgZ2V0IG5vIGVycm9ycy48L3A+Cgo8cD5NYXliZSBJIGRvIHNvbWV0aGluZyB3cm9u > ZywgYnV0IGkgc2hvdWxkIGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcyBjYXNlLCBpc24m > IzM5O3QgaXQ/PC9wPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA4LzEwLzMwIFBpZXJhbmdl > bG8gTWFzYXJhdGkgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86YW5kb0BzeXMt > bmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0Lml0PC9hPiZndDs8L3NwYW4+PGJy > PgoKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 > ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdj7g0snK > IO/Iz87JziB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 > Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm > dDoxZXgiPgpTb3JyeS48YnI+Cjxicj4KVGhpcyBpcyBiZWNhdXNlIG9mIEZyZWVCU0QgcG9ydHMg > Y29sbGVjdGlvbi4gSSYjMzk7bGwgdHJ5IHRvIGluc3RhbGwgdGhlIGxhdGVzdDxicj4KcmVsZWFz > ZS4gV2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vl > aywgYW5kIHRlbGw8YnI+CmlmIHRoZSBwcm9ibGVtIGV4aXN0Pzxicj4KPC9ibG9ja3F1b3RlPgo8 > YnI+PC9kaXY+CkFzIHlvdSBsaWtlLiAmbmJzcDsgQnV0IHBsZWFzZSByZXBseSB0byAmbHQ7PGEg > aHJlZj0ibWFpbHRvOm9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmciIHRhcmdldD0iX2JsYW5rIj5v > cGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPC9hPiZndDssIG5vdCB0byBteSBwZXJzb25hbCBhZGRy > ZXNzLjxkaXY+PGRpdj48YnI+Cjxicj4KcC48YnI+Cjxicj4KPGJyPgpJbmcuIFBpZXJhbmdlbG8g > TWFzYXJhdGk8YnI+Ck9wZW5MREFQIENvcmUgVGVhbTxicj4KPGJyPgpTeXNOZXQgcy5yLmwuPGJy > Pgp2aWEgRG9zc2ksIDggLSAyNzEwMCBQYXZpYSAtIElUQUxJQTxicj4KPGEgaHJlZj0iaHR0cDov > L3d3dy5zeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5zeXMtbmV0Lml0PC9h > Pjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Ck9mZmljZTogJm5i > c3A7KzM5IDAyIDIzOTk4MzA5PGJyPgpNb2JpbGU6ICZuYnNwOyszOSAzMzMgNDk2MzE3Mjxicj4K > RmF4OiAmbmJzcDsgJm5ic3A7ICszOSAwMzgyIDQ3NjQ5Nzxicj4KRW1haWw6ICZuYnNwOyA8YSBo > cmVmPSJtYWlsdG86YW5kb0BzeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0 > Lml0PC9hPjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Cjxicj4K > PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwPjxicj48L3A+Cg== > ------=_Part_36644_12214634.1225420991107-- > > Please post plaintext messages; as you can see, the ITS doesn't like other formats. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5778) slapd crashes while adding multipe attributes
by snowyurik＠gmail.com 31 Oct '08

31 Oct '08

------=_Part_36644_12214634.1225420991107 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiksIGlm IGkgdXNlIGJzZC1tYWtlIGZvcgpidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1dCBn b2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksCmluIGNhc2UgaSB1c2UgZ251 LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC4KCkluIGJvdGggc2l0dWF0aW9uLCBp IGdldCBubyBlcnJvcnMuCgpNYXliZSBJIGRvIHNvbWV0aGluZyB3cm9uZywgYnV0IGkgc2hvdWxk IGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcwpjYXNlLCBpc24ndCBpdD8KMjAwOC8xMC8z MCBQaWVyYW5nZWxvIE1hc2FyYXRpIDxhbmRvQHN5cy1uZXQuaXQ+Cgo+IODSycog78jPzsnOIHdy b3RlOgo+Cj4+IFNvcnJ5Lgo+Pgo+PiBUaGlzIGlzIGJlY2F1c2Ugb2YgRnJlZUJTRCBwb3J0cyBj b2xsZWN0aW9uLiBJJ2xsIHRyeSB0byBpbnN0YWxsIHRoZQo+PiBsYXRlc3QKPj4gcmVsZWFzZS4g V2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vlaywg YW5kIHRlbGwKPj4gaWYgdGhlIHByb2JsZW0gZXhpc3Q/Cj4+Cj4KPiBBcyB5b3UgbGlrZS4gICBC dXQgcGxlYXNlIHJlcGx5IHRvIDxvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPiwgbm90IHRvIG15 Cj4gcGVyc29uYWwgYWRkcmVzcy4KPgo+IHAuCj4KPgo+IEluZy4gUGllcmFuZ2VsbyBNYXNhcmF0 aQo+IE9wZW5MREFQIENvcmUgVGVhbQo+Cj4gU3lzTmV0IHMuci5sLgo+IHZpYSBEb3NzaSwgOCAt IDI3MTAwIFBhdmlhIC0gSVRBTElBCj4gaHR0cDovL3d3dy5zeXMtbmV0Lml0Cj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBPZmZpY2U6ICArMzkgMDIgMjM5OTgzMDkKPiBN b2JpbGU6ICArMzkgMzMzIDQ5NjMxNzIKPiBGYXg6ICAgICArMzkgMDM4MiA0NzY0OTcKPiBFbWFp bDogICBhbmRvQHN5cy1uZXQuaXQKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQo+Cj4K ------=_Part_36644_12214634.1225420991107 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: base64 Content-Disposition: inline PHA+SSBoYXZlIGluc3RhbGxlZCB0aGUgbGF0ZXN0IHJlbGVhc2UgKG9wZW5sZGFwLTIuNC4xMiks IGlmIGkgdXNlIGJzZC1tYWtlIGZvciBidWlsZGluZyBvcGVubGRhcCwgc2xhcGQgc3RhcnRzIGJ1 dCBnb2VzIG5vdCBhbnN3ZXIgbm8gYW55dGhpbmcgKGV2ZW4ga2lsbCksIGluIGNhc2UgaSB1c2Ug Z251LW1ha2UsIHNsYXBkIGRvZXMgbm90IHN0YXJ0IGF0IGFsbC48L3A+PHA+SW4gYm90aCBzaXR1 YXRpb24sIGkgZ2V0IG5vIGVycm9ycy48L3A+Cgo8cD5NYXliZSBJIGRvIHNvbWV0aGluZyB3cm9u ZywgYnV0IGkgc2hvdWxkIGdldCBzb21lIGVycm9yIG1lc3NhZ2UgaW4gdGhpcyBjYXNlLCBpc24m IzM5O3QgaXQ/PC9wPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA4LzEwLzMwIFBpZXJhbmdl bG8gTWFzYXJhdGkgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86YW5kb0BzeXMt bmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0Lml0PC9hPiZndDs8L3NwYW4+PGJy PgoKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdj7g0snK IO/Iz87JziB3cm90ZTo8YnI+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPgpTb3JyeS48YnI+Cjxicj4KVGhpcyBpcyBiZWNhdXNlIG9mIEZyZWVCU0QgcG9ydHMg Y29sbGVjdGlvbi4gSSYjMzk7bGwgdHJ5IHRvIGluc3RhbGwgdGhlIGxhdGVzdDxicj4KcmVsZWFz ZS4gV2lsbCBpdCBiZSBjb3JyZWN0IGlmIGkgcmVwbHkgdG8gdGhpcyBtZXNzYWdlIGluIGEgd2Vl aywgYW5kIHRlbGw8YnI+CmlmIHRoZSBwcm9ibGVtIGV4aXN0Pzxicj4KPC9ibG9ja3F1b3RlPgo8 YnI+PC9kaXY+CkFzIHlvdSBsaWtlLiAmbmJzcDsgQnV0IHBsZWFzZSByZXBseSB0byAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmciIHRhcmdldD0iX2JsYW5rIj5v cGVubGRhcC1pdHNAb3BlbmxkYXAub3JnPC9hPiZndDssIG5vdCB0byBteSBwZXJzb25hbCBhZGRy ZXNzLjxkaXY+PGRpdj48YnI+Cjxicj4KcC48YnI+Cjxicj4KPGJyPgpJbmcuIFBpZXJhbmdlbG8g TWFzYXJhdGk8YnI+Ck9wZW5MREFQIENvcmUgVGVhbTxicj4KPGJyPgpTeXNOZXQgcy5yLmwuPGJy Pgp2aWEgRG9zc2ksIDggLSAyNzEwMCBQYXZpYSAtIElUQUxJQTxicj4KPGEgaHJlZj0iaHR0cDov L3d3dy5zeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5zeXMtbmV0Lml0PC9h Pjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Ck9mZmljZTogJm5i c3A7KzM5IDAyIDIzOTk4MzA5PGJyPgpNb2JpbGU6ICZuYnNwOyszOSAzMzMgNDk2MzE3Mjxicj4K RmF4OiAmbmJzcDsgJm5ic3A7ICszOSAwMzgyIDQ3NjQ5Nzxicj4KRW1haWw6ICZuYnNwOyA8YSBo cmVmPSJtYWlsdG86YW5kb0BzeXMtbmV0Lml0IiB0YXJnZXQ9Il9ibGFuayI+YW5kb0BzeXMtbmV0 Lml0PC9hPjxicj4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Cjxicj4K PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwPjxicj48L3A+Cg== ------=_Part_36644_12214634.1225420991107--

1 0

Re: (ITS#5764) addpartial patch
by hyc＠symas.com 30 Oct '08

30 Oct '08

dhawes(a)vt.edu wrote: > Pierangelo Masarati wrote: >> dhawes(a)vt.edu wrote: >>> Full_Name: David Hawes >>> Version: 2.4.12 >>> OS: URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch >>> Submission from: (NULL) (128.173.38.164) >>> >>> >>> This patch includes the following changes: >>> >>> - -fPIC added to the Makefile for compilation on x86_64 systems. >>> - No longer use be_search() to retrieve the entry that is to be >>> compared. Use >>> be_entry_get_rw() instead. >> You should probably use overlay_entry_get_ov() rather than >> be_entry_get_rw() from inside an overlay (AFAIR). > > Okay, I'll make that change, thanks. > > I notice that most overlays seem to use be_entry_get_rw(), and one > (translucent) uses both. What is the reasoning to use one over the other? Most of those overlays were written before overlay_entry_get_ov() was written. It's just a convenience function so you don't have to juggle bd_info pointers all the time. -- -- Howard Chu CTO, 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#5764) addpartial patch
by dhawes＠vt.edu 30 Oct '08

30 Oct '08

Pierangelo Masarati wrote: > dhawes(a)vt.edu wrote: >> Full_Name: David Hawes >> Version: 2.4.12 >> OS: URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch >> Submission from: (NULL) (128.173.38.164) >> >> >> This patch includes the following changes: >> >> - -fPIC added to the Makefile for compilation on x86_64 systems. >> - No longer use be_search() to retrieve the entry that is to be >> compared. Use >> be_entry_get_rw() instead. > > You should probably use overlay_entry_get_ov() rather than > be_entry_get_rw() from inside an overlay (AFAIR). Okay, I'll make that change, thanks. I notice that most overlays seem to use be_entry_get_rw(), and one (translucent) uses both. What is the reasoning to use one over the other?

1 0

(ITS#5781) syncrepl doing delete/add on items without equality
by rubin＠physics.umn.edu 30 Oct '08

30 Oct '08

Full_Name: Alex Schumann Version: 2.4.11 OS: freebsd 7.0-release-p3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.101.220.229) We are using nis.schema's nisNetgroupTriple to hold unix netgroups. When we make a change, we do so using the following code snipit: $mesg = $ldap_master->modify ( $dn, replace => [ 'nisNetgroupTriple' => \@{$groups{$g}} ] ); The master accepts this change, but all the syncrepl slaves immediately start failing: Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_search (0) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 cn=ng115,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=ng115,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_search (0) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 cn=ng116,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed Oct 29 11:54:28 lanark slapd[4187]: null_callback : error code 0x12 Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_modify (18) Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_modify failed (18) Oct 29 11:54:28 lanark slapd[4187]: do_syncrepl: rid=001 retrying Error code 0x12 is LDAP_INAPPROPRIATE_MATCHING, which indicates that syncrepl tried to do a delete/add on a multivalued attribute witohout an equality matching rule. Reason being, the schema for nis defines nisNetgroupTriple without an EQUALITY. You can argue between openldap and sun if that is an error in the schema, but fact is syncrepl should not fail in this or similar cases. Proper behavior would be if there is no equality, syncrepl should fall back to a replace. many thanks to hyc on freenode #openldap for helping me to understand what was going on here. http://www.archivesat.com/OpenLDAP_bugs/thread1581049.htm indicates nisNetgroupTriple is improperly defined according to SUN, but is really an aside on this bug.

1 0

Re: (ITS#5764) addpartial patch
by ando＠sys-net.it 30 Oct '08

30 Oct '08

dhawes(a)vt.edu wrote: > Full_Name: David Hawes > Version: 2.4.12 > OS: > URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch > Submission from: (NULL) (128.173.38.164) > > > This patch includes the following changes: > > - -fPIC added to the Makefile for compilation on x86_64 systems. > - No longer use be_search() to retrieve the entry that is to be compared. Use > be_entry_get_rw() instead. You should probably use overlay_entry_get_ov() rather than be_entry_get_rw() from inside an overlay (AFAIR). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5779) backsql_load_schema_map checks wrong schema column in db
by robb＠wtg.cw.com 30 Oct '08

30 Oct '08

Pierangelo Masarati wrote: > I have applied a blind fix to back-sql/schema-map.c; please apply the > patch between r1.67 & r1.68 and report (presented below as a reference). > > p. > > diff -u -r1.67 schema-map.c > --- servers/slapd/back-sql/schema-map.c 21 Aug 2008 20:07:29 -0000 > 1.67 > +++ servers/slapd/back-sql/schema-map.c 30 Oct 2008 13:02:24 -0000 applied the fix and issue is resolved. Many thanks (and man that was fast :) Rob

1 0

Re: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)
by hyc＠symas.com 30 Oct '08

30 Oct '08

emmanuel.duru(a)atosorigin.com wrote: > It works fine with MoveFileEx. Thanks for the confirmation. We'll release this in 2.4.13... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5780) "manageDIT" is still used instead of "relax" here and there
by ando＠sys-net.it 30 Oct '08

30 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando s/manageDIT/relax/

1 0

Re: (ITS#5779) backsql_load_schema_map checks wrong schema column in db
by ando＠sys-net.it 30 Oct '08

30 Oct '08

robb(a)wtg.cw.com wrote: > Full_Name: Robert Brooks > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.28.17.64) > > > start-up of slapd reports > > "backsql_load_schema_map(): required column #6 "expect_return" is empty" > > however the value of ldap_oc_mappings.create_proc is actually being checked, > this can be confirmed by changing create_proc value in database from empty value > to non-empty. > > problem seems to be around line 567 of schema-map.c > > " { delete_proc_idx + 1, "expect_return" }," > > 6 seems correct value, but actual result is not correct I have applied a blind fix to back-sql/schema-map.c; please apply the patch between r1.67 & r1.68 and report (presented below as a reference). p. diff -u -r1.67 schema-map.c --- servers/slapd/back-sql/schema-map.c 21 Aug 2008 20:07:29 -0000 1.67 +++ servers/slapd/back-sql/schema-map.c 30 Oct 2008 13:02:24 -0000 @@ -570,7 +570,7 @@ int i; for ( i = 0; required[ i ].name != NULL; i++ ) { - if ( oc_row.value_len[ i ] <= 0 ) { + if ( oc_row.value_len[ required[ i ].idx ] <= 0 ) { Debug( LDAP_DEBUG_ANY, "backsql_load_schema_map(): " "required column #%d \"%s\" is empty\n", Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5759) whitespace vs white space
by ghenry＠OpenLDAP.org 30 Oct '08

30 Oct '08

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I noticed that the term "whitespace" and "white space" are used inconsistently > throughout the documentation. Can we please pick one? ;) > > --Quanah > > whitespace it is. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

RE: (ITS#5774) Modifications not saved on file by back-ldif (on Windows)
by emmanuel.duru＠atosorigin.com 30 Oct '08

30 Oct '08

It works fine with MoveFileEx.

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by ghenry＠OpenLDAP.org 30 Oct '08

30 Oct '08

Can you upload these zip attachments to our ftp server or somewhere else with online access please. Then we can test. > > ------=_Part_18730_5320025.1224681987183 > Content-Type: application/zip; name=test018-parallel-import.zip > Content-Transfer-Encoding: base64 > X-Attachment-Id: file0 > Content-Disposition: attachment; filename=test018-parallel-import.zip -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5779) backsql_load_schema_map checks wrong schema column in db
by robb＠wtg.cw.com 30 Oct '08

30 Oct '08

Full_Name: Robert Brooks Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.28.17.64) start-up of slapd reports "backsql_load_schema_map(): required column #6 "expect_return" is empty" however the value of ldap_oc_mappings.create_proc is actually being checked, this can be confirmed by changing create_proc value in database from empty value to non-empty. problem seems to be around line 567 of schema-map.c " { delete_proc_idx + 1, "expect_return" }," 6 seems correct value, but actual result is not correct

1 0

Re: (ITS#5778) slapd crashes while adding multipe attributes
by ando＠sys-net.it 30 Oct '08

30 Oct '08

yoreck(a)rambler.ru wrote: > Full_Name: Yuriy V. Ohonin > Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49) Is there any special reason you're using a release that is more than 2 years old? Can you reproduce the issue with the latest release? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5778) slapd crashes while adding multipe attributes
by yoreck＠rambler.ru 30 Oct '08

30 Oct '08

Full_Name: Yuriy V. Ohonin Version: slapd 2.4.3alpha (Oct 16 2008 14:08:49) OS: FreeBSD 6.2-RELEASE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.65.16.93) slapd daemon crashes complitely in such a situation: I create my own class in shema objectclass ( Tasks:Chain:Element NAME ('x-tch-e' 'x-Task-Chain-Element') MUST ( cn ) MAY ( x-tch-nxt $ x-tch-sp $ x-tch-ep ) DESC 'Container of pointers, next and previos' ) and an attribute wich should have multiple values attributetype ( Tasks:Attr:3 NAME ('x-tch-nxt' 'x-Task-Chain-Next') EQUALITY distinguishedNameMatch DESC 'Point to next chain element' SYNTAX distinguishedName ) Slapd starts sussesfully. It is possible add first x-tch-nxt attribute to an entry, but if i try to add next one (usind ldapbrowser, or ldap_mod_add php function) slapd stops (i have no such process any more) this is what syslog say: Oct 30 12:11:45 yurik kernel: pid 13227 (slapd), uid 389: exited on signal 6

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs