openldap-bugs July 2007

openldap-bugs@openldap.org

30 participants
126 discussions

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

Quanah Gibson-Mount wrote: > --On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.37 >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (66.92.25.194) >>> >>> >>> When using cn=config with a slapd.conf driven slapd, the value for >>> olcLogLevel is not correct: >>> >>> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >>> olcLogLevel >>> Enter LDAP Password: >>> dn: cn=config >>> olcLogLevel: None >>> >>> However: >>> >>> grep loglevel conf/slapd.conf >>> loglevel 32768 >>> >>> And the logging that is happening is actually for level 32768. >>> Modifying the loglevel works, and once that is done, the right loglevel >>> is shown. However, this makes it impossible to know what loglevel is >>> set via a remote query unless it has been changed. >> >>> From slapd.conf(5), loglevel: >> 32768 (0x8000 none) only messages that get logged >> whatever log level is set >> >> Seems to be correct. > > Yet if I modify it to be "256", then olcLogLevel is "256". If I modify > it to be "32768", then it is "32768". That's because in EMIT the loglevel goes through loglevel2bvarray(), which turns the level into an array of pretty values. You're supposed to modify the loglevel by adding multiple values, each with the descriptive name of the level you're using. The use of loglevel with OR'ed integers is stylistically deprecated. > So if the loglevel setting in > slapd.conf is "32768", then that is what it should match. In any case, > "None" has the unfortunate ring of sounding like an unset value. In LDAP, if the value were unset, the attribute would be missing, which is what you get if, for example, you set loglevel to 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#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

--On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.37 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (66.92.25.194) >> >> >> When using cn=config with a slapd.conf driven slapd, the value for >> olcLogLevel is not correct: >> >> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >> olcLogLevel >> Enter LDAP Password: >> dn: cn=config >> olcLogLevel: None >> >> However: >> >> grep loglevel conf/slapd.conf >> loglevel 32768 >> >> And the logging that is happening is actually for level 32768. >> Modifying the loglevel works, and once that is done, the right loglevel >> is shown. However, this makes it impossible to know what loglevel is >> set via a remote query unless it has been changed. > >> From slapd.conf(5), loglevel: > 32768 (0x8000 none) only messages that get logged > whatever log level is set > > Seems to be correct. Yet if I modify it to be "256", then olcLogLevel is "256". If I modify it to be "32768", then it is "32768". So if the loglevel setting in slapd.conf is "32768", then that is what it should match. In any case, "None" has the unfortunate ring of sounding like an unset value. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > When using cn=config with a slapd.conf driven slapd, the value for olcLogLevel > is not correct: > > ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W > olcLogLevel > Enter LDAP Password: > dn: cn=config > olcLogLevel: None > > However: > > grep loglevel conf/slapd.conf > loglevel 32768 > > And the logging that is happening is actually for level 32768. Modifying the > loglevel works, and once that is done, the right loglevel is shown. However, > this makes it impossible to know what loglevel is set via a remote query unless > it has been changed. >From slapd.conf(5), loglevel: 32768 (0x8000 none) only messages that get logged whatever log level is set Seems to be correct. 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#5068) buglet in charray.c
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

--On July 30, 2007 9:28:06 PM +0000 mb(a)g10code.com wrote: > Full_Name: Marcus Brinkmann > Version: 2.1.30 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.123.156.61) OpenLDAP 2.1 is no longer a supported release. The current release branch is OpenLDAP 2.3. Please do not file ITSes on dead releases. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5068) buglet in charray.c
by mb＠g10code.com 30 Jul '07

30 Jul '07

Full_Name: Marcus Brinkmann Version: 2.1.30 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.123.156.61) This fixes a warning and seems locally correct. I did not check the expected semantics of this code. Thanks, Marcus. diff -ru openldap2-2.1.30-orig/libraries/libldap/charray.c openldap2-2.1.30/libraries/libldap/charray.c --- openldap2-2.1.30-orig/libraries/libldap/charray.c 2003-03-03 18:10:04.000000000 +0100 +++ openldap2-2.1.30/libraries/libldap/charray.c 2007-07-30 23:24:30.000000000 +0200 @@ -183,7 +183,7 @@ i = 1; for ( s = str; *s; s++ ) { - if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { + if ( ldap_utf8_strchr( brkstr, *s ) != NULL ) { i++; } }

1 0

(ITS#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) When using cn=config with a slapd.conf driven slapd, the value for olcLogLevel is not correct: ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W olcLogLevel Enter LDAP Password: dn: cn=config olcLogLevel: None However: grep loglevel conf/slapd.conf loglevel 32768 And the logging that is happening is actually for level 32768. Modifying the loglevel works, and once that is done, the right loglevel is shown. However, this makes it impossible to know what loglevel is set via a remote query unless it has been changed.

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de 30 Jul '07

30 Jul '07

Hi Gavin, I just uploaded a patch for my contribution as Sebastian-Hetze-070630.patch (sorry for the wrong date) The adpwc as contributed has a dependency to samba3.schema to be present, which is fixed with this patch. The patch also makes adpwc fold realm names to upper case since AD stores them mixed case and gives tickets upper case. I introduced a new config option adpw-cache-keep-realm-case to keep the old behaviour if needed. It looks like I cannot add this patch to ticket #5042, so I ask you to attach it if possible. Thanx alot, Sebastian On Thu, Jul 19, 2007 at 09:48:58AM +0000, Gavin Henry wrote: > Hi, > > This looks like it is in the correct format for our contrib section. Just > testing is needed. As I don't have access to an Active Directory server I can't > test. > > Anyone else? > > Gavin. -- Sebastian Hetze Mitglied des Vorstands Linux Information Systems AG Ehrenbergstr. 19, D-10245 Berlin Fon: +49 30 726238-0, Fax: +49 30 726238-99 s.hetze(a)linux-ag.com, http://www.linux-ag.com ---------------------------------------------------------- Sitz der Gesellschaft: Stefan-George-Ring 8, 81929 München Amtsgericht München: HRB 128 019 Vorstand: Rudolf Strobl, Sebastian Hetze Aufsichtsrat: Michael Tarabochia (Vorsitzender)

1 0

(ITS#5066) ldap error :server down
by jalali_azam＠yahoo.com 30 Jul '07

30 Jul '07

Full_Name: Azam Jalali Version: 2.2.29 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.207.237.38) I installed openldap 2.2.9 and set sldap.conf as following: /////////////////////////////////////////////////////////////////////////// ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/nis.schema include ./schema/dyngroup.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory ./data # Indices to maintain index objectClass eq access to attr=userpassword by anonymous auth by self write by dn="cn=Manager,dc=my-domain,dc=com" write by * none access to * by dn="cn=Manager,dc=my-domain,dc=com" write by users write by self write by * read by * write /////////////////////////////////////////////////////////////////////////// After running some query on this openldap i got ldap error:server down. This event occurs every time i reinstalled it and ran some query on it? How i fix this error? Thanks in advance Azam Jalali

1 0

Slapd doesn't start after update
by ツ Leandro Sales 27 Jul '07

27 Jul '07

Hello folks... I update the openldap from version 2.2.28-r7 to 2.3.35-r1 using emerge. After update the slapd deamon didn't start. I enabled the log and realized that the problem was the incompatible version of the database. I then downgrade to the 2.2.28 version and when I started slapd I got the message: "/usr/lib64/openldap/slapd: error while loading shared libraries: liblber-2.3.so.0: cannot open shared object file: No such file or directory". I then reinstall and this problem doesn't happen anymore, but slapd still doesn't start and print the following messages in the log file: Jul 27 17:55:11 embedded slapd[2957]: bdb_db_init: Initializing BDB database Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): Program version 4.5 doesn't match environment version 0.22 Jul 27 17:55:11 embedded slapd[2958]: bdb_db_open: dbenv_open failed: DB_VERSION_MISMATCH: Database environment version mismatch (-30972) Jul 27 17:55:11 embedded slapd[2958]: backend_startup: bi_db_open failed! (-30972) Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): txn_checkpoint interface requires an environment configured for the transaction subsystem Jul 27 17:55:11 embedded slapd[2958]: bdb_db_destroy: txn_checkpoint failed: Invalid argument (22) Please, help me on this. []s Leandro.

2 1

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it 27 Jul '07

27 Jul '07

ando(a)sys-net.it wrote: > What would make things totally different is the persistence of a problem > in 2.3 and 2.4. But the very existence of a problem has to be proven > yet. If you look at my analysis with dntest, you'll see that your DN I confirm that using the schema extracted from <ldap://cclcgtopbdii01.in2p3.fr:2170/>, 2.3/2.4 slapdn can successfully handle the offending DN: $ slapdn \ 'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid' DN: <GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid> check succeeded normalized: <GlueVOViewLocalID=/vo\3Dswetest/group\3D/swetest/role\3Dswadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,Mds-Vo-name=uporto,Mds-Vo-name=local,o=grid> pretty: <GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,Mds-Vo-name=UPorto,Mds-Vo-name=local,o=grid> I'd consider this ITS closed. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2007