searching for attributes without index in 2.4.19 with bdb 4.5
by Christoph Herrmann
Hello,
after upgrading from openldap-2.3.39 with bdb-4.2.52 to openldap 2.4.19 with bdb-4.5
searching for attributes without index is about three times slower. (same machine, same
data, all data fit in DB cache)
Are there any known problems or magic tuning options we have missed?
regards
Christoph &:-)
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
13 years, 7 months
Re: Question about contextCSN's
by Ryan Steele
Rein Tollevik wrote:
> Ryan Steele wrote:
>> I'm replicating both the config and backend databases between two
>> boxes. Everything seems fine, but for some reason
>> when I query them both for the contextCSN, the config database returns
>> only one while the backend database returns two,
>> as seen below:
>
> The contextCSN attribute with any given sid is added to a database only
> after the server with that serverID modifies the database. The count of
> contextCSN values in a database does not need to reflect the number of
> master servers that could modify it, and it have no relation to the
> values in other databases.
>
> In your example, all modifications to cn=config was probably made on the
> first server (assuming it have serverID 1 that is). The example db have
> been modified by both.
>
> Rein
Thanks a lot for clarifying; I didn't realize that the contextCSN for each SID was added to a given database only after
being modified by that SID. And yes, I do understand that the different databases (e.g., backend and config) will have
different contextCSN's reflecting the last time they were written to, but my question was mostly about the same database
on different nodes. Namely, I thought that verifying whether replication was complete was done by comparing the
contextCSN's for the same database on each node (SID) in the replication group. That is, if replication is working,
each server to whom the given database is being replicated should have the same contextCSN for that database, to verify
that each received the same last write operation.
I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the
contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.:
contextCSN: 20100126210305.876171Z#000000#001#000000
contextCSN: 20100126210305.876171Z#000000#002#000000
Or should both nodes agree about the timestamps for each SID independently? E.g.:
### ldap1
contextCSN: 20100126210305.876171Z#000000#001#000000
contextCSN: 20091018205321.288716Z#000000#002#000000
### ldap2
contextCSN: 20100126210305.876171Z#000000#001#000000
contextCSN: 20091018205321.288716Z#000000#002#000000
It would intuitively seem to me that each node (SID) to whom the database is being replicated should have the same
contextCSN, so that one could verify the replication status by looking at the attribute values for each SID on one node,
instead of querying each node to see if the timestamp for each individual SID matched on every node. But, which is
correct? Thanks again for the insight.
Respectfully,
Ryan
13 years, 8 months
dynlist overlay and ldapsearch
by ben thielsen
hi-
i'm using the dynlist overlay and am not getting back the search results i expected. i'm using 2.4.11 courtesy of debian.
here is my overlay config:
>ldapsearch -xWLLLD 'cn=admin,cn=config' -b 'cn=config' "(objectclass=olcdynamiclist)"
dn: olcOverlay={5}dynlist,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcOverlay: {5}dynlist
olcDLattrSet: {0}groupOfNames memberURL member
olcDLattrSet: {1}mailGroup labeledURI
here is the entry in question:
>ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' -s base -b 'cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groundnoise,dc=net'
dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun
dnoise,dc=net
objectClass: mailGroup
objectClass: top
objectClass: extensibleObject
cn: abuse
member: cn=postmaster,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail
,dc=groundnoise,dc=net
labeledURI: ldap:///ou=domains,ou=mail,dc=groundnoise,dc=net?host?sub?(objectC
lass=mailDomain)
host: phone.dipswitch.net
host: luna.mpls.mn.us
host: groundnoise.net
host: thielsen.org
host: sjva1991.org
host: dipswitch.net
host: bitrate.net
searched for another way:
>ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(cn=abuse))' host
dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun
dnoise,dc=net
host: phone.dipswitch.net
host: luna.mpls.mn.us
host: groundnoise.net
host: thielsen.org
host: sjva1991.org
host: dipswitch.net
host: bitrate.net
however, the results from this search are missing that entry:
>ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(host=dipswitch.net)' dn
dn: host=dipswitch.net,ou=domains,ou=mail,dc=groundnoise,dc=net
or another search:
ldapsearch -xvWD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(host=*))' host
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
filter: (&(objectclass=mailgroup)(host=*))
requesting: host
# extended LDIF
#
# LDAPv3
# base <dc=groundnoise, dc=net> (default) with scope subtree
# filter: (&(objectclass=mailgroup)(host=*))
# requesting: host
#
# search result
search: 2
result: 0 Success
# numResponses: 1
if i remove the labeledURI attribute and populate with static entries, things appear to work as expected:
here's the entry:
>ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(cn=abuse))'
dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun
dnoise,dc=net
objectClass: mailGroup
objectClass: top
objectClass: extensibleObject
cn: abuse
member: cn=postmaster,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail
,dc=groundnoise,dc=net
host: foo
host: bar
host: com
host: net
host: org
and a search:
>ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(host=foo)' dn
dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun
dnoise,dc=net
what am i doing wrong?
thanks
-ben
13 years, 8 months
Need some help with OpenLDAP rights
by Guenter Knauf
Hi all,
I have a relatively simple requirement to grant some OpenLDAP rights ....
my OpenLDAP directory looks like that:
root
\
ou=managers
ou=webprojects
\
ou=groups
ou=users
now I need to grant full rights for users (InetOrgPerson) in ou=managers to ou=webprojects so that they can create/modify/delete users and groups in ou=groups,ou=webprojects and ou=users,ou=webprojects, also I would like to have users be able to modify their own entries.
For a start I tried some settings in slapd.conf, f.e.:
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to dn.base="ou=webprojects" by users write
access to *
by self write
by users read
by anonymous auth
>From my (most likely wrong) understanding this would mean that every user should be able to create/modify/delete every entry in and below ou=webprojects; but unfortunately this seems not the case. Instead I get all other sorts of whoes like 'error: need stronger encryption' when I try to login via non-ssl connection etc.
I really dont need ssl since in my case the manager users will always only login via web application on localhost, so nothing goes over the wire.
Can please someone tell about the proper access rules for my requirements?
thanks, Günter.
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
13 years, 8 months
startup error after converting to slapd-config
by Gerard Ranke
Dear all,
We run openLDAP 2.4.21 on one master plus 7 slaves. Some time ago ( I believe we were on 2.4.19 at
the time ), I converted one of the slaves to slapd-config from slapd.conf to get myself acquainted
with it, and that went without problems. Now, if I try the conversion with slaptest -f slapd.conf -F
slapd.d, the conversion works ok, but slapd won't start, and gives this error:
Jan 18 15:30:20 7E:example-slave slapd[1741992]: _sasl_plugin_load failed on sasl_auxprop_plug_init
for plugin: ldapdb
Jan 18 15:30:20 7U:example-slave slapd[1741992]: olcSyncrepl: value #0: <olcSyncrepl> invalid URL
Jan 18 15:30:20 7U:example-slave slapd[1741992]: config error processing
olcDatabase={1}hdb,cn=config: <olcSyncrepl> invalid URL
Jan 18 15:30:20 7U:example-slave slapd[1741992]: slapd stopped.
Jan 18 15:30:20 7U:example-slave slapd[1741992]: connections_destroy: nothing to destroy.
I noticed that the olcSyncrepl in olcDatabase={1}hdb,cn=config changed from:
olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout
=0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx
" starttls=critical filter="(objectClass=*)" searchbase="dc=example,dc=com" scope=
sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 10 +"
for the older openldap version, to:
olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 uri="" bindmethod=simple
timeout=0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx"
starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert
" tls_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr
/ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obj
ectClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=o
ff type=refreshAndPersist retry="5 5 10 +"
for 2.4.21.
Notice the ' uri="" ' in the last version.
Fortunately, if I remove the empty uri assignment from the ldif file, slapd starts normally. But I
still wondered if I have missed something, so if anyone can explain what happened, I would be very
grateful.
Best regards,
gerard
13 years, 8 months
fw: using the perl backend
by Brett ＠Google
Hello,
I am trying to find a way to drive a perl backend to receive changes from a
master.
Assume we have something like :
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
pidfile /data/openldap/run/slapd_log.pid
argsfile /data/openldap/run/slapd_log.args
database perl
suffix "dc=example,dc=com"
rootdn "cn=admin, dc=example, dc=com"
rootpw <mypass>
# log example module
perlModulePath /usr/local/perl-lib
perlModule MyPerlModule
loglevel 256
Which is pretty straightforward. In the ye olde days of 2.3.x there was
slurp, you could point a slurp at the above slap instance, and you could
perform custom perl code when changes were pushed incrementally to it by
slurp replication. It would appear that since syncrepl, as responsibility
for replication replication has moved from the server to the client, having
a somewhat "dumb" client now is not so easy.
It would appear out of the box that there is no (trivial) way with syncrepl
to push delta changes after a given epoch, towards a perl backend under
2.4.x ?
Slurp used to be able to push add/modify/delete operations, to a perl or
shell backend which could then "snoop" for interesting information.
Doing the same for syncrepl would seem to require maintainance of a full
syncrepl state (or replica), in order for a perl/shell backend to snoop for
interesting changes.
Anyone got any thoughts on this ?
Is there a way of getting syncrepl to emit simple add/modify/delete changes
(ala slurp-like) to a perl backend, without the prerequisite present search
?
Or maybe the perl backend in question would need to "fake" or pass through
syncrepl searches and responses, well enough to force syncrepl to either
always perform the prerequisite change, and/or perhaps only call the
add/modify/delete in the perl backend for leaf objects or other objects of
interest, maybe given a particular time epoch or starting date/time ?
Being able to call a perl (threaded) or shell backend (unthreaded) for
changes is a useful ability which seems to have apparently been lost in the
upgrade from 2.3.x to 2.4.x ??
The 2.4.x series seems to require a perl backend to require knowledge of
syncrepl, even if it's pushing to a perl backend on another server via a
"standalone ldap proxy".
Cheers
Brett
13 years, 8 months
Syncrepl Problem after repeatedly reboot
by HRZ Konten
Hallo all,
we have 2 OpenLDAP 2.4.17 with N-Way Replication on Debian Lenny.
Config
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW:: xxxxxxxxxxxxxxxxx
structuralObjectClass: olcDatabaseConfig
entryUUID: 446a8178-95f7-102e-8e9a-95c863b9a1ce
creatorsName: cn=config
createTimestamp: 20100115075644Z
olcSyncrepl: {0}rid=001 provider=ldaps://xxxxxxxxxxxxxxxx:636/ bindd
n="cn=config" bindmethod=simple credentials=xxxxxxxxxxxxxxxxxxx
searchbase="cn=confi
g" type=refreshAndPersist retry="5 5 300 +" schemachecking="on" timeout=3
olcSyncrepl: {1}rid=002 provider=xxxxxxxxxxxxxxxxxxxxxxxxxxx:636/ bindd
n="cn=config" bindmethod=simple credentials=xxxxxxxxxxxxxxxx
searchbase="cn=confi
g" type=refreshAndPersist retry="5 5 300 +" schemachecking="on" timeout=3
olcMirrorMode: TRUE
entryCSN: 20100115075655.626787Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20100115075655Z
We reboot one of the nodes a couple of times at the time as the other
node made ~ 60 000 adds.
After 12 hours there is still some difference between both nodes:
root@ldap1:~# ldapsearch -D "cn=manager,dc=xxx" -W -x -b "dc=xxx"
courseOfStudy=* | grep courseOfStudy | wc -l
Enter LDAP Password:
61125
root@ldap2:~# ldapsearch -D "cn=manager,dc=xxx" -W -x -b "dc=xxx"
courseOfStudy=* | grep courseOfStudy | wc -l
Enter LDAP Password:
47366
The contextCSN is equal on both nodes:
ldap1:
ldapsearch -xLLLH ldaps://ldap1:636 -s base -b "dc=xxx" contextCSN -W -D "cn=manager,xxx"
Result:
contextCSN: 20100121183644.034011Z#000000#000#000000
ldap2:
ldapsearch -xLLLH ldaps://ldap2:636 -s base -b "dc=uxxx" contextCSN -W -D "cn=manager,xxx"
Result:
contextCSN: 20100121183644.034011Z#000000#000#000000
Is there an easy way to force a new replication on the second node?
I will really appreciate your help...
13 years, 8 months
Re: Syncrepl Problem after repeatedly reboot
by HRZ Konten
Am 28.01.2010 13:00, schrieb openldap-software-request(a)OpenLDAP.org:
>> Is there any other way to check that? Then if I don't know that they are
>> > out of synchow could I start the rebuild of the second node...
>>
> To check the database content just slapcat both directories and do a
> diff.
>
Thank you, Dieter! The simple solutions are the best, I wonder why I
hadn't the same idea :)
> My multimaster tests of early 2.4 versions(2.4.11 + 2.4.12) had
> similar effects. While a node was down, heavy modifications, that is
> modify, delete and add operations, where made. But only the added
> objects where synchronised but not the modified and deleted
> objects.
It seems to me that there is something missed in the syncrepl if after
crash only adds are provided
> claim not to use n-way synchronisation. In most cases it is only bad
> directory design that leads to a request for multimaster systems.
> One-way synchronisation in combination with chaining is has the same
> effects as multimaster but is much more reliable.
>
Yes, maybe. We use Heartbeat to switch the Service-IP between the
masters, that's why we have always exactly one primary and one
secondary. The N-Way or MirrorMode in that case is usefull because we
don't have to switch between different master-slave configs for ldap,
but keeping two identical configs ....
Regards
Irina
13 years, 8 months
Re: Syncrepl Problem after repeatedly reboot
by HRZ Konten
>> Is there an easy way to force a new replication on the second node?
>> > I will really appreciate your help...
>>
> Just delete the database on the second node and setup a new node.
>
Well, that is rather a worst case scenario, but if this is the only was
to get them synced...
This situation is a little bit strange, then it says if the contextCSN
is equal then the systems are synced.
In my case I had equal contextCSN and diefferent number of entries and
no error message in the logs.
How could I be sure that my both nodes are synced?
Is there any other way to check that? Then if I don't know that they are
out of synchow could I start the rebuild of the second node...
13 years, 8 months
Question about contextCSN's
by Ryan Steele
I'm replicating both the config and backend databases between two boxes. Everything seems fine, but for some reason
when I query them both for the contextCSN, the config database returns only one while the backend database returns two,
as seen below:
## ldap1 replication config
olcDatabase={0}config.ldif:olcSyncrepl: {0}rid=001 provider=ldap://ldap1.example.com binddn="cn=admin,cn=co
olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type
olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1
olcDatabase={0}config.ldif:olcSyncrepl: {1}rid=002 provider=ldap://ldap2.example.com binddn="cn=admin,cn=co
olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type
olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {0}rid=003 provider=ldap://ldap1.example.com binddn="cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example,
olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {1}rid=004 provider=ldap://ldap2.example.com binddn="cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example,
olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1
## ldap2 replication config
olcDatabase={0}config.ldif:olcSyncrepl: {0}rid=001 provider=ldap://ldap1.example.com binddn="cn=admin,cn=co
olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type
olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1
olcDatabase={0}config.ldif:olcSyncrepl: {1}rid=002 provider=ldap://ldap2.example.com binddn="cn=admin,cn=co
olcDatabase={0}config.ldif- nfig" bindmethod=simple credentials="SECRET" searchbase="cn=config" type
olcDatabase={0}config.ldif- =refreshAndPersist retry="5 10 300 15" timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {0}rid=003 provider=ldap://ldap1.example.com binddn="cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example,
olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1
olcDatabase={1}hdb.ldif:olcSyncrepl: {1}rid=004 provider=ldap://ldap2.example.com binddn="cn=admin,dc=exa
olcDatabase={1}hdb.ldif- mple,dc=com" bindmethod=simple credentials="SECRET" searchbase="dc=example,
olcDatabase={1}hdb.ldif- dc=com" type=refreshAndPersist retry="5 10 300 15" timeout=1
## Query
root@ldap1:~# ldapsearch -x -H ldap://localhost -D 'cn=admin,cn=config' -y /etc/ldap.secret -b 'cn=config' -s base -LL
contextCSN; ldapsearch -x -H ldap://localhost -D 'cn=admin,dc=example,dc=com' -y /etc/ldap.secret -b 'dc=example,dc=com'
-s base -LL contextCSN
version: 1
dn: cn=config
contextCSN: 20091012205437.323661Z#000000#001#000000
version: 1
dn: dc=example,dc=com
contextCSN: 20100126210305.876171Z#000000#001#000000
contextCSN: 20091018205321.288716Z#000000#002#000000
I checked the documentation, but didn't see anything that clarified this behavior. I've also checked the logs, and
there are no replication failures in them. So what is the reason for this? The only difference I can see between the
config and backend is that the backend database has two overlays (autogroup and syncprov) and the config db has only one
(syncprov), but that may just be an irrelevant coincidence. I would be most appreciative if somebody could shed some
light on this for me. Thanks!
Respectfully,
Ryan
13 years, 8 months
