openldap-software

openldap-software@openldap.org

2719 discussions

loglevel/logfile
by Edgar Fuß 28 Oct '09

28 Oct '09

I was somewhat surprised to learn from reading the source that while the loglevel directive controls the level of logging done via syslog, the level of logging done to the file specified via the logfile directive is solely controlled via the parameter given do -d on the command line (leaving Windows Registry aside). Is this observation correct? Is this documented? Is there a sane way to write to logfile and still deamonize?

1 0

refint overlay not working
by lee_yiu_chung＠yahoo.com 25 Oct '09

25 Oct '09

Hi, I have a question about refint overlay. Situation: I have a ldap server maintaining a ldap tree of users, groups and email aliases like this: --------------------------------------------------- dn: uid=user_a,ou=users,dc=example,dc=com mail:user_a@example.com dn: uid=user_b,ou=users,dc=example,dc=com mail:user_b@example.com dn: cn=group_a,ou=groups,dc=example,dc=com member: uid=user_a,ou=users,dc=example,dc=com dn: cn=group_b,ou=groups,dc=example,dc=com member: uid=user_b,ou=users,dc=example,dc=com dn: cn=alias_a,ou=emailAliases,dc=example,dc=com member: uid=user_a,ou=users,dc=example,dc=com member: uid=group_b,ou=users,dc=example,dc=com dn: cn=alias_b,ou=emailAliases,dc=example,dc=com member: uid=user_b,ou=users,dc=example,dc=com member: uid=group_a,ou=users,dc=example,dc=com --------------------------------------------------- Now, I have configured my SMTP server (specifically, postfix) to read email aliases from LDAP, and let postfix to recursively expand email aliases from ou=emailAliases,dc=example,dc=com until actual email address is resolved. (no problem here). But, when I need to rename the user/group, I have to manually update the corresponding alias, and I figured refint overlay would be useful for me. I tried, but seems that it just do nothing. Below is my configuration. Did I missed something? Thank you very much. ------------------------- slapd.conf allow bind_v2 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema #include /etc/ldap/schema/nis.schema include /etc/ldap/schema/rfc2307bis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/mozillaabpersonalpha.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/hdb.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_hdb moduleload refint sizelimit 500 tool-threads 1 sasl-secprops minssf=0 sasl-realm EXAMPLE.COM sasl-host foo.example.com sasl-regexp "gidNumber=.*\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=heimdal,dc=example,dc=com" authz-regexp "uid=root,cn=gssapi,cn=auth" "cn=admin,dc=example,dc=com" authz-regexp "uid=(.*),cn=example.com,cn=gssapi,cn=auth" "uid=$1,ou=users,dc=example,dc=com" backend hdb database config rootpw secret database hdb suffix "dc=example,dc=com" directory "/var/lib/ldap" dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectClass eq index ou eq index uidNumber eq index gidNumber eq index cn,sn,givenName eq,sub index mail eq,sub index uid eq,sub index memberUid,member eq index uniqueMember eq index displayName eq,sub index labeledURI eq index entryUUID eq index createTimestamp,modifyTimestamp eq index mozillaNickname sub index mozillaSecondEmail sub index nsAIMid sub index mozillaHomeLocalityName sub index mozillaHomeState sub index mozillaHomePostalCode sub index mozillaHomeCountryName sub index mailLocalAddress eq index krb5PrincipalName eq lastmod on checkpoint 512 30 (ACL omitted) overlay refint refint_attributes member refint_nothing "cn=admin"

1 0

What does it means in slave? SyncRepl 2.4.19
by Nacho Díaz Asenjo 25 Oct '09

25 Oct '09

Hi! Yesterday, I upgraded my servers to Openldap 2.4.19, but in slave server i have some problems with synrepl. I can't make replica work, and i only can see this message continuosly. Oct 24 14:34:55 xxxx slapd[3657]: syncrepl_message_to_entry: rid=002 mods check (mail: value #0 provided more than once) Oct 24 14:34:55 xxxx slapd[3657]: do_syncrepl: rid=002 rc 20 retrying (9 retries left) What does it means? Another question it's about GNU/Linux Debian 5.0. I upgraded from Etch to Lenny and the slapadd operation with a 100 MB LDIF took about 1h and the same operation in a Etch (Debian 4.0) usually takes only 5 minutes. Anyone knows why?. I made tests with Berkeley DB 4.6 and Berkeley DB 4.4 and i obtained a similar result. Thanks for your atencion.

1 0

MirrorMode/N-Way Multi-Master Replication Clarification
by Alan Evans 24 Oct '09

24 Oct '09

There is another thread "MirrorMode and chaining - are slaves needed?" which has caused me some confusion about MirrorMode and N-Way Multi-Master Replication. Is the difference between MirrorMode and N-Way Multi-Master the number of nodes? 2 nodes = Mirror Mode, 3+ nodes = Multi-Master? But both use the exact same configuration? If this is the case the documentation does not make this clear at all and using the MirrorMode directive in N-Way Multi-Master is very confusing. Why not "MirrorMode On" OR "MultiMaster On" ?? Is there a way to use two nodes in N-Way Multi-Master replication?

5 5

Re: syncrepl problem with 2.4.19
by Serge Dubrouski 23 Oct '09

23 Oct '09

On Wed, Oct 21, 2009 at 4:30 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, October 21, 2009 10:48 PM +0200 Dieter Kluenter > <dieter(a)dkluenter.de> wrote: > >> I found that disable logging on provider and consumers solved most of >> my problems. in addition you should check the number of waiters and >> increase the number of threads if required. > > This is not a solution, this is a workaround. The underlying problem should > be investigated and resolved. If you've seen this, you should have filed an > ITS. So it is a confirmed bug? I was planning an upgrade from 2.4.13 to 2.4.19 but now it sounds like I should wait. Was an ITS created for this bug? -- Serge Dubrouski.

2 1

Re: Mirror Mode, replicas and delta-syncrepl
by Sam Tran 23 Oct '09

23 Oct '09

On Thu, Oct 22, 2009 at 10:30 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, October 22, 2009 9:37 PM -0400 Sam Tran <stlist(a)gmail.com> > wrote: > >> I was planning to use the load balancer in the 2nd configuration as >> well. In both cases only a single master will receive the write >> requests. The 2nd configuration would still work in the event of a >> failure of the load balancer. > > > I don't know if delta-syncrepl can handle two syncrepl statements getting > the same data. I would think that would cause a lot of problems. Although > I guess it would know it already got that change? I'm curious to know the > results of your experiments. ;) > Based on your last post on this thread: http://archive.netbsd.se/?ml=OpenLDAP-software&a=2009-03&t=10149068 I thought the replicas would be able to handle two masters in a mirror mode configuration. Did I miss something?

1 0

question: dynamic groups / reverse group membership
by Andreas Schoe 23 Oct '09

23 Oct '09

Hello, one question about dynamic groups. Explanation: I think the configuration of dynamic groups is more flexible than the static method (memberof). I can create any ldapserch to get a list depending on all kind of attributes or objectclasses. If I configure the reverse group membership overlay I have to use the dn of the group and the dn of the entry. To change the objectclasses on which the memberof attribute depends or change the attribute name on which the dn depends is possible, but thats it. Example (static): dn: cn=testgroup,ou=Groups,dc=example uniqueMember: uid=testuser,ou=People,dc=example ... dn: uid=testuser,ou=People,dc=example memberOf: cn=testgroup,ou=Groups,dc=example ... In that example the configuration is for both sides. If I add a Member to cn=testgroup the memberOf is add to uid=testuser and if I add a Group to uid=testuser the uniqueMember is add to cn=testgroup. Example (dynamic): dn: cn=testgroup,ou=Groups,dc=example labeldURI: ldap:///ou=people,dc=example??one?(&(objectclass=person)(departmentNumber=test)) uniqueMember: uid=testuser,ou=People,dc=example ... dn: uid=testuser,ou=People,dc=example departmentNumber: test ... In that example the group attribute (departementNumber) is mapped to a specific groupname (cn). With static groups I can do a search like that: ldapsearch -h ldap -b dc=example '(uniquemember=uid=testuser,ou=People,dc=example)' dn With dynamic groups the search result is empty because the entry (uniquemember) doesn't exists in the underlying DB. Question: Is it possible to copy/configure the behavior from dynamic groups to reverse group membership? I have some applications that use searches with '(uniquemember=uid={uid},dc=example)'. These applications need the static entries.

3 2

Re: Mirror Mode, replicas and delta-syncrepl
by Sam Tran 22 Oct '09

22 Oct '09

On Thu, Oct 22, 2009 at 6:47 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, October 22, 2009 4:34 PM -0400 Sam Tran <stlist(a)gmail.com> > wrote: > >> Hi All, >> >> I am looking to upgrade our OL 2.3 platform to OL 2.4. >> >> For all write operations, I'd like to have two masters in Mirror Mode >> configuration and behind a load balancer with a virtual IP (VIP) >> address. All read operations will be performed on a set of replicas. >> The replication mode would be delta-syncrepl. I am trying to figure >> out how to configure replication between the replicas and the masters. >> I came across those two threads that seem to address this issue: >> >> http://www.openldap.org/lists/openldap-devel/200903/msg00085.html >> http://www.openldap.org/lists/openldap-software/200903/msg00127.html >> >> If I understand correctly, there are two possible configurations: >> >> 1) On each replica, create a single syncrepl stanza that points to the >> load balancer VIP. >> >> 2) On each replica, creates two syncrepl stanzas, each one pointing to >> a different master. >> >> Could you please confirm that both configurations would work? Should >> the second configuration be favored over the first for it does not >> depend on the load balancer? > > I don't know the answer, but let me know when you figure it out. ;) I'd > guess the first option would be best, since only one master will be > receiving the writes as well, since you'll be using mirror mode. > I was planning to use the load balancer in the 2nd configuration as well. In both cases only a single master will receive the write requests. The 2nd configuration would still work in the event of a failure of the load balancer.

2 1

Re: Syncrepl, syncprov, and contextCSN.
by Tim Stewart 22 Oct '09

22 Oct '09

(This is the continuation of a direct email conversation with Rein Tollevik that instead belongs on this list) Rein, On Oct 22, 2009, at 6:01 AM, Rein Tollevik wrote: > Tim Stewart wrote: > >> I ran across one of your messages on openldap-devel entitled >> "contextCSN interaction between syncrepl and syncprov" at this >> location: >> http://www.openldap.org/lists/openldap-devel/200903/msg00024.html > > This haven't been implemented yet, but a configuration like the one > you have should still work if properly configured. > >> I was wondering if the fix you are discussing has made it into the >> OpenLDAP source anywhere. I think I may be experiencing the same >> issue. Here is my configuration: >> Site 1 Site 2 >> ------ ------ >> Master for Master for >> ou=site1,dc=example,dc=org ou=site2,dc=example,dc=org >> Slave for Slave for >> dc=example,dc=org dc=example,dc=org >> (inlcuding ou=site2) (including ou=site1) >> \ / >> \ / >> ---------- ------------ >> \ / >> | >> Main Site >> --------- >> Master for >> dc=example,dc=org >> Slave for >> ou=site1,dc=example,dc=org >> Slave for >> ou=site2,dc=example,dc=org > > Assuming all the databases are glued together under > dc=example,dc=org, this is a configuration similar to the one we > use, and which is tested in test058. There are comments in that > test scripts that describes the configuration. To succeed, you must > ensure that: > > Syncrepl on site1 and site2 is configured on dc=example,dc=org. The > rootdn used on this backend must differ from the rootdn on the > locally mastered backend, other backend should use the same rootdn > as the top dc=example,dc=org. I.e, on site1, all backends *except* > ou=site1 should have the same rootdn. > > On the master, syncrepl must be configured on each of the ou=site1 > and ou=site1 backends, *not* the superior dc=example,dc=org. ACL > rules should be used to prevent the user syncrepl on site1 > authenticates as from reading the ou=site1 backend it itself is > master for, and similar for site2. Hmm, I'm not sure I understand this point fully. Could you try stating it another way so my feeble brain can have another go? > Finally, it is *vital* that differing serverID directive values are > used on each of the servers! Nor should any of them have a serverID > of 0. Look at the contextCSN attribute (should be in > dc=example,dc=org). You should have three values with differing > serverID field (second to last). Other than the ACLs above, the configuration you have described is identical to what I have configured and is now working (see two comments below for my mistake). I am about to extend my tests by adding sites 3, 4, and 5. I'll let you know how it goes. > Oh, and a final final note :-) Only the main site can be master for > more than one backend, site1 and site2 are restricted to only be > master for ou=site1 and ou=site2 respectively. This is the main > problem which the message you referred to outlines a fix for. You have confirmed what I thought was the case from reading your emails and the bug report. I emailed you initially because I didn't feel that my particular setup should trigger what you described and I was afraid my understanding was incomplete. >> During a large initial import, ou=site1 is properly replicated over >> to Site 2 but ou=site2 is *not* properly replicated to Site 1 (or >> the other way around, depending on the order items are added). > > Provided your configuration is as outlined above, *and* the initial > replication is not interrupted but runs to its completion, it should > succeed. Oh, if you slapadd ldif data, this must already include the > operational attributes of the entries (entryUUID etc), or it must be > imported only on the server which is the master for the data. site1 > and site2 needs the top-level dc=example,dc=org entry in their > database before importing the backend they are master for, so that > they have somewhere to store their contextCSN attribute. You should > also ensure that a contextCSN with the servers local serverID have > been stored before starting replicating from them (any modification > to their locally mastered backend should fix that). I was wrong. I was impatient and did not allow the daemons enough time to sync. I have learned to be patient and the replication has worked every time since. I am using ldapadd to populate the tree online and the data is about 3MB. Thank you for the assistance. -- -TimS Tim Stewart Stoo Research tim(a)stoo.org

1 0

Loading LDIF into a new mirrormode setup
by Peter Mogensen 22 Oct '09

22 Oct '09

Hi, I'm trying to optimize loading a huge LDIF file (several Gb) into a clean mirrormode setup. As of now, I don't have hardware with RAM enough to hold the whole database, but I've reach useable performance when setting olcDbLinearIndex: TRUE and running (on Server1): # slapdadd -q -w -l database.ldif and then # slapindex -q -t Now, the only thing missing is for Server2 to replicate the entire database from Server1. This is however a bit slow, so I'm wondering if I could do better by loading the database on both servers from start, and if there's any special things to worry about regarding entryCSN. Also: The LDIF is from another setup running slapd 2.3.x, so the entryCSN values are the old format and the SID values are different. Should I use -S with slapadd to set the ServerID to 1/2 when loading? /Peter

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software