openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Re: High load times with mdb
by Bill MacAllister 08 Jul '13

08 Jul '13

--On Tuesday, June 25, 2013 12:58:54 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, June 25, 2013 12:38 PM -0700 Bill MacAllister <whm(a)stanford.edu> wrote: > >> The load starts out at a rate of about 2 M/s. In the past I remember >> that dropping to something like 900 k/s and staying there. Now the >> load starts in the same place, but after 30 seconds it alternates >> between stalling out right, and a rate under 100 k/s. Dips as low as >> under 10 k/s and sometimes as high at 700 k/s. (My undergraduate >> degree was in watching water boil.) > > What is the partition type? ext4? > > What options are set for the partition in fstab? This is what I am currently using. The UUID are obviously shortened for readability. UUID=blah1 / ext4 defaults,acl,noatime,errors=remount-ro 0 1 UUID=blah2 /var/cache/openafs ext4 defaults,noatime 0 2 UUID=blah3 /var/lib/ldap ext4 defaults,noatime 0 2 UUID=blah4 none swap sw 0 0 I also tried ext3 with the same results. This is on a raid-1. I have also tried splitting the two disks and putting the OS on one and the LDAP database on the other. None of this moved the problem. It really has the feel of a resource exhaustion. The load is now stalled in that the progress display is not updating. top does not show slapd as doing anything. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

2 6

proxying read/write request to secounday ldap server
by val john 08 Jul '13

08 Jul '13

Hi.. guys We have primary ldap called ,ldap.example.com , In that server we have following structure ou=users,ou=ldap,ou=example,ou=com ou=applications,ou=ldap,ou=example,ou=com basically we need redirect any read/write request that coming to the server ldap.example.com 's *"ou=applications,ou=ldap,ou=example,ou=com*" to our second ldap server called ldap2.example.com , and also all the Read/Write request that comes to * ou=users,ou=ldap,ou=example,ou=com* OU should be served from our primary ldap server , is there any way to achieve that , Please advice Thank You John

1 0

slapd on an interface alias
by Ulrich Windl 06 Jul '13

06 Jul '13

Hi! I had sent a request for documentation to the ITS, because I feel that something is wrong with OpenLDAP 2.4.26 (as shipped with SLES11 SP2), but I was redirected: I wrote: > Full_Name: Ulrich Windl > Version: 2.4.26 > OS: Linux (SLES11 SP2) [...] > > > I was able to set up a master LDAP server and a replication consumer using the > physical host names and TLS. However when I tried to bind slapd on a virtual IP > address ("interface alias"), I never got slapd working (even though I fixed the > certificates for TLS, of course). Dynamic configuration ("cn=config") seems to > make things very difficult, because slapd ends in a state where _nobody_ can > make configuration changes. Use the openldap-technical mailing list to ask for configuration help. You talk about IP addresses and yet in your quoted text below you are using hostnames. Be consistent when you post your question to the mailing list otherwise no one will understand what you're asking for. --> Obviously slapd listens to ports, not to names, and names were invented so that people don't have to remember IP addresses, but you know. --> Only with X.509 certificates the relation between names and adresses are of some inportance, but you can believe me that I understand that. Closing this ITS. > It seems slapd tried to use the wrong URI (using the physical host where nobody > is listening): > slapd[10036]: slap_client_connect: URI=ldap://phost.domain.org/ Error, > ldap_start_tls failed (-1) > slapd[10036]: do_syncrepl: rid=002 rc -1 retrying > > slapd is listening on ldap://vhost.domain.org/ however. --> You should believe me if I say so. > > I read lots of procedures using Google, but could not find the solution for this > problem. Thus I suggest to add documentation how to configure such a scenario: > > 1) Set up an LDAP Master server that provides service on a specific IP address > using TLS > 2) Set up a replication consumer that provides service on a specific IP address > using TLS also > 3) The replication consumer should use the address where the master server > listens for replication > > It sounds like an every-day setup, but I failed multiple times, thus the request > for documentation. > Still waiting for a procedure. Something seems to be non-obvious or broken. Some details (randomly picked, with some names obfuscated): (master server) olcSyncrepl: {0}rid=2 provider="ldap://v07.domain.org/" searchbase="dc=domain,dc=org" type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=domain,dc=org" credent ials="wNkWudLd3ko8" The process is started as "/usr/lib/openldap/slapd -h ldap://ds1.domain.org:389 ldaps://ds1.domain.org:636 ldapi:/// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=off" And syslog message sI'm seeing over and over are like this: Jul 5 08:23:16 v07 slapd[25914]: slap_client_connect: URI=ldap://v07.domain.org/ Error, ldap_start_tls failed (-1) Jul 5 08:23:16 v07 slapd[25914]: do_syncrepl: rid=002 rc -1 retrying Obviously a connection to the "v07" address is not possible, because the server listens to the "ds1" address. The interface settings look like this: eth0 Link encap:Ethernet HWaddr 00:16:3E:5C:DD:76 inet addr:172.20.16.38 Bcast:172.20.17.255 Mask:255.255.254.0 inet6 addr: fe80::216:3eff:fe5c:4d76/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6334378 errors:0 dropped:6 overruns:0 frame:0 TX packets:237667 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:421369553 (401.8 Mb) TX bytes:49452419 (47.1 Mb) eth0:ds1 Link encap:Ethernet HWaddr 00:16:3E:5C:DD:76 inet addr:172.20.17.200 Bcast:172.20.17.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Basically I think I have to fix the "olcSyncrepl provider" and possibly the "olcServerID", but with dynamic configuration I cannot do it: Using ldapmodify I get: v07:~ # ldapmodify -v -ZZ -x -W -D cn=config -H ldap://ds1.domain.org -f /tmp/fix1.ldif ldap_initialize( ldap://ds1.domain.org:389/??base ) Enter LDAP Password: replace olcServerID: 1 ldap://ds1.domain.org modifying entry "cn=config" ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral When editing the files in the slap.d directory, I get: Jul 5 09:11:25 v07 slapd[15014]: @(#) $OpenLDAP: slapd 2.4.26 (Sep 26 2012 13:21:45) $ abuild@e71:/usr/src/packages/BUILD/openldap-2.4.26/servers/slapd Jul 5 09:11:25 v07 slapd[15014]: ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif" Jul 5 09:11:25 v07 slapd[15014]: ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif" Jul 5 09:11:25 v07 slapd[15015]: hdb_monitor_db_open: monitoring disabled; configure monitor database to enable Jul 5 09:11:25 v07 slapd[15015]: slapd starting Jul 5 09:11:25 v07 slapd[15015]: slap_client_connect: URI=ldap://ds1.domain.org/ DN="uid=syncrepl,ou=system,dc=domain,dc=org" ldap_sasl_bind_s failed (49) Jul 5 09:11:25 v07 slapd[15015]: do_syncrepl: rid=002 rc 49 retrying Jul 5 09:11:25 v07 slapd[15015]: slap_client_connect: URI=ldap://ds1.domain.org/ DN="uid=syncrepl,ou=system,dc=domain,dc=org" ldap_sasl_bind_s failed (49) Jul 5 09:11:25 v07 slapd[15015]: do_syncrepl: rid=001 rc 49 retrying Jul 5 09:12:37 v07 nscd: nss-ldap: do_open: do_start_tls failed:stat=-1 (So obviously the syncrepl provider has changed, but it still won't work) Regards, Ulrich

3 2

4th LDAP International Conference announced
by Clément OUDOT 03 Jul '13

03 Jul '13

Hi, The 4th LDAP international conference LDAPCON 2013 will be held in Paris, France on November 18th & 19th. You can find all the details on http://ldapcon.org/ The call for paper is now open and you have until September 8th to submit your proposals. Please check http://ldapcon.org/#cfp for details. LDAPCON is also looking for sponsors. If you or your company is interested, please check http://ldapcon.org/ldapcon_2013_sponsoring.pdf. Hope I can meet some of you at this event! Best regards, Clément.

1 0

err=32 (No such object) with translucent overlay and base scope search
by Steve Eckmann 03 Jul '13

03 Jul '13

Is it expected that the translucent overlay returns a proxied entry but also a "No such object" error when a remote entry exists but the matching local entry does not exist? For example, if there is no local entry for user "John Doe", then the search: ldapsearch -x -H ldaps://localhost -LLL \ -b "cn=John Doe,ou=Users,dc=example,DC=com" -s base \ -D "cn=admin,dc=example,dc=com" -w admin \ '(&)' cn mail manager returns: dn: cn=John Doe,ou=Users,dc=example,DC=com cn: John Doe mail: john.doe(a)example.com manager: cn=Jane Smith,ou=Users,dc=example,DC=com No such object (32) In the slapd log I see: conn=1000 op=9 SEARCH RESULT tag=101 err=32 nentries=1 text= For comparison, the search: ldapsearch -x -H ldaps://localhost -LLL -b dc=example,DC=com \ -s sub \ -D "cn=admin,dc=example,dc=com" -w admin \ '(cn=John Doe)' cn mail manager returns the same entry and attributes but no error. Should the client use the one entry and ignore the error, or is there some way to ask the translucent overlay to not return that error, or how should we handle this? Thanks. Steve

1 0

Increasing olcSockbufMaxIncomingAuth
by Chris Card 03 Jul '13

03 Jul '13

Hi, I'm running openldap 2.4.31 on centos 6.3. I am seeing an issue where a very large group (> 270000 members) is being added to my directory and it is failing with the connection to slapd being closed. I have tracked this down to this error: ber_get_next: sockbuf_max_incoming exceeded (19634099> 16777215) and I can see that the olcSockbufMaxIncomingAuth value is set by default to 2^24 - 1 = 16777215. I've tried increasing this value to 2^25 - 1 = 33554431 in cn=config and the request works fine. Are there any problems associated with increasing olcSockbufMaxIncomingAuth? Chris

1 0

restrict anonymous read access to posixAccount
by Ingo 03 Jul '13

03 Jul '13

Hello list, I'm just learning about access control. I want to setup my clients to manage its posixAccounts and posixGroups over the ldap Directory. With the default access rights it's working. Clients are looking anonymous at the directory for the group, e.g. at boot time or on user login. Syslog shows me: ~$ sudo egrep "slapd\[.*\]: conn=1186" /var/log/syslog slapd[2340]: conn=1186 fd=13 ACCEPT from IP=192.168.1.64:35566 (IP=0.0.0.0:389) slapd[2340]: conn=1186 op=0 BIND dn="" method=128 slapd[2340]: conn=1186 op=0 RESULT tag=97 err=0 text= slapd[2340]: conn=1186 op=1 SRCH base="dc=hoeft-online,dc=de" scope=2 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=1002))" slapd[2340]: conn=1186 op=1 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slapd[2340]: conn=1186 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[2340]: conn=1186 fd=13 closed (connection lost) ~$ slapd ACCEPT a connection from the client, BIND to anonymous with simple method (BIND dn="" method=128) and searches with filter="(&(objectClass=posixGroup)(gidNumber=1002))" with SEARCH RESULT success (err=0 nentries=1). testing it with: ~$ ldapsearch -xLLL "(&(objectClass=posixGroup)(gidNumber=1002))" dn: cn=gemeinsam,ou=groups,ou=home,dc=hoeft-online,dc=de cn: gemeinsam gidNumber: 1002 objectClass: top objectClass: posixGroup memberUid: ingo memberUid: uschi ~$ Now I try to restrict anonymous read only to posixGroup and posixAccount because I don't want anonymous reading other Entries. I modified the default access control to this: olcAccess: to filter= "(| (objectClass=posixAccount) (objectClass=posixGroup))" by anonymous read olcAccess: to * by self write by dn=<admin> write by * none now I get: ~$ ldapsearch -xLLL "(&(objectClass=posixGroup)(gidNumber=1002))" No such object (32) ~$ It works with: olcAccess: to filter="(objectClass=*)" by anonymous read or olcAccess: to filter="(objectClass=top)" by anonymous read What I'm misunderstanding here? And yes, I have read slapd.access three times but do not really understand everything til now. kind regards Ingo

1 1

Re: Mirror mode replication
by Philip Colmer 03 Jul '13

03 Jul '13

> Just curious, why would you do "mirror mode" MMR vs just plain MMR? Do you feel you have a specific > requirement that only one master ever receive the write traffic? No specific requirement but the documentation made various points that suggested "mirror mode" MMR would be easier to support ... For example, for plain MMR, the arguments against included: If connectivity with a provider is lost because of a network partition, then "automatic failover" can just compound the problem Typically, a particular machine cannot distinguish between losing contact with a peer because that peer crashed, or because the network link has failed If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider but the arguments against mirror mode were more semantics (e.g. "MirrorMode is not what is termed as a Multi-Master solution" and "MirrorMode can be termed as Active-Active Hot-Standby") rather than any real negatives. I'm essentially looking to have two LDAP servers and keep them in sync. LDAP consumers will be configured to query both and the web interfaces would be configured to talk to their "local" instance with DNS pointing at a preferred instance. For me, the biggest concern I have about implementing MMR - plain or mirror mode - is the challenge of recovering from a problem. Mirror mode seems to be simpler in that respect because only one node has the writes and therefore reconciliation should be straightforward. Philip On 2 July 2013 16:27, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, July 02, 2013 10:25 AM +0100 Philip Colmer < > philip.colmer(a)linaro.org> wrote: > > >> At the moment, we have a single LDAP server which we are using with LDAP >> Account Manager for web-based object management and Atlassian Crowd for >> authentication. The LDAP server is queried directly by other servers for >> UNIX-level authentication, i.e. SSH and group membership. >> >> >> I'm looking at introducing a second LDAP server and I'm leaning towards >> choosing mirror mode as the replication methodology. Since the only >> writes to LDAP come via LAM or Crowd, and these are both web-based, I >> think I could set up an almost identical server to the one I have at the >> moment and use a system like Amazon's Route 53 DNS service with health >> checks to allow me to redirect users off to the second server if the >> first server fails. >> > > Just curious, why would you do "mirror mode" MMR vs just plain MMR? Do > you feel you have a specific requirement that only one master ever receive > the write traffic? > > --Quanah > > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Corrupted cn=config on multimaster configuration
by paolo penzo 02 Jul '13

02 Jul '13

Hi all, recently I've upgraded some OpenLDAP installations running MM replica from version 2.4.23 to version 2.4.34 (both compiled and packaged locally on RHEL6). At the beginning everything worked fine but then on a cluster I got a corrupted cn=config database after that some modifications were made. When this arose on all the nodes but one the cn=config database was missing of all the other database definitions. I've made a little investigation on this with no luck but I was able to reproduce this behaviour with a simple script which is attached whenever the replication is configured. In my tests both the nodes are configured with the monitor database but after the replica is activated, on the second one, this database is removed and the logs reports "be_delete olcDatabase={1}monitor,cn=config" Did I miss something? Regards, Paolo. ________________________________ Non stampare questa e-mail. Questo documento e' formato esclusivamente per il destinatario. Tutte le informazioni ivi contenute, compresi eventuali allegati, sono soggette a riservatezza a termini del vigente D.Lgs. 196/2003 in materia di privacy e quindi ne e' proibita l'utilizzazione. Se avete ricevuto per errore questo messaggio, Vi preghiamo cortesemente di contattare immediatamente il mittente e cancellare la e-mail. Grazie. Please don't print this e-mail. Confidentiality Notice - This e-mail message including any attachments is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

1 0

Mirror mode replication
by Philip Colmer 02 Jul '13

02 Jul '13

At the moment, we have a single LDAP server which we are using with LDAP Account Manager for web-based object management and Atlassian Crowd for authentication. The LDAP server is queried directly by other servers for UNIX-level authentication, i.e. SSH and group membership. I'm looking at introducing a second LDAP server and I'm leaning towards choosing mirror mode as the replication methodology. Since the only writes to LDAP come via LAM or Crowd, and these are both web-based, I think I could set up an almost identical server to the one I have at the moment and use a system like Amazon's Route 53 DNS service with health checks to allow me to redirect users off to the second server if the first server fails. It occurs to me, though, that either LAM or Crowd could have failed, leaving the LDAP service itself quite healthy. In that situation, all of the writes would still be directed to one of the LDAP servers so is that a problem? The documentation says that "the two providers are set up to replicate from each other but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync." So the only requirement of mirror mode *seems* to be that all writes just go to one provider at a time, i.e. the replication model must be as close to single-master as possible, presumably because of consistency requirements? Or do I need to introduce yet another layer of "something" to direct the writes? The documentation suggests slapd in proxy model or a hardware load balancer, but would my scenario as described above meet the needs? Thanks. Philip

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical