Re: config_back_db_open and "cannot assess the validity of the ACL scope" in openldap-devel

[Pierangelo Masarati]

Gavin Henry wrote:

Hi all,

Just playing in openldap-devel, with the next step being mirrormode, and
get this warning when running slapd with debug on:

config_back_db_open: line 0: warning: cannot assess the validity of
the ACL scope within backend naming context

So is this a seperate assessment outwith the normal syntax one?

I don't quite understand the warning.
  
That's quite informative, and issued at a very verbose log level.  
Basically, the ACL parsing code checks whether a rule will actually be 
used with the scope it can potentially apply to.  For example, if you 
place a rule


access to dn.subtree="" by * read

within a database with suffix "dc=example,dc=com", the rule might 
potentially apply to any DN, but since it's placed within a database 
with a non-empty suffix, it will only apply to 
dn.subtree="dc=example,dc=com".  So the ACL designer might be fooled 
into believing that it will apply to any entry while it won't.  This 
doesn't mean that the ACL is wrong: it will do what's intended for; 
that's why the warning is informative.  In some cases, the ACL parsing 
code cannot determine the scope of a rule (for example, when regular 
expressions are involved); this causes the specific warning you see.  If 
you understood the ACL syntax and you believe your ACLs are correct, you 
can safely ignore that warning.


p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
--
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:[EMAIL PROTECTED]
--

Re: Searches lagging at end of search

[Pierangelo Masarati]

Jeremiah Martell wrote:

Hello,

  Here's the situation. I'm using openldap-2.2.17, libldap.

  I bind to the server, successfully. I do a search, successfully. I
unbind, successfully.

  However, when I watch this process with ethereal I notice something
wrong. All the search results are coming back almost immediately (2
seconds), but my code still hangs on the ldap_search call for up to
20-30 seconds.

  Is this a known bug that I need to upgrade my openldap? Has anybody
seen this behavior before? Anybody have any idea what could be going
wrong?
Is that behavior reproducible with ldapsearch(1) (the command-line 
tool)?  It sounds like you're running a non-indexed search, where all 
the database is scanned for entries matching the filter, while those 
that match are stored at the beginning (by chance, I guess). In any 
case, I'd upgrade to the latest 2.3, given the improvements and bug 
fixes libldap received.


p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
--
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:[EMAIL PROTECTED]
--

Re: qmail.schema: line 55: Inconsistent duplicate attributeType: "mailHost"

[Pierangelo Masarati]

Dave Horsfall wrote:

On Tue, 15 Aug 2006, Anthony wrote:

  

# /usr/local/etc/rc.d/slapd start
Starting slapd.
/usr/local/etc/openldap/schema/qmail.schema: line 55: Inconsistent duplicate
attributeType: "mailHost"



Did you include "misc.schema" as well?  I note that it's defined in there 
too.
  
The definition in misc.schema is taken from 
 which expired long ago.  
I note that qmail guys modified it to allow substrings searches, which 
might be required by qmail.  Since they seem to be using their own OID 
space, they simply "stealed" the name of the attribute (a better 
practice would have been to prefix everything with "qmail" instead of 
"mail"?  You may run into similar problems with "mailQuota" and 
"mailAlternateAddress", which have already been used by other popular 
schemas).  In any case, you should either avoid including misc.schema, 
or modify qmail.schema to comply
with existing schema items with the same short names (and possibly break 
the need for substring searches in qmail; in any case, what seems to be 
broken here is qmail's schema, based on the fact that "mailHost" was 
around way before qmail ever existed, as far as I can tell).


p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
--
Office:   +39.02.23998309
Mobile:   +39.333.4963172
Email:[EMAIL PROTECTED]
--

Re: slurpd not replicating to slave at root

[Buchan Milne]

On Wednesday 16 August 2006 19:18, Steven Wong wrote:
> I was wondering if this is correct or if I have my access or config wrong.
>
> It seems that only "cn=manager,dc=pro-unlimited,dc=com", which is the
> rootdn can create a new child at the root level ( ie.
> ou=netgroup,dc=pro-unlimited,dc=com ) and my replica uses
> binddn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com"
>
> [EMAIL PROTECTED] openldap]# ldapadd -x -D
> "uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" -w  -a
> -f /tmp/netg adding new entry "ou=netgroup,dc=pro-unlimited,dc=com"
> ldap_add: Insufficient access
> additional info: no write access to parent
>
> ldif_record() = 50
> [EMAIL PROTECTED] openldap]# ldapadd -x -D
> "uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" -w 
> -a -f /tmp/netg adding new entry "ou=netgroup,dc=pro-unlimited,dc=com"
> ldap_add: Insufficient access
> additional info: no write access to parent
>
> ldif_record() = 50
>
> If I were to use uid=replicator/sysadmin to add things under
> ou=hosts/people, I am able to add them fine.
>
> Does that mean, my only choice to get around this, such that sync can
> happen, even at the top level, is to use the rootdn as the binddn?

No, it is preferable *not* to use the rootdn as replicadn, and it is entirely 
possible to have it replicate any change in the directory, if your ACLs allow 
it.

> If there are any info needed, please let me know.

A list of your ACLs would help.

Regards,
Buchan

-- 
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI74592)


pgpxowYkgjDF6.pgp
Description: PGP signature

Re: Correct procedure to backup LDAP?

[Roger Thomas]

Quoting Quanah Gibson-Mount <[EMAIL PROTECTED]>:

> Why in the world are you using ldbm?  It is a known problematic
> database 
> that has been removed from OpenLDAP 2.4, so it is not portable going
> 
> forward.  I highly advise using one of the supported backends (bdb or
> hdb).

Am currently running the old 2.0.5 on ldbm. Now how do I upgrade to 2.4? I mean 
how do I convert my existing records in ldbm format to bdb or hdb?

I am no expert, please go slow. TIA.

--
Roger


---
Sign Up for free Email at http://ureg.home.net.my/
---

Re: config_back_db_open and "cannot assess the validity of the ACL scope" in openldap-devel

[Gavin Henry]

> Gavin Henry wrote:
>> Hi all,
>>
>> Just playing in openldap-devel, with the next step being mirrormode, and
>> get this warning when running slapd with debug on:
>>
>> config_back_db_open: line 0: warning: cannot assess the validity of
>> the ACL scope within backend naming context
>>
>> So is this a seperate assessment outwith the normal syntax one?
>>
>> I don't quite understand the warning.
>>
> That's quite informative, and issued at a very verbose log level.
> Basically, the ACL parsing code checks whether a rule will actually be
> used with the scope it can potentially apply to.  For example, if you
> place a rule
>
> access to dn.subtree="" by * read
>
> within a database with suffix "dc=example,dc=com", the rule might
> potentially apply to any DN, but since it's placed within a database
> with a non-empty suffix, it will only apply to
> dn.subtree="dc=example,dc=com".  So the ACL designer might be fooled
> into believing that it will apply to any entry while it won't.  This
> doesn't mean that the ACL is wrong: it will do what's intended for;
> that's why the warning is informative.  In some cases, the ACL parsing
> code cannot determine the scope of a rule (for example, when regular
> expressions are involved); this causes the specific warning you see.  If
> you understood the ACL syntax and you believe your ACLs are correct, you
> can safely ignore that warning.

Understood, thanks.

Gavin.

>
> p.
>
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.n.c.
> Via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> --
> Office:   +39.02.23998309
> Mobile:   +39.333.4963172
> Email:[EMAIL PROTECTED]
> --
>
>

Re: slurpd not replicating to slave at root

[Steven Wong]

Hi Buchan,
Here is the ACL's from one of the slaves

access to dn.regex=".*,dc=pro-unlimited,dc=com"
  attrs=userPassword
  by self write
  by dn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" write
  by dn="uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" write
  by * auth

access to dn.regex=".*,dc=pro-unlimited,dc=com"
  attrs=shadowLastChange
  by self write
  by dn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" write
  by dn="uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" write
  by * read

access to dn.regex=".*,dc=pro-unlimited,dc=com"
  by dn="uid=proxyuser,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" read
  by dn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" write
  by dn="uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" write
  by * read


Thanks,
Steven

- Original Message 
From: Buchan Milne <[EMAIL PROTECTED]>
To: Steven Wong <[EMAIL PROTECTED]>
Cc: openLDAP software 
Sent: Thursday, August 17, 2006 12:07:57 AM
Subject: Re: slurpd not replicating to slave at root

On Wednesday 16 August 2006 19:18, Steven Wong wrote:
> I was wondering if this is correct or if I have my access or config wrong.
>
> It seems that only "cn=manager,dc=pro-unlimited,dc=com", which is the
> rootdn can create a new child at the root level ( ie.
> ou=netgroup,dc=pro-unlimited,dc=com ) and my replica uses
> binddn="uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com"
>
> [EMAIL PROTECTED] openldap]# ldapadd -x -D
> "uid=sysadmin,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" -w  -a
> -f /tmp/netg adding new entry "ou=netgroup,dc=pro-unlimited,dc=com"
> ldap_add: Insufficient access
> additional info: no write access to parent
>
> ldif_record() = 50
> [EMAIL PROTECTED] openldap]# ldapadd -x -D
> "uid=replicator,ou=ldapbods,ou=people,dc=pro-unlimited,dc=com" -w 
> -a -f /tmp/netg adding new entry "ou=netgroup,dc=pro-unlimited,dc=com"
> ldap_add: Insufficient access
> additional info: no write access to parent
>
> ldif_record() = 50
>
> If I were to use uid=replicator/sysadmin to add things under
> ou=hosts/people, I am able to add them fine.
>
> Does that mean, my only choice to get around this, such that sync can
> happen, even at the top level, is to use the rootdn as the binddn?

No, it is preferable *not* to use the rootdn as replicadn, and it is entirely 
possible to have it replicate any change in the directory, if your ACLs allow 
it.

> If there are any info needed, please let me know.

A list of your ACLs would help.

Regards,
Buchan

-- 
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI74592)

DB_CONFIG not being read.....

[Amith Varghese]

I'm running FC-3 with OpenLDAP RPMS (v. 2.2.29).  Recently, my backend  
was corrupted which caused me to rebuild the database.  After doing  
some research, I learned the BDB backend was the "preferred" backend  
and that support for ldbm is on the way out.  So I converted to the  
BDB format using slapcat/slapadd and a new configuration file.   
Everything converted fine, but I'm now experiencing  worse performance  
that I did with the ldbm backend.


I've read the online docs about how to tune the BDB backend and added  
the following parameters to my slapd.conf file


directory   /var/lib/ldap
cachesize 10
checkpoint 1024 5

In my /var/lib/ldap/DB_CONFIG file I have the following set:

set_cachesize   0 104857600  1
set_lg_regionmax1048576
set_lg_max  10485760
set_lg_bsize2097152

However, when I use slapd_db_stat to look at the BDB backend  
statistics, I see the following:


264KB 48B   Total cache size
1   Number of caches
272KB   Pool individual cache size
212781  Requested pages found in the cache (88%)



It looks like the backend is using some kind of default (264KB)  
instead of the 100MB I specified.  Does anyone know why this may be  
happening?  Hopefully someone can point out an obvious mistake I'm  
making.


Thanks
Amith

Re: Correct procedure to backup LDAP?

[Quanah Gibson-Mount]

--On Thursday, August 17, 2006 3:08 PM +0800 Roger Thomas 
<[EMAIL PROTECTED]> wrote:



Quoting Quanah Gibson-Mount <[EMAIL PROTECTED]>:


Why in the world are you using ldbm?  It is a known problematic
database
that has been removed from OpenLDAP 2.4, so it is not portable going

forward.  I highly advise using one of the supported backends (bdb or
hdb).


Am currently running the old 2.0.5 on ldbm. Now how do I upgrade to 2.4?
I mean how do I convert my existing records in ldbm format to bdb or hdb?

I am no expert, please go slow. TIA.


Well, to start, I wouldn't go to 2.4 quite yet, it is only in alpha.  But I 
would upgrade to 2.3.25+.


To upgrade, you will need to export your database into LDIF format, either 
via ldapsearch or slapcat.


Then you'll need to import that LDIF file into a server running the newer 
version of OpenLDAP (preferably with slapadd).  I will note that OL 2.0 was 
not very strict on data validation, so you may need to clean up the data in 
your LDIF file some before an import will work correctly.


You'll also need to set up a slapd.conf file that corresponds to the newer 
syntaxes in 2.3.  Reading the Admin Guide & Quickstart Guide @ 
 is probably a good start for that.


--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Re: DB_CONFIG not being read.....

[Quanah Gibson-Mount]

--On Thursday, August 17, 2006 1:09 PM -0400 Amith Varghese 
<[EMAIL PROTECTED]> wrote:



I'm running FC-3 with OpenLDAP RPMS (v. 2.2.29).  Recently, my backend
was corrupted which caused me to rebuild the database.  After doing  some
research, I learned the BDB backend was the "preferred" backend  and that
support for ldbm is on the way out.  So I converted to the  BDB format
using slapcat/slapadd and a new configuration file.   Everything
converted fine, but I'm now experiencing  worse performance  that I did
with the ldbm backend.

I've read the online docs about how to tune the BDB backend and added
the following parameters to my slapd.conf file

directory   /var/lib/ldap
cachesize 10
checkpoint 1024 5

In my /var/lib/ldap/DB_CONFIG file I have the following set:

set_cachesize   0 104857600  1
set_lg_regionmax1048576
set_lg_max  10485760
set_lg_bsize2097152

However, when I use slapd_db_stat to look at the BDB backend  statistics,
I see the following:

264KB 48B   Total cache size
1   Number of caches
272KB   Pool individual cache size
212781  Requested pages found in the cache (88%)



It looks like the backend is using some kind of default (264KB)  instead
of the 100MB I specified.  Does anyone know why this may be  happening?
Hopefully someone can point out an obvious mistake I'm  making.



Did you stop slapd and run db_recover with the correct version of 
db_recover after creating the DB_CONFIG file?  It is only read one time, at 
the creation of the DB environment.


I'll also note that 2.2.29 is very old, and I believe RH FC3 links it 
against BDB 4.3, which has seemed rather unstable in comparison to BDB 4.2 
or BDB 4.4.  You probably want to investigate using Buchan Milne's 
packages, or a pre-packaged distribution like is available from Symas 
Corporation ().


--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Should BerkeleyDB 4.3 be used along with latest OpenLDAP 2.3 series?

[(LI Xin)]

Hello,

Recently I have received some claims that says OpenLDAP 2.3.x (latest
stable) does not work well with OpenLDAP 2.3 series, and it is better to
use BDB 4.2.x instead of 4.3.x to archive better stability and/or
performance.  After some Google search against the mailing list archive,
the only clue I can find to support the claim is in mid-2005.  Moreover,
the FAQ did not say that 4.3 is not encouraged[1] (nor encouraged,
though), so this makes me confused.

Is the situation still hold true?  Because I maintained the OpenLDAP
port for FreeBSD I think it would be better if we get a stable
out-of-the-box installation, and because I did not encountered a single
problem which looks like bdb related, I would like to hear some
"official" information from developers, and make a change if necessary.

Thanks in advance!

Cheers,
-- 
Xin LI http://www.delphij.net/


signature.asc
Description: 	这是信件的数	字签名部分

Re: DB_CONFIG not being read.....

[Amith Varghese]

Quoting Quanah Gibson-Mount <[EMAIL PROTECTED]>:


Did you stop slapd and run db_recover with the correct version of
db_recover after creating the DB_CONFIG file?  It is only read one
time, at the creation of the DB environment.


Nope, this was it though.  Thanks for the quick help.



I'll also note that 2.2.29 is very old, and I believe RH FC3 links it
against BDB 4.3, which has seemed rather unstable in comparison to BDB
4.2 or BDB 4.4.  You probably want to investigate using Buchan Milne's
packages, or a pre-packaged distribution like is available from Symas
Corporation ().


Again, thanks for the information.

Amith

Re: Should BerkeleyDB 4.3 be used along with latest OpenLDAP 2.3 series?

[matthew sporleder]

On 8/17/06, 李鑫 (LI Xin) <[EMAIL PROTECTED]> wrote:

Hello,

Recently I have received some claims that says OpenLDAP 2.3.x (latest
stable) does not work well with OpenLDAP 2.3 series, and it is better to
use BDB 4.2.x instead of 4.3.x to archive better stability and/or
performance.  After some Google search against the mailing list archive,
the only clue I can find to support the claim is in mid-2005.  Moreover,
the FAQ did not say that 4.3 is not encouraged[1] (nor encouraged,
though), so this makes me confused.

Is the situation still hold true?  Because I maintained the OpenLDAP
port for FreeBSD I think it would be better if we get a stable
out-of-the-box installation, and because I did not encountered a single
problem which looks like bdb related, I would like to hear some
"official" information from developers, and make a change if necessary.

Thanks in advance!

Cheers,
--
Xin LI http://www.delphij.net/


The recommended version of BDB (according to this list) is 4.2.52 +
patches.  4.4 is showing promise, and 4.3 has shown problems, so it is
not recommended.  For details, keep searching the list archives.

slapadd: database doesn't support necessary operations

[Andreas Hasenack]

REL_ENG_2_3 from a few hours ago (labeled as 2.3.26)

I get this error when trying to slapadd an ldif file with the -w option
on a database that is glue'd:

# slapadd -b dc=example,dc=com -w -v -g < remote1.ldif 
slapadd: database doesn't support necessary operations.

(same without -g)

Since I'm having lots of problems with syncrepl in a cascading setup +
glued databases, I was wondering if the above error is expected in this
setup or could help diagnose my other issues.

tool threads

[Eric Irrgang]

In OpenLDAP 2.3.24 and 2.3.25 the tool-threads parameter has the desired effect 
when running slapadd or slapindex on an hdb only when using the '-q' flag. 
Without the '-q' flag, I only get one thread running.  Is that the intended 
behavior or is this a bug?


This is with 64-bit builds on Sparc Solaris on UltraSparc 3 and UltraT1 
and BDB 4.4.20 with the four current patches.


--
Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

Re: tool threads

[Howard Chu]

Eric Irrgang wrote:
In OpenLDAP 2.3.24 and 2.3.25 the tool-threads parameter has the 
desired effect when running slapadd or slapindex on an hdb only when 
using the '-q' flag. Without the '-q' flag, I only get one thread 
running.  Is that the intended behavior or is this a bug?


This is with 64-bit builds on Sparc Solaris on UltraSparc 3 and 
UltraT1 and BDB 4.4.20 with the four current patches.



That's the intended behavior.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sunhttp://highlandsun.com/hyc
 OpenLDAP Core Teamhttp://www.openldap.org/project/

Re: Correct procedure to backup LDAP?

[Roger Thomas]

Quoting Quanah Gibson-Mount <[EMAIL PROTECTED]>:

> 
> 
> --On Thursday, August 17, 2006 3:08 PM +0800 Roger Thomas 
> <[EMAIL PROTECTED]> wrote:
> 
> > Quoting Quanah Gibson-Mount <[EMAIL PROTECTED]>:
> >
> >> Why in the world are you using ldbm?  It is a known problematic
> >> database
> >> that has been removed from OpenLDAP 2.4, so it is not portable
> going
> >>
> >> forward.  I highly advise using one of the supported backends (bdb
> or
> >> hdb).
> >
> > Am currently running the old 2.0.5 on ldbm. Now how do I upgrade to
> 2.4?
> > I mean how do I convert my existing records in ldbm format to bdb
> or hdb?
> >
> > I am no expert, please go slow. TIA.
> 
> Well, to start, I wouldn't go to 2.4 quite yet, it is only in alpha. 
> But I 
> would upgrade to 2.3.25+.
> 
> To upgrade, you will need to export your database into LDIF format,
> either 
> via ldapsearch or slapcat.
> 
> Then you'll need to import that LDIF file into a server running the
> newer 
> version of OpenLDAP (preferably with slapadd).  I will note that OL
> 2.0 was 
> not very strict on data validation, so you may need to clean up the
> data in 
> your LDIF file some before an import will work correctly.

OK. I think it shouldn't be too difficult to perform the export and import 
stuff. What I am dead worried is the validation stuff. Can you provide some 
example as to why a validation process would fail and how to correct them?


> You'll also need to set up a slapd.conf file that corresponds to the
> newer 
> syntaxes in 2.3.  Reading the Admin Guide & Quickstart Guide @ 
>  is probably a good start for that.
> 
> --Quanah
> 
> 
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITS/Shared Application Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
> 


--
Roger


---
Sign Up for free Email at http://ureg.home.net.my/
---