Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it
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
---------------------------------------
16 years, 4 months
Re: (ITS#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com
--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
16 years, 4 months
Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it
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
---------------------------------------
16 years, 4 months
Re: (ITS#5068) buglet in charray.c
by quanah＠zimbra.com
--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
16 years, 4 months
(ITS#5068) buglet in charray.c
by mb＠g10code.com
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++;
}
}
16 years, 4 months
(ITS#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com
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.
16 years, 4 months
Re: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de
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)
16 years, 4 months
(ITS#5066) ldap error :server down
by jalali_azam＠yahoo.com
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
16 years, 4 months
Slapd doesn't start after update
by ツ Leandro Sales
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.
16 years, 4 months
Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it
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
---------------------------------------
16 years, 4 months
