- openldap-bugs - openldap.org

RE: Adding new Attribute in OpenLdap (ITS#5423)
by vijayaragavanp＠zenithsoft.com 14 Mar '08

14 Mar '08

i was't able to find the manual ,can you please send me the link -----Original Message----- From: Pierangelo Masarati [mailto:openldap-its@OpenLDAP.org] Sent: Friday, March 14, 2008 2:46 PM To: vijayaragavanp(a)zenithsoft.com Subject: Re: Adding new Attribute in OpenLdap (ITS#5423) > how to add custom attributes in OpenLdap As clearly explained in the manual. p.

1 0

(ITS#5424) pwdGraceLoginLimit only mentioned, not documented in slapo-ppolicy
by ghenry＠OpenLDAP.org 14 Mar '08

14 Mar '08

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry "(please refer to the pwdGraceLoginLimit password policy attribute)" Nothing else mentioned. Gavin.

1 0

(ITS#5423) Adding new Attribute in OpenLdap
by vijayaragavanp＠zenithsoft.com 13 Mar '08

13 Mar '08

Full_Name: vijayaragavanp Version: 2.0 OS: yes URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.30.128.168) how to add custom attributes in OpenLdap

1 0

(ITS#5422) strerror(errno) problems
by h.b.furuseth＠usit.uio.no 13 Mar '08

13 Mar '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "grep -i strerror" shows some places <strerror/STRERROR>(errno) are passed to Debug(). However Debug() can evaluate its arguments twice: for -d output and syslog. Thus it can syslog the wrong message, since the -d stdio call can change errno. Also strerror() can return NULL, which can break with Debug(%s). STRERROR() fixes that, but not the duplicate call. And strerror too can change errno:-( So the STRERROR() variant #elif defined( HAVE_STRERROR ) #define STRERROR(e) ( strerror(e) ? strerror(e) : _AC_ERRNO_UNKNOWN ) in include/ac/errno.h isn't quite safe either. I suggest we put something like below in ac/string.h or ac/errno.h, then we can usually say if (whatever) { DEF_STRERROR(msg, errno); Debug(..., msg, ...); } ac/something.h: #define DEF_STRERROR(msg, err) \ DECL_STRERROR(msg); \ SET_STRERROR(msg, err) #ifdef HAVE_SYS_ERRLIST #define DECL_STRERROR(msg) \ unsigned int msg##_err_; \ const char *msg #define SET_STRERROR(msg, err) \ ((void)(msg = (msg##_err_ = (e)) < (unsigned) sys_nerr \ ? sys_errlist[msg##_err_] : _AC_ERRNO_UNKNOWN)) #elif <threaded> && defined( HAVE_NONPOSIX_STRERROR_R ) #define DECL_STRERROR(msg) \ char msg##_buf_[80]; \ const char *msg #define SET_STRERROR(msg, err) \ ((void) ((msg = strerror_r(err, msg##_buf_, 80)) || \ (msg = _AC_ERRNO_UNKNOWN))) #elif <threaded> && defined( HAVE_STRERROR_R ) #define DECL_STRERROR(msg) \ char msg##_buf_[80]; \ const char *msg #define SET_STRERROR(msg, err) \ ((void) (msg = strerror_r(err, msg##_buf_, 80) != -1 \ ? msg##_buf_ : _AC_ERRNO_UNKNOWN)) #elif defined( HAVE_STRERROR ) #define DECL_STRERROR(msg) \ const char *msg #define SET_STRERROR(msg, err) \ ((void) ((msg = strerror(err)) || (msg = _AC_ERRNO_UNKNOWN))) #else #define DECL_STRERROR(msg) const char *msg #define SET_STRERROR(msg, err) ((void) (msg = "Unknown error")) #endif Don't know what the #if <threaded> test should look like, see ITS#5421.

1 0

(ITS#5421) slapd vs LDAP_R_COMPILE
by h.b.furuseth＠usit.uio.no 13 Mar '08

13 Mar '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Some slapd source files include libldap/ldap-int.h, which contains #ifdef LDAP_R_COMPILE in structs. slapd links libldap_r but does not define LDAP_R_COMPILE, so these files have access to bad struct definitions. A quick grep doesn't show any use cases though. Anyway: Either #ifdef LDAP_R_COMPILE in libldap(_r)should be something else, or we should define LDAP_R_COMPILE in slapd - maybe like this: --- slap.h 13 Mar 2008 13:37:07 +++ slap.h 13 Mar 2008 16:40:25 @@ -28,4 +28,10 @@ #define _SLAP_H_ +#if defined _LDAP_INT_H +# error include slap.h before ldap-int.h +#elif !defined NO_THREADS +# define LDAP_R_COMPILE 1 +#endif + #include "ldap_defaults.h"

1 0

Re: (ITS#5416) slapd core dump
by ando＠sys-net.it 13 Mar '08

13 Mar '08

rui.yan(a)gmail.com wrote: > 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 You should provide: - your slapd.conf - the LDIF of the modification that caused the issue - the contents of some variables from gdb: (gdb) frame 4 (gdb) print nocs (gdb) print values (gdb) print values[0] 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#5420) test048-syncrepl-multiproxy: ldapsearch failed at P1 slave (32)!
by hyc＠symas.com 13 Mar '08

13 Mar '08

Dup of ITS#5419. michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: OpenSUSE Linux 10.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.68.253) > > > make test fails with current HEAD synced right now. > > michael@nb2:~/src/openldap/HEAD/openldap/tests> ./run -b bdb test048 > Cleaning up test run directory leftover from previous run. > 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)! > > > -- -- 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#5420) test048-syncrepl-multiproxy: ldapsearch failed at P1 slave (32)!
by michael＠stroeder.com 13 Mar '08

13 Mar '08

Full_Name: Michael Ströder Version: HEAD OS: OpenSUSE Linux 10.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.68.253) make test fails with current HEAD synced right now. michael@nb2:~/src/openldap/HEAD/openldap/tests> ./run -b bdb test048 Cleaning up test run directory leftover from previous run. 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)!

1 0

Re: (ITS#5419) test048 fails...
by h.b.furuseth＠usit.uio.no 13 Mar '08

13 Mar '08

hyc(a)symas.com writes: > op->o_bd is essentially supposed to be a constant once it is set on an > operation. Operations within a backend are generally not allowed to > access other backends so it should not be overriding the backend that > was given to it. "grep -n -e '.->o_bd *=[^=]' *.c */*.c" finds 10 from 'orig'something. Some of the other 202 matches also restore an old o_bd. -- Hallvard

1 0

Re: (ITS#5419) test048 fails...
by hyc＠symas.com 13 Mar '08

13 Mar '08

luca(a)OpenLDAP.org wrote: > 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 Yes, I see this as well. syncrepl is trying to use backend_attribute() to retrieve the underlying DB's contextCSN, but backend_attribute is discarding the current op->o_bd and using select_backend() to pick which backend to query. This is definitely the wrong behavior; op->o_bd is essentially supposed to be a constant once it is set on an operation. Operations within a backend are generally not allowed to access other backends so it should not be overriding the backend that was given to it. -- -- 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#5391) hdb deadlock
by h.b.furuseth＠usit.uio.no 13 Mar '08

13 Mar '08

hyc(a)symas.com writes: >Hallvard B Furuseth wrote: >> 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. Whoops, good point. > 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. I don't think Berkeley DB writes a checkpoint record then, at least I don't see that in the docs. If not, #bytes do help keep recovery and checkpoint times down. Anyway, unless you are proposing to ignore the #bytes parameter: If this is a Berkeley DB bug we could hear what they say, and in the meantime put a mutex_trylock around checpoints. Unless db has some feature which defeats that, like if txn_checkpoint() merely schedules a checkpoint. #define CHECKPOINT_WORKAROUND /* hopefully an ITS#5391 workaround */ struct bdb_info { ... #ifdef CHECKPOINT_WORKAROUND # ldap_pvt_thread_mutex_t bi_checkpoint_mutex; #define CHECKPOINT_LOCK(op, bdb) op(&(bdb)->bi_checkpoint_mutex) #else #define CHECKPOINT_LOCK(op, bdb) 0 #endif ... }; #define TXN_CHECKPOINT(bdb, k, m, f) do { \ if ( CHECKPOINT_LOCK( ldap_pvt_thread_mutex_trylock, bdb ) == 0 ) { \ (bdb)->bi_dbenv->txn_checkpoint( (bdb)->bi_dbenv, k, m, f ); \ (void) CHECKPOINT_LOCK( ldap_pvt_thread_mutex_unlock, bdb ); \ } \ } while (0) -- Hallvard

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by jclarke＠linagora.com 13 Mar '08

13 Mar '08

Hi, michael(a)stroeder.com a écrit : > I'd be interested to add support for something like this to my LDAP client. > > BTW: I'd vote against ";x-allowed" or ";x-required" since a schema-aware > client can already determine this in a non-proprietary way from the subschema. > > The overlay's source is quite old. Does it still build with recent HEAD? I'm also interested in an overlay of this type. I started hacking into it recently, and don't remember any problems getting it to build on HEAD (a couple of months ago). This was related to an implementation of Get Effective Rights [1], which returns rights the current user has on each attribute in an object. I had a premilinary working version, but it did not work as a control, just returned extra attributes. Similarly, this would be useful to LDAP GUI clients. If you're interested, I could dig out the code. [1] http://directory.fedoraproject.org/wiki/Get_Effective_Rights_Design and http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-ldapext-acl-model-08.t… Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs