Questions about the Monitor Backend
by Thierry Lacoste
Hello,
I have recently upgraded from 2.3.24 to 2.4.16.
I find two points confusing in the "Monitor Backend" section
of the B annex "Upgrading from 2.3.x" in the admin guide
(http://www.openldap.org/doc/admin24/appendix-upgrading.html#Monitor%20Bac...
).
First my slapd happily starts even when I have no rootdn in my
"database monitor" section.
Second the example of the admin guide reads:
database monitor
rootdn cn=monitor
rootpw change_me
Is it on purpose that the rootdn equals the hadcoded suffix of the
monitor database?
In the "Monitor" section of the admin guide, the example reads:
database monitor
rootdn "cn=monitoring,cn=Monitor"
rootpw monitoring
The choice of the rootdn seems much more intuitive but then it seems
a bit weird to not use it in the ACL below:
access to dn.subtree="cn=Monitor"
by dn.exact="uid=Admin,dc=my,dc=org" write
by users read
by * none
Can someone please post his monitor configuration?
Regards,
Thierry
14 years, 7 months
Re: back-sql Varchar2 Primary Key Support
by deckrider＠gmail.com
Pierangelo Masarati wrote:
> > King, Leon C wrote:
> >
> > Hi all,
> >
> > Is there a way to wrap oracle functions to where clauses passed
> > into back-sql? I have a non-numeric primary key value of my
> > users' table which in some cases is preceeded by a '0'. None of
> > the data mapped via the ldap_entries.keyval and my table are
> > being retrieve when I execute an ldap search. If I remove the
> > preceeding '0' the values are retrieved.
>
> Manually edit servers/slapd/back-sql/back-sql.h and #define
> BACKSQL_ARBITRARY_KEY (it's #undef'd right now). This allows to use
> arbitrary keys (treated as strings) instead of integers. Note: it's not
> very well tested, and performances obviously may decrease (lots of
> mallocs/frees, more demanding comparisons and so).\
I need this also, but get a compile time error:
servers/slapd/back-sql/search.c:2420: error: invalid operands to binary
<< (have ‘struct berval’ and ‘int’)
14 years, 7 months
strange behavior of openldap: missing record in ldapsearch
by Zhang Weiwu
First there is a record with value that fits (businessCategory=C16.1*),
verified in STEP 1, second, searching with '(businessCategory=C16.1*)'
couldn't find it, demonstrated in STEP2.
===== STEP 1 =====
$ ldapsearch -xD uid=supertuxadmin,ou=contacts,ou=china,dc=ahk,dc=de -W -b ou=contacts,ou=china,dc=ahk,dc=de '(o=Homag Machinery * Co., Ltd.)' dn businessCategory
# extended LDIF
#
# LDAPv3
# base <ou=contacts,ou=china,dc=ahk,dc=de> with scope subtree
# filter: (o=Homag Machinery * Co., Ltd.)
# requesting: dn businessCategory
#
# SH0180, contacts, china, ahk.de
dn: uid=SH0180,ou=contacts,ou=china,dc=ahk,dc=de
businessCategory: C16.10 Sawmilling and planing of wood
businessCategory;lang-zh:: QzE2LjEwIOmUr+acqOWPiuWIqOacqA==
businessCategory;lang-de:: QzE2LjEwIFPDpGdlLSwgSG9iZWwtIHVuZCBIb2x6aW1wcsOkZ25
pZXJ3ZXJrZQ==
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
===== STEP 2 =====
$ ldapsearch -xD uid=supertuxadmin,ou=contacts,ou=china,dc=ahk,dc=de -W -b ou=contacts,ou=china,dc=ahk,dc=de '(businesscategory=C16.1*)' dn
# extended LDIF
#
# LDAPv3
# base <ou=contacts,ou=china,dc=ahk,dc=de> with scope subtree
# filter: (businesscategory=C16.1*)
# requesting: dn
#
# German_Perfect_2, contacts, china, ahk.de
dn: uid=German_Perfect_2,ou=contacts,ou=china,dc=ahk,dc=de
# Keenmax, contacts, china, ahk.de
dn: uid=Keenmax,ou=contacts,ou=china,dc=ahk,dc=de
# SH1625, contacts, china, ahk.de
dn: uid=SH1625,ou=contacts,ou=china,dc=ahk,dc=de
# id6505, contacts, china, ahk.de
dn: uid=id6505,ou=contacts,ou=china,dc=ahk,dc=de
# Davidyang1981, contacts, china, ahk.de
dn: uid=Davidyang1981,ou=contacts,ou=china,dc=ahk,dc=de
# search result
search: 2
result: 0 Success
# numResponses: 6
# numEntries: 5
======== FINISH ======
I expected to see uid=SH0180,ou=contacts,ou=china,dc=ahk,dc=de in the
search result in step 2 but couldn't. Similiar problem happen on
commonName as well, on both of our two installations, one is running
2.4.9 and the other 2.3.30. Both using hdb.
It is totally confusing to me that I don't even know where to start look
for the problem. Should I also attach full slapd.conf?
Thanks for any input in advance. I am totally clueless now, even after
running the installation for 3 years it's the first time see such
frastrating situation. Thanks.
Best regards
Zhang Weiwu
14 years, 7 months
Re: openldap2.4.16 and BDB4.7 not sync configured as provider/consumer
by Rodrigo Costa
Quanah,
Thanks a lot!
The replication is just fine after loading the LDIF with operational
attributes. No overload in consumer to sync database now.
Regards,
Rodrigo.
Quanah Gibson-Mount wrote:
> --On Thursday, May 07, 2009 10:36 AM -0700 Rodrigo Costa
> <rlvcosta(a)yahoo.com> wrote:
>
>>
>> Quanah,
>>
>> My understanding is that attrs doesn't need to exist in config since by
>> default all attributes are shared.
>
> I think that is what I said. You should not specify the attrs= line
> in the syncrepl stanza on the replica, and just use the default. That
> way, the entire database is replicated in full to the replica.
>
>> My original plan was to remove some tasks from the provider, like
>> backup, running a slapcat in the consumer(slave). Based in the
>> requirement to load the consumer(slave) using a master LDIF dump I'm not
>> sure if this is really feasible.
>
> Why is it a requirement to use a master LDIF dump? I never said that.
> What I said, is that you are required to have a fully formed LDIF file
> to load LDAP servers that will be syncing (I.e., an LDIF file with the
> operational attributes, vs a generated LDIF file from a program that
> is missing them.). If you do a slapcat from an existing server, then
> it should be fully formed.
>
>> My idea was :
>> 1)Have a provider/consumer running;
>> 2)Execute LDIF and binary backups in the consumer(slave)
>> 3)In a case of problem in the master just let a HA SW move the master to
>> slave and then load "old master" using the slave LDIF file(recovering
>> procedure).
>>
>> Is this feasible?
>
> Yes, this is pretty standard procedure, minus the binary backups. You
> could of course just set up mirror mode or multi-master, as well...
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
14 years, 7 months
Re: openldap2.4.16 and BDB4.7 not sync configured as provider/consumer
by Rodrigo Costa
Quanah,
My understanding is that attrs doesn't need to exist in config since by
default all attributes are shared.
My original plan was to remove some tasks from the provider, like
backup, running a slapcat in the consumer(slave). Based in the
requirement to load the consumer(slave) using a master LDIF dump I'm not
sure if this is really feasible.
My idea was :
1)Have a provider/consumer running;
2)Execute LDIF and binary backups in the consumer(slave)
3)In a case of problem in the master just let a HA SW move the master to
slave and then load "old master" using the slave LDIF file(recovering
procedure).
Is this feasible? Could for replication purposes copy the binary bdb
files from master to slave or vice-verse to recover system?
Regards,
Rodrigo.
Regards,
Rodrigo.
Quanah Gibson-Mount wrote:
> --On Wednesday, May 06, 2009 1:55 PM -0700 John Du <jjohndu(a)gmail.com>
> wrote:
>
>
>> Is it necessary to explicitly specify the '+' in slapd.conf to replicate
>> operational attributes?
>>
>
> You shouldn't specify the "attrs=" line in slapd.conf at all, unless
> you only want to replicate a subset of attributes. The default is
> usually all you want. But yes, if you plan on doing replication, and
> want it to work, and you are going to specify the attrs= line, then
> you better include "+" in there.
>
> --Quanah --
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
14 years, 7 months
Re: openldap2.4.16 and BDB4.7 not sync configured as provider/consumer
by Rodrigo Costa
Buchan,
I made exactly what you said even using the -q flag in the slapadd
command. So in summary I did :
1) Load the master DB using LDIF file through slapdd(-q flag and
DB_CACHEZIZE to 1GB);
2) Load the slave DB using LDIF(same) file through slapdd(-q flag and
DB_CACHEZIZE to 1GB);
3)Then have the slapd.conf files appropriately configured
4)Start master and then after some minutes start slave.
So the slave is not starting blank but exactly loaded and in terms of
data there isn't any difference between provider(master) and
consumer(slave). I just see when the consumer slapd process start at
slave machine(slapd started with -d 256 flag) the connection from the
consumer to the provider slapd process.
Then all behavior explained start to happen. Please see the provider and
consumer configuration file attached.
Something appears not being following the expect behavior. Also the
memory consumed in the consumer is growing too fast and doesn't appear
to really follow the caches directives.
Regards,
Rodrigo.
Buchan Milne wrote:
> On Sunday 03 May 2009 04:15:47 Rodrigo Costa wrote:
>
>> openldap software,
>>
>> Sometime ago I open the ITS#5860 about some memory cache limitations not
>> being respected by config files. Even this issue was solved when I tried
>> to configured openldap to use replication(syncrepl) the system never
>> enter into sync and the behavior appears similar to the ITS#5860 bug.
>>
>> The system start to sync and in the provider(master) I see the query for
>> the DB sync. But the consumer(slave) memory consumption start to grow
>> very fast making me to constrain much more the dncachesize to a 1/10 of
>> the size of the provider(master) where at least system doesn't crash at
>> consumer.
>>
>> Since changes were done in the openldap 2.4.16 I download and made tests
>> with this version. I get into the same behavior with consumer(slave)
>> never getting in sync with provider(master).
>>
>> The behaviors are :
>>
>> 1) Consumer(slave) start query to the provider(master) DB;
>> 2) Memory allocation and number of threads in the provider(master) start
>> to increase as expected;
>> 3) dncachesize directive into provider(master) controls as expected the
>> maximum memory to be allocated by slapd process in provider(master);
>> 4) Consumer(slave) consumer memory in a much faster pace. dncachesize
>> configured to 1/10 of provider(master) to avoid memory allocation problems;
>> 5) After sometime the consumer(slave) CPU usage maintains in 200%.
>> Provider(master) stays with low CPU usage, around 1 to 3 %;
>> 6) A new provisioning in provider(master) isn't propagated to
>> consumer(slave);
>> 7) Bases never get in sync and CPU usage in consumer still high. Queries
>> to provider(master) are answer very fast and even multiple individual
>> queries to consumer(slave) are also answer in reasonable time.
>>
>> It looks like could exist certain issue in the replication logic where
>> some processing dead loop could be found by the replication
>> consumer(slave) logic.
>>
>> The newest openldap version and Berkeley DB 4.7 with all patches were
>> compiled in the platform running the code.
>>
>> Any idea about this behavior?
>>
>
> I have seen behaviour like this when there was something preventing
> synchronisation, and the comsumer would spawn more consumer threads, until the
> box ran out of memory. I fixed the real issue, and haven't seen it since (and
> haven't had time to try and reproduce it).
>
> However, on a large database, you may have better success by initialising the
> consumer via 'slapadd' with an export from a provider, instead of using
> syncrepl to do it. Since slapadd can run multiple threads (syncrepl only runs
> one thread), and doesn't need to bother serving client requests, and can run
> without transactions (see -q flag), it is much more efficient.
>
> Note that you could consider different tuning for import vs run-time, e.g. I
> usually increase the BDB cache_size for imports with slapadd, and decrease it
> for runtime.
>
> Regards,
> Buchan
>
>
>
>
>
14 years, 7 months
Let "self" create new entries
by Wolfgang Lorenz
Hello,
I'm quite new to LDAP and at the moment I'm really just playing around,
and trying to learn how to configure and use OpenLDAP correctly.
So I set up some kind of a small address directory, as could be used by
my family to have a central place, where addresses can be stored, just
to keep in contact. The setup looks like this:
# reading out data as authenticated user
access to dn.children="ou=people,dc=example,dc=org"
by self write
by users read
access to dn.base="ou=people,dc=example,dc=org"
by users read
access to dn.base="dc=example,dc=org"
by users read
This seems to work, fine: I can log in, using my dn
uid=wolfgang,ou=people,dc=example,dc=org
and I can change my details, and view the details of the other uids.
Then I thought, it would be nice to be able, to create my own address
books within my "self" contact. Such as
ou=adrbook01,uid=wolfgang,ou=people,dc=example,dc=org
and have in there contacts, that can only be shown by me. All other
users should be able to do the same thing, of course. So I tried to
create the new ou=adrbook01 entry and got a "no write access to entry".
As I understand it, I may only add and change attributes, that lie
within my binddn.
So, now my question is, how can I configure slapd to enable users, to
build their own subtrees, without having to give a rule for every
single uid, that lies within ou=people?
Thanks in advance,
Wolfgang
14 years, 7 months
Re: openldap2.4.16 and BDB4.7 not sync configured as provider/consumer
by Rodrigo Costa
Quanah,
This means I cannot use the same original LDIF file to load in parallel
the master and slave at the same time.
I need to load the master, then slapcat it and then finally load the
slave to have a correct startup. Just confirming the procedure.
Regards,
Rodrigo.
Quanah Gibson-Mount wrote:
> --On Tuesday, May 05, 2009 6:50 PM -0700 Rodrigo Costa
> <rlvcosta(a)yahoo.com> wrote:
>
>> Buchan,
>>
>> I made exactly what you said even using the -q flag in the slapadd
>> command. So in summary I did :
>>
>> 1) Load the master DB using LDIF file through slapdd(-q flag and
>> DB_CACHEZIZE to 1GB);
>> 2) Load the slave DB using LDIF(same) file through slapdd(-q flag and
>> DB_CACHEZIZE to 1GB);
>> 3)Then have the slapd.conf files appropriately configured
>> 4)Start master and then after some minutes start slave.
>
> Unless the LDIF was a valid export from a master, you should have
> slapcat'd the master after step 1, and used that LDIF to load the
> replica in step 2.
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
14 years, 7 months
Re: slapd-meta and paged results control
by Quanah Gibson-Mount
--On Tuesday, May 05, 2009 9:46 PM +0200 Lajos Boróczki
<boroczki.lajos(a)gmail.com> wrote:
> I forgot to include: 2.4.11
Please keep your replies on the list.
I'd suggest you try a newer release of OpenLDAP (2.4.16 is the current
stable release).
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
14 years, 7 months
sync problem
by Leonardo Carneiro
Hi everyone,
i'm no ldap expert at all. in fact i'm very noob.
a few months ago i'd configured 2 ldap servers. they were set in 2
separated networks, and syncronized via a openvpn link. all was working
ok when when about a month ago they stop syncing. the replogfile is empty.
main server (piece of slapd.conf):
replogfile /var/lib/ldap/openldap-master-replog
replica host=192.168.0.2:389
binddn="cn=root,dc=dominio,dc=com,dc=br"
bindmethod=simple credentials=[pass]
secondary server (piece of slapd.conf)
updatedn "cn=root,dc=dominio,dc=com,dc=br"
updateref ldap://192.168.1.2:380
Sorry about my poor english, i'm from brasil.
--
*Leonardo de Souza Carneiro*
*Veltrac - Tecnologia em Logística.*
lscarneiro(a)veltrac.com.br <mailto:lscarneiro@veltrac.com.br>
http://www.veltrac.com.br <http://www.veltrac.com.br/>
/Fone Com.: (43)2105-5600/
/Av. Higienópolis 1601 Ed. Eurocenter Sl. 803/
/Londrina- PR/
/Cep: 86015-010/
/Esta mensagem pode conter informação confidencial e/ou privilegiada./
/Se você recebeu esta mensagem por engano, por favor avise imediatamente
o remetente, respondendo o e-mail e em seguida apague-o./
/This message may contain confidential and/or privileged information./
/If you have received this message in error, please advise the sender
immediately by reply e-mail and delete this message./
14 years, 7 months
