- openldap-bugs - openldap.org

(ITS#5419) test048 fails...
by luca＠OpenLDAP.org 13 Mar '08

13 Mar '08

Full_Name: Luca Scamoni Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) consistently Running ./scripts/test048-syncrepl-multiproxy... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting P1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that P1 slave slapd is running... Starting R1 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R1 slave slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... ldapsearch failed at P1 slave (32)! modifications to the master are not propagated to the slaves

1 0

Re: (ITS#5391) hdb deadlock
by hyc＠symas.com 13 Mar '08

13 Mar '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> One thing that I've started doing recently in my configs is to skip >> the #bytes option (leave it zero), so that only time-based checkpoints >> occur. Since they're done in a dedicated task, only one thread at a >> time can trigger a checkpoint. > > How about making #bytes-based checkpoints signal or (pthread_kill?) the > timed checkpoints thread, so that thread can handle all checkpoints? It's an interesting idea. But that means we have to count bytes ourselves, rather than letting BerkeleyDB do it. And that's rather difficult, since we don't know the actual volume of writes resulting from a given operation. Personally I don't think byte counts are very useful here. They're made somewhat superfluous because the data volume will tend to cause the transaction log buffers to fill up and be flushed regardless. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5401) slapd crashes in mirrormode
by hyc＠symas.com 13 Mar '08

13 Mar '08

A patch for this is now in CVS HEAD. Please test. I was unable to reproduce the reported crash, so your feedback is important here. ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.8 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > Hi, > I am testing OpenLdap 2.4.8 in mirrormode. > I have two mirror servers (A, and B) synchronized in SearchAndPersist mode with > a retry interval of 10 seconds : retry="10 +". > An injector writes data to A. The data is replicated in B. But this server > UNBINDs then reBINDs to A every 10 seconds ! > This continues until slapd on A crashes with a SIGIOT. More investigation in the > slapd log shows that the crash is caused by the losing of the client syncrepl > connection coming from B ! -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5411) rename the leave label to allow building on OSF
by ando＠sys-net.it 12 Mar '08

12 Mar '08

pogma(a)thewrittenword.com wrote: Fixed in HEAD, please test. Thanks, 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5418) Syncrepl filters are evaluated using the wrong DN
by ando＠sys-net.it 12 Mar '08

12 Mar '08

roessner(a)capcom.de wrote: Fixed in HEAD. Thanks, 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5418) Syncrepl filters are evaluated using the wrong DN
by roessner＠capcom.de 12 Mar '08

12 Mar '08

Full_Name: Ralph Rößner Version: 2.4.8 OS: Debian Linux URL: ftp://ftp.capcom.de/pub/CPS/openldap-ITS-20080312/ Submission from: (NULL) (146.140.221.89) When syncreplication is run in refreshAndPersist mode and it is limited to certain objects by a "filter=..." expression and one of these objects is modified then the attributes needed to check the filter expression are accessed using the rights of the DN that the modifying connection is bound to, not those of the DN that the replication connection is bound to. This can result in modifications not being propagated to the consumer server. This was encountered in the wild when a user successfully changed some service password but found that the change was not reflected by the consumer slapd that he was subsequently trying to authenticate to. The same change requested by a maintenance tool (under a different bind dn) was replicated. Turning on ACL tracing showed up the behaviour described above. I have created a demonstration configuration and data set, available at the provided ftp URL and summarized in the "index" file there. The demonstration features a replication that is restricted to object that have the "replicate" attribute set to "yes", a user object "uid=user,ou=subtree,o=test" that is allowed to change its password but not allowed to read the "replicate" attribute, a maintenance object "uid=maintainer,o=test" that is allowed to create or modify user entries, including their "replicate" attribute, and a replication object "uid=replicator,o=test" that is used as bind dn for the replication and is allowed to read everything that has the "replicate" attribute set to "yes". I have then changed the userPassword attribute of the user object, using the ldappasswd tool, and traced the provider slapd. The logs show that after the modification is done, the "replicate" attribute is accessed, and the ACLs are checked using the dn that the modifying connection is bound to (which is the user dn in the case of the first log and the maintenance dn in the second). Only the modification made by the maintainer is propagated, the one made by the user is not, as shown by the logs and by the ldapsearch results provided with the files. Allowing access to the "replicate" attribute for everyone (as in the "slapd-workaround.conf") works around the problem. The third slapd log file shows that now even a modification made by the user dn is being propagated. Pierangelo Masarati has already suggested a patch for this behaviour on the openldap-software list (included with the files). After applying this patch the behaviour changes as shown in the last provided slapd log file, i.e. the access checks to the "replicate" attribute are made with respect to the replication dn, and do not any more depend on the dn that requested the modification. This fixes the problem for me in the demonstration setup. Sincerely, Ralph Rößner

1 0

Re: (ITS#5417) ldap memory utilization extremely high
by quanah＠zimbra.com 12 Mar '08

12 Mar '08

--On Wednesday, March 12, 2008 4:50 PM +0000 james(a)broadsoft.com wrote: > Full_Name: J B > Version: openldap-2.3.27 (a) I advise upgrading to a newer release (b) There's no indication of a bug being present here isn't fixed in a later release (c) You may simply need to better tune your slapd. If after upgrading to the current 2.3 release (2.3.41) you continue to see issues, I would recommend you email the software list if you have questions about how to properly tune OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5417) ldap memory utilization extremely high
by james＠broadsoft.com 12 Mar '08

12 Mar '08

Full_Name: J B Version: openldap-2.3.27 OS: FreeBSD 4.7-RELEASE-p28 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.88.7.2) The ldap process periodically shows high CPU utilization. It will gradually climb from an extremely low number to up to 95%, then gradually return to an extremely low number again. The server is running ldap to authenticate for a Plone/zope for which the user needs to log in. In this instance the process is extremely low. However at times it can reach 85%. During these times, the login process can take up to 30 seconds. It seems when the utilization is low, the login process is only 1 second. PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 34154 zope2 2 0 1173M 1165M poll 1 21.2H 14.06% 14.06% python2 370 ldap 2 0 149M 12564K poll 0 469.1H 2.34% 2.34% slapd another top output shows that slpad actually reached 0% PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 62976 root 28 0 2068K 1064K CPU1 1 0:01 16.10% 3.56% top4 370 ldap 2 0 149M 12564K poll 0 469.1H 0.00% 0.00% slapd

1 0

Re: (ITS#5414) About nis.schema
by h.b.furuseth＠usit.uio.no 12 Mar '08

12 Mar '08

I wrote: > Rename your hacked nis.schema and put it somewhere an upgrade will not > touch. ..and include that instead of nis.schema from slapd.conf, if that wasn't clear. -- Hallvard

1 0

Re: (ITS#5414) About nis.schema
by h.b.furuseth＠usit.uio.no 12 Mar '08

12 Mar '08

jtwang(a)cs.nctu.edu.tw writes: > When we upgrade the openldap server, the modifed "nis.schema" would be > replaced with a unmodified "nis.schema". > > Our servers will be down, because there are some strings in database which > conflicts to "nis.schema". Rename your hacked nis.schema and put it somewhere an upgrade will not touch. > May you change the default schema of the "gecos" field and make it to > be able to carry dual-byte string? Unfortunately, no. The schema is defined in RFC2307, which specifies IA5 String (ASCII) gecos. OpenLDAP follows that, and a change would cause interoperability problems with servers which still follow the RFC. You could write the RFC author and ask if there are plans to update to use Directory String. So, not an OpenLDAP bug. This ITS will be closed. -- Hallvard

1 0

(ITS#5416) slapd core dump
by rui.yan＠gmail.com 12 Mar '08

12 Mar '08

Full_Name: yanr Version: 2.4.8 OS: Linux 2.6.22 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.221.197.21) Verion: 2.4.8 Desc: client runs some codes like ldap_modify_ext, sometimes slapd core dump. The same codes works on 2.3.38. [root@test1 /]# uname -r 2.6.22.9-2.smp.gcc3.4.x86_64 (gdb) bt #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 67 int res = INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00002b018fa6da3d in *__GI_raise (sig=19040) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #1 0x00002b018fa6ef1e in *__GI_abort () at ../sysdeps/generic/abort.c:88 #2 0x00002b018fa67720 in *__GI___assert_fail (assertion=0x56ad43 "i > 0", file=0x56acf8 "schema_init.c", line=366, function=0x56ad30 "octetStringIndexer") at assert.c:83 #3 0x00000000004664b3 in octetStringIndexer (use=163, flags=4, syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x2aaaaacad6b0, keysp=0x42001598, ctx=0x83d970) at schema_init.c:366 #4 0x000000000046ffde in objectSubClassIndexer (use=163, mask=4, syntax=0x77ea70, mr=0x77ed70, prefix=0x77ec48, values=0x87b7e0, keysp=0x42001598, ctx=0x83d970) at schema_prep.c:305 #5 0x00000000004e898b in indexer (op=0x839cc0, txn=0x87c680, ad=0x7789b0, atname=0x77ec48, vals=0x87b7e0, id=86, opid=2, mask=4) at index.c:205 #6 0x00000000004e8e2d in index_at_values (op=0x839cc0, txn=0x87c680, ad=0x7789b0, type=0x77ebe0, tags=0x7789d0, vals=0x87b7e0, id=86, opid=2) at index.c:337 #7 0x00000000004e8fa6 in bdb_index_values (op=0x839cc0, txn=0x87c680, desc=0x7789b0, vals=0x87b7e0, id=86, opid=2) at index.c:386 #8 0x00000000004ae4d6 in bdb_modify_internal (op=0x839cc0, tid=0x87c680, modlist=0x87b700, e=0x420018f0, text=0x42002e30, textbuf=0x42001980 "��\213\216\001+", textlen=256) at modify.c:287 #9 0x00000000004af29c in bdb_modify (op=0x839cc0, rs=0x42002e10) at modify.c:577 #10 0x0000000000443710 in fe_op_modify (op=0x839cc0, rs=0x42002e10) at modify.c:300 #11 0x0000000000443172 in do_modify (op=0x839cc0, rs=0x42002e10) at modify.c:175 #12 0x000000000042629d in connection_operation (ctx=0x42002f60, arg_v=0x839cc0) at connection.c:1084 #13 0x00000000004267d9 in connection_read_thread (ctx=0x42002f60, argv=0xc) at connection.c:1211 #14 0x000000000052409d in ldap_int_thread_pool_wrapper (xpool=0x78ab30) at tpool.c:625 #15 0x00002b018e8bc35a in start_thread () from /lib64/tls/libpthread.so.0 #16 0x00002b018faf6473 in clone () from /lib64/tls/libc.so.6 #17 0x0000000000000000 in ?? ()

1 0

(ITS#5414) About nis.schema
by jtwang＠cs.nctu.edu.tw 11 Mar '08

11 Mar '08

Full_Name: Jiun-Tsung Wang Version: 2.3.41 OS: FreeBSD 6.3-Release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.113.166.53) Hello, We can't store any dual-byte(including UTF-8) string in "gecos" field which be declared in "nis.schema". But we need to store some Chinese information in it. We store Chinese information by modifying the nis.schema from attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) to attributetype ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) . When we upgrade the openldap server, the modifed "nis.schema" would be replaced with a unmodified "nis.schema". Our servers will be down, because there are some strings in database which conflicts to "nis.schema". May you change the default schema of the "gecos" field and make it to be able to carry dual-byte string? Thanks! -- Jiun-Tsung Wang(jtwang(a)cs.nctu.edu.tw) Computer Center of Computer Science Department, Nation Chiao-Tung University, Taiwan R.O.C

1 0

(ITS#5413) typo in syncrepl.c causes SEGV
by hyc＠OpenLDAP.org 11 Mar '08

11 Mar '08

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc in compare_csns, sc1->ctxcsns[i] is compared against sc2->ctxcsns[i], the latter should have been [j] instead.

1 0

Re: (ITS#5409) paged results invalid sizelimit error
by quanah＠zimbra.com 11 Mar '08

11 Mar '08

--On Tuesday, March 11, 2008 4:14 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.41 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (24.23.156.219) >> >> >> Intermittently if the max entries requested is exact multiple of page >> size, after a paged search hits SizeLimitExceededException, the next >> search also always throws a SizeLimitExceededException, even when it >> should not. > > Does "the next search" also use the paging control? Yes. >> e.g. if max requested is 5000, if page size is: >> 1000 => bad >> 2500 => bad >> 999 => good >> 2000 => good >> >> I have a java program that can reproduce this. > > Are you sure it's not AdminLimitExceeded? Yes. javax.naming.SizeLimitExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; > Does the same situation occur in 2.4? I don't have 2.4 available to test with at this time. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5409) paged results invalid sizelimit error
by hyc＠symas.com 11 Mar '08

11 Mar '08

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.23.156.219) > > > Intermittently if the max entries requested is exact multiple of page size, > after a paged search hits SizeLimitExceededException, the next search also > always throws a SizeLimitExceededException, even when it should not. Does "the next search" also use the paging control? > e.g. if max requested is 5000, if page size is: > 1000 => bad > 2500 => bad > 999 => good > 2000 => good > > I have a java program that can reproduce this. Are you sure it's not AdminLimitExceeded? Does the same situation occur in 2.4? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5412) Add operation should not require naming attrs
by h.b.furuseth＠usit.uio.no 11 Mar '08

11 Mar '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard A somewhat belated ITS: ldapadd of dn: o=foo objectClass: organization complains that "naming attribute 'o' is not present in entry". RFC 2251 required this, but RFC 4511 changed it to the opposite: The RDN attrs need not be present in AddRequest.attributes. slapd and slapadd should generate them if they are missing. I don't know if the change belongs in RE23.

1 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)
by h.b.furuseth＠usit.uio.no 11 Mar '08

11 Mar '08

jclarke(a)linagora.com writes: > > Eh. API design bug. (...) > Hmmm. I may have misunderstood, (...) No, I did. I'll file a separate ITS for it. -- Hallvard

1 0

Re: (ITS#5408) back-ldif bugs
by h.b.furuseth＠usit.uio.no 11 Mar '08

11 Mar '08

Another question: How should backends handle the return value from, and rs->sr_err to/from, send_search_entry() and send_search_reference()? The back-ldif handling differs from back-bdb/search.c. At one point ldapsearch got insufficientAccessRights when an entry _below_ baseDN in the search scope was ACL-protected. But I can't reproduce it, and don't know if the error was mine or back-ldif's. Other details: ldif_back_search() modified op->ors_scope. That looked improper, I removed it. The ENOENT special case for rename() in spew_entry() made little sense, since it was just moving the file it just created, and to the same directory. I deleted it, but I wonder why it was there. I wrote: > + Sorting (in ldif_r_enum_tree()): > Should "a={1}x" sort before or after "a=x"? Currently it sorts > like "a={". "a=" (normally before) or "a=<CHAR_MAX>" (normally > after) would be better. No, UCHAR_MAX. strcmp compares the strings as unsigned char*. -- Hallvard

1 0

(ITS#5411) rename the leave label to allow building on OSF
by pogma＠thewrittenword.com 10 Mar '08

10 Mar '08

Full_Name: Peter O'Gorman Version: 2.4.8 OS: OSF1 5.1 URL: ftp://ftp.openldap.org/incoming/the-written-word-rename-leave-080310.patch Submission from: (NULL) (24.76.165.223) osf1's headers have, in /usr/include/c_excpt.h:#define leave __builtin_leave, this causes build failures. This patch simply renames leave to func_leave.

1 0

(ITS#5410) Patch for contrib smbk5pwd.c to use gcrypt
by pogma＠thewrittenword.com 10 Mar '08

10 Mar '08

Full_Name: Peter O'Gorman Version: 2.4.8 OS: URL: ftp://ftp.openldap.org/incoming/the-written-word-smbk5pwd-080310.patch Submission from: (NULL) (24.76.165.223) This patch allows the smbk5pwd slapd module to build with gcrypt instead of openssl.

1 0

(ITS#5409) paged results invalid sizelimit error
by quanah＠zimbra.com 10 Mar '08

10 Mar '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) Intermittently if the max entries requested is exact multiple of page size, after a paged search hits SizeLimitExceededException, the next search also always throws a SizeLimitExceededException, even when it should not. e.g. if max requested is 5000, if page size is: 1000 => bad 2500 => bad 999 => good 2000 => good I have a java program that can reproduce this.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 10 Mar '08

10 Mar '08

hyc(a)symas.com writes: >>> "An LDAP server MUST act in accordance with the X.500 (1993) series" >> Except when it doesn't. Like the various implications of sending text >> instead of ASN.1 and numeric OIDs. > That's irrelevant. The service model and the on-the-wire encoding are > two completely different things. That's not what I meant, but in any case, this discussion seems to be going nowhere fast as far as resolving this ITS is concerned. I've committed the referral_rewrite fix I suggested and removed default_referral. Left back-ldif alone for now, can take it with ITS#5408. Didn't mark it "test" yet, I don't know if changes like 'reject add of ref attr with DN' or whatever you think should be done should go in this ITS or another one. -- Hallvard

1 0

(ITS#5408) back-ldif bugs
by h.b.furuseth＠usit.uio.no 10 Mar '08

10 Mar '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: Linux URL: http://folk.uio.no/hbf/OpenLDAP/back-ldif.c Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Here are a bunch of back-ldif bugs some questions. I have code for most of it, but need advice/discussion on functionality changes. I've been sitting on it too long and would keep sitting if I waited until I'd cleaned up everything, so, posting now instead. I enclose an URL for a *draft* back-ldif/ldif.c. Functionality changes. * Some LDIF files/directories with special chars need to be renamed: RE24 or RE25 change? If anyone uses back-ldif as a regular database, they may need to slapcat/slapadd to upgrade past these changes. - back-ldif escapes the directory separator as \<hex value>. But Windows uses "\" as directory separator, so that doesn't help. It needs another escape character. To avoid double hex-escaping of DNs that contain "\", we can pick another escape char, e.g. "^", escape that too, and translate "\" to it. Thus DN "cn=x^y\2Cz" gets filename "cn=x^5Ey^2Cz.ldif". - More characters should likely be hex-escaped: + ":" (as in "C:\") and "/" on Windows? I've seen programs use the latter as directory separator even on Windows. Others? + 8-bit chars in case the OS gets clever about charset handling. + Control chars. I don't use Windows myself though. Nor Mac... - When back-ldif uses OS-specific escaping, we can't move a directory tree between Windows and Unix hosts if some RDN in the tree contains characters with OS-specific escaping. Should we special-case both Unix' and Windows' directory separators on both OSes? Then instead there will be more directory trees which can't be move between OpenLDAP versions, before and after the change. Assuming anyone uses back-ldif in the first place:-) - The database suffix must be hex-escaped like the rest of the filenames. - RDNs ending with ".ldif" should be escaped. Currently "cn=foo.ldif" is the name of both RDN "cn=foo"'s entry file and RDN "cn=foo.ldif"'s non-leaf directory. - Sorted-value RDNs: + In dn2path() when IX_FSL != IX_DNL (filename '{' != RDN '{'): IX_FS[LR] must be hex-escaped. They are treated as equivalent to '{' - '}', thus different RDNs can map to the same filename. The "{1}" in path "/foo/cn=x{,cn={1}y" is not recognized. The IX_DN[LR] (i.e. '{', '}') to IX_FS[LR] translation is a bit strange: It translates the first '{' it sees, then the next '}', then the next '{', etc. Any reason not to just translate all '{' and '}' chars? If so, we should at least reset at each filename and '+'. + Sorting (in ldif_r_enum_tree()): Should "a={1}x" sort before or after "a=x"? Currently it sorts like "a={". "a=" (normally before) or "a=<CHAR_MAX>" (normally after) would be better. RDN "attr=foo{bar}baz" is treated as a sorted value. Can easily check for '={' <successful strtol parse'> '}' instead. "attr={0<octal>}val" and "attr={0x<hex>}val" are recognized as sorted values, should they be? Some of this is from ITS#4627 (back-ldif issues). * If slapcat encounters an error in some entry, it outputs a partial tree and returns success - no indication that the tree is wrong. It looks deliberate: ldif_tool_entry_first() explicitly ignores the error code. Looks to me like it should at least cause be_entry_get() to fail. Maybe it should also output an empty tree at failure. (entry_first() reads all the entries before it returns anything.) Or if the intent is to output as much as possible in case of failure (at least with slapcat -c), it should not give up at the first error it encounters. * Referral handling is broken: - Apparently manageDSAit should only apply to the operation's base object: Return a referral if the base is missing and a parent is a referral object. That matches back-bdb, but breaks RFC 3296. - ldif_back_referrals() should return non-success for more internal errors, like BDB. - Search referrals (in ldif_back_referrals()) and continuation references (in ldif_back_search() get the wrong scope. The former should use op->ors_scope, the latter should use the same scope as when it looked up the entry. (It has already changed LDAP_SCOPE_ONELEVEL to LDAP_SCOPE_BASE.) - Modify DN should catch newSuperior=<referral object>. - The default_referral code can be deleted, see ITS#5339. * Multiple suffixes break back-ldif. Simplest fix is to forbid multiple suffixes: Set be_flag SLAP_DBFLAG_ONE_SUFFIX in bi_db_init(), if I understand correctly. * olcDbDirectory should be 'SINGLE-VALUE'd in the back-ldif schema. * Internal errors should return LDAP result code 'other', not unwillingToPerform/busy. Unless there is some reason it returned those, like back-config expects unwillingToPerform? I didn't see any. * Check for Abandon. At least in Search, which rfc4511 requires to check for Abandon. As far as I can tell we just need to sprinkle be->be_<operation>() with "if (op->o_abandon) return SLAPD_ABANDON;" and the caller will take care of the rest. * ITS#5329: ACL deadlock. Should the ACL check be there? More checks? ======================================================================== Other bugs for which the fixes should not break anything: * Modify DN with newSuperior does not create the new parent directory. * Search should send noSuchObject only when it is the baseobject which does not exist. (ldif_r_enum_tree() checks the scope to see if it .is at the baseobject, that doesn't work.) * ldapadd <suffix entry> creates <database directory> if file <database directory>.ldif exists. * tmpfile-names can in theory match a DN/RDN (and thus a subtree's directory name). A simple fix is to include ",," in tempfile-names. * slurp_file() buffer overrun if file size > (int)fstat().st_size. (Size > INT_MAX, file grew after fstat(), filetype where st_size=0.) Since I was changing so much anyway, I did some other changes: * Better result code/error handling, improve/normalize Debug output. - Handle errors from most system calls. modrdn in particular was bad. - Drop the one use of op->o_log_prefix in Debug(), it seems out of place. - Return LDAP result codes from more functions. - spew_entry(): + Remove *save_errnop arg, return/print error instead. + Wrong save_errno setting after close(). + Wrong spew_entry() error-return check in ldif_back_modify(). - move_entry() checked incorrectly for open()/spew_entry() errors. - Remove the ENOENT special case in spew_entry(). Should only happen if someone is messing with the database contents by hand, or due to bugs I've fixed (like in move_entry). * Move code around, in particular: - Move file operations around to help error checking. - Do all reads before writes in LDAP update ops, to narrow down locks. - Move common add/modify/modrdn code to ldif_prepare_create(). - Make directories and files in a single function ldif_spew_entry(). - Reuse computed values more. * Change some integer types to what they are used for. * Cleanup: - Rename some functions by prepending "ldif_" for better debug output, and get_entry/get_entry_for_fd() -> ldif_read_entry/read_entry_file so those names differ more from ldif_back_entry_get(). - Add comments. - Reformat somewhat. Function headers, too long lines, spacing, etc. - Remove 'if something != NULL' tests where that's already guaranteed. - Reduce switch statements - remove no-op default/break, etc. - Rename some variables. dn=>ndn for normalized DN, rs=>rc for result code, etc. Use macros like ors_scope for oq_search.rs_scope.

1 0

Re: (ITS#5329) back-ldif deadlock
by h.b.furuseth＠usit.uio.no 10 Mar '08

10 Mar '08

I wrote: > Assuming the acl call should be there, one simple fix could be to > introduce a 'li_wlock' mutex, lock it early on LDAP update operations, > and delay locking li_rdwr until the operation is about to update > the database. That does affect scheduling: Incoming read operations bypass pending write operations that are waiting for another write operation. (Since write but not read operations lock li_wlock before li_rdwr.) Looks acceptable to me, back-ldif doesn't exist for max performance. -- Hallvard

1 0

ITS#5396
by ecizaguirre＠gmv.com 10 Mar '08

10 Mar '08

Hi Pierangelo, I guess I have to explain a little bit more about the configuration I am working with. I didn't send the whole config file, there are two URIs defined in it with correspondig rewrite rules so the rewrite engine is needed, although I have to check the rewrite capabilities of back-meta. I have used the single-conn directive but I have faced the same problem, every connection gets stuck in the CLOSE_WAIT state in the metadirectory server but is closed in the remote LDAP servers. I guess you are rigth and is only a configuration issue but, why every socket remains open, in CLOSE_WAIT state, even when there is no more connections to the server? I have reproduced the issue in a test enviroment and the sockets are freed only when the slapd server is stopped. The whole config file follows: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # ### Fichero de schema basico de OpenLDAP. include /opt/openldap-2.4.8/etc/openldap/schema/core.schema ### Definiciones incluidas con OpenLDAP. Es importante usar el orden dado ya ### que hay atributos definidos en un schema que se usan en los siguientes. include /opt/openldap-2.4.8/etc/openldap/schema/cosine.schema include /opt/openldap-2.4.8/etc/openldap/schema/inetorgperson.schema ### Definicion de atributos de Active Directory. include /opt/openldap-2.4.8/etc/openldap/schema/AD.schema ### Definicion incluida con OpenLDAP para usar LDAP como servicio NIS. include /opt/openldap-2.4.8/etc/openldap/schema/nis.schema ### Definicion de atributos y objetos de Grupo GMV. include /opt/openldap-2.4.8/etc/openldap/schema/local.schema ### Definicion de atributos y objetos de samba. include /opt/openldap-2.4.8/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. pidfile /opt/openldap-2.4.8/var/run/slapd.pid argsfile /opt/openldap-2.4.8/var/run/slapd.args ## TTL para tirar una conexion inactiva (1 minuto). idletimeout 60 ## Caractersiticas adicionales. allow bind_anon_cred ####################################################################### # # Definicion de una base de datos Metadirectorio para consultas a AD. # ####################################################################### backend meta database meta ## Sufijo del arbol mostrado por el metadirectorio y usuario ## administrador del mismo(superusuario de ldap). suffix "dc=gmv,dc=es" rootdn "cn=diradmin,dc=gmv,dc=es" ## Password del superusuario, pasar a texto cifrado con slappasswd. rootpw secret ############################################## ### Opciones comunes a todo el metadirectorio. ############################################## ######################################### #### Directivas comunes de configuracion. ## TTL para tirar una conexion, aunque no este inactiva (6 minutos). conn-ttl 120 ## Version del protocolo LDAP a utilizar. protocol-version 3 ## Accion ante un referral. chase-referrals no ##################################################################### ### Definicion del LDAP remoto para las consultas de informacion de ### usuario y grupos UNIX desde maquinas que son clientes LDAP. ##################################################################### ## Definicion de los servidores target remotos a consultar. ## Se consultara el primer servidor remoto que responda. ## Defino una lista de dcs que pueden responder para el contexto de ## nombre dc=gmv,dc=es. Primer target con sus parametros de configuracion. uri "ldap://gmvdc1.gmv.es/DC=gmv,DC=es" "ldap://gmvdc2.gmv.es/" ## Habilitamos el sistema de reescritura para las consultas. rewriteEngine on overlay rwm ## Pseudoroot DN. idassert-bind bindmethod=simple binddn="CN=proxymetadir,OU=SISTEMAS,OU=Usuarios,DC=gmv,DC=es" credentials="****" mode=none ################################################################### ################################################################### # Definicion de las reglas de reescritura a utilizar para los DCs. ################################################################### ################################################################### ## Reglas de reescritura para buscar informacion en los DCs. ## Primero se cambia el sufijo del arbol para buscar grupos. rwm-suffixmassage "ou=group,dc=gmv,dc=es" "OU=Proyectos,OU=Grupos,DC=gmv,DC=es" ## Ahora se modifica para buscar las cuentas de usuario. rwm-suffixmassage "ou=people,dc=gmv,dc=es" "OU=Usuarios,DC=gmv,DC=es" ## Regla de reescritura para el DN de los grupos. ## Teoricamente solo deberia aplicarse a los resultados devueltos ## a los clientes del servidor. rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+)?_prj,ou=Group,dc=gmv,dc=es" "$1,ou=Group,dc=gmv,dc=es" ## Ahora vienen las reglas de reescritura de los atributos y las ## clases de objeto de cuentas de usuario y grupo UNIX. rwm-map objectClass posixAccount user rwm-map objectClass shadowAccount person rwm-map objectClass posixGroup group ## ## Definicion de atributos a mapear con MS SFU 3.0. ## rwm-map attribute gecos msSFU30Gecos rwm-map attribute homeDirectory msSFU30HomeDirectory rwm-map attribute uidNumber msSFU30UidNumber rwm-map attribute loginShell msSFU30LoginShell rwm-map attribute gidNumber msSFU30GidNumber rwm-map attribute memberUid msSFU30MemberUid rwm-map attribute ShadowFlag msSFU30ShadowFlag rwm-map attribute ShadowExpire msSFU30ShadowExpire rwm-map attribute ShadowInactive msSFU30ShadowInactive rwm-map attribute ShadowMax msSFU30ShadowMax rwm-map attribute ShadowWarning msSFU30ShadowWarning rwm-map attribute ShadowLastChange msSFU30ShadowLastChange rwm-map attribute ShadowMin msSFU30ShadowMin ### Como hay dos atributos iguales para los usuarios y para ### los grupos haremos esta distincion entre unos y otros ### para realizar el mapeo entre los dos. ## Los grupos se identifican por cn. rwm-map attribute cn msSFU30Name ## Los usuarios se identifican por uid. rwm-map attribute uid sAMAccountName ## El resto de atributos no los quiero para nada asi que me los ## cargo con los siguientes mapeos. rwm-map attribute DSCOREPROPAGATIONDATA rwm-map attribute SHOWINADDRESSBOOK rwm-map attribute MSEXCHHOMESERVERNAME rwm-map attribute MSEXCHALOBJECTVERSION rwm-map attribute MSEXCHMAILBOXSECURITYDESCRIPTOR rwm-map attribute MSEXCHUSERACCOUNTCONTROL rwm-map attribute MSEXCHMAILBOXGUID rwm-map attribute PROXYADDRESSES rwm-map attribute MEMBEROF rwm-map attribute HOMEMTA rwm-map attribute HOMEMDB rwm-map attribute USERACCOUNTCONTROL rwm-map attribute manager rwm-map attribute LEGACYEXCHANGEDN rwm-map attribute BADPWDCOUNT rwm-map attribute BADPASSWORDTIME rwm-map attribute LASTLOGOFF rwm-map attribute LASTLOGON rwm-map attribute USERWORKSTATIONS rwm-map attribute PWDLASTSET rwm-map attribute OBJECTSID rwm-map attribute ADMINCOUNT rwm-map attribute ACCOUNTEXPIRES rwm-map attribute LOGONCOUNT rwm-map attribute DIRECTREPORTS rwm-map attribute USNCREATED rwm-map attribute USNCHANGED rwm-map attribute CODEPAGE rwm-map attribute OBJECTGUID rwm-map attribute MDBUSEDEFAULTS rwm-map attribute title rwm-map attribute physicalDeliveryOfficeName rwm-map attribute objectCategory rwm-map attribute LASTLOGONTIMESTAMP rwm-map attribute MSEXCHPOLICIESINCLUDED rwm-map attribute MSRTCSIP-PRIMARYHOMESERVER rwm-map attribute MSRTCSIP-PRIMARYUSERADDRESS rwm-map attribute MSRTCSIP-FEDERATIONENABLED rwm-map attribute MSRTCSIP-OPTIONFLAGS rwm-map attribute street rwm-map attribute jpegPhoto rwm-map attribute USERPARAMETERS rwm-map attribute member rwm-map attribute INSTANCETYPE rwm-map attribute WHENCREATED rwm-map attribute WHENCHANGED rwm-map attribute COMPANY rwm-map attribute DELIVERANDREDIRECT rwm-map attribute AUTHORIGBL rwm-map attribute MAILNICKNAME rwm-map attribute COUNTRYCODE rwm-map attribute LOGONHOURS rwm-map attribute PRIMARYGROUPID rwm-map attribute SAMACCOUNTTYPE rwm-map attribute USERPRINCIPALNAME rwm-map attribute textEncodedORAddress rwm-map attribute mail rwm-map attribute MSRTCSIP-USERENABLED rwm-map attribute MSRTCSIP-INTERNETACCESSENABLED rwm-map attribute SRTCSIP-ARCHIVINGENABLED rwm-map attribute c rwm-map attribute l rwm-map attribute st rwm-map attribute postalCode rwm-map attribute telephoneNumber rwm-map attribute facsimileTelephoneNumber rwm-map attribute givenName rwm-map attribute initials rwm-map attribute MSRTCSIP-ARCHIVINGENABLED rwm-map attribute MSSFU30NISDOMAIN rwm-map attribute SCRIPTPATH rwm-map attribute DEPARTMENT rwm-map attribute co rwm-map attribute GECOS-OLD rwm-map attribute UIDNUMBER-OLD rwm-map attribute GIDNUMBER-OLD rwm-map attribute LOGINSHELL-OLD rwm-map attribute MSSFUHOMEDIRECTORY rwm-map attribute MSSFUNAME ############################################## ### Opciones comunes a todo el metadirectorio. ############################################## ######################################### #### Directivas comunes de configuracion. ## TTL para tirar una conexion, aunque no este inactiva (60 segundos). conn-ttl 90 ## Version del protocolo LDAP a utilizar. protocol-version 3 ## Accion ante un referral. chase-referrals no ##################################################################### ### Definicion del LDAP local para las consultas de informacion de ### mapas de automount, perfiles de inicializacion de clientes Solaris ### y los netgroups. ##################################################################### ## Ahora defino el ldap que contiene los mapas de autofs ## asi como los perfiles para los clientes LDAP Solaris. ## De momento hago la prueba en local. uri "ldap://172.22.4.13:390/dc=gmv,dc=es" ## Habilitamos el sistema de reescritura para las consultas. rewriteEngine on ## Pseudoroot DN. idassert-bind bindmethod=simple binddn="CN=proxymetadir,OU=SISTEMAS,OU=Usuarios,DC=gmv,DC=es" credentials="****" mode=none ######################################################################## ######################################################################## # Definicion de las reglas de reescritura a utilizar para el LDAP local. ######################################################################## ######################################################################## ## Ahora las reglas de reescritura del servidor LDAP que contiene ## los mapas de automount asi como los perfiles de Solaris y los ## netgroups de Unix. rwm-suffixmassage "ou=Profile,dc=gmv,dc=es" "ou=Profile,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "ou=Automount,dc=gmv,dc=es" "ou=Automount,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "ou=netgroup,dc=gmv,dc=es" "ou=Netgroup,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "automountmapname=auto_home,dc=gmv,dc=es" "automountmapname=auto_home,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "automountmapname=auto_master,dc=gmv,dc=es" "automountmapname=auto_master,ou=Unix,dc=gmv,dc=e s" rwm-suffixmassage "automountmapname=auto_direct,dc=gmv,dc=es" "automountmapname=auto_direct,ou=Unix,dc=gmv,dc=e s" rwm-map objectClass nisObject nisObject rwm-map objectClass nisNetgroup nisNetgroup rwm-map objectClass automountMap automountMap rwm-map objectClass automount automount rwm-map objectClass DUAConfigProfile DUAConfigProfile rwm-map attribute memberNisNetgroup memberNisNetgroup rwm-map attribute automountMapName automountMapName rwm-map attribute automountKey automountKey rwm-map attribute nisNetgroupTriple nisNetgroupTriple Thanks again, Eduardo. -----Mensaje original----- De: Eduardo Izaguirre Pazos Enviado el: viernes, 29 de febrero de 2008 13:28 Para: 'openldap-its(a)openldap.org' Asunto: ITS#5396 Another update about this problem. Connections between slpad and the remote active directory servers remains in ESTABLISHED state for a long time and changes to CLOSE_WAIT state in the slapd server. In the active directory servers the connections then changes to FIN_WAIT_2, so it seems the slapd server is not sending the FIN packet to close the socket. Cheers. Eduardo ________________________________ De: Eduardo Izaguirre Pazos Enviado el: jueves, 28 de febrero de 2008 13:21 Para: 'openldap-its(a)openldap.org' Asunto: ITS#5396 An update about the case, the problem seems to be related with the connections which remains in CLOSE_WAIT state, as an example: [root@metaldap openldap]# netstat -an | grep -i close | wc -l 11361 all these connections are to the remote ldap servers. Cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs