openldap-software

openldap-software@openldap.org

2719 discussions

Fwd: Best method for redundant replication
by Brett ＠Google 15 Oct '08

15 Oct '08

On 10/15/08, Mark S <tokenrain(a)gmail.com> wrote: > I would some advice and how best to go about setting up a redundant > infrastructure for my ldap consumer servers. > > I work for a company that has remote offices around the world. > > In our main office we have setup 2 OpenLDAP servers running 4.x version of > the software in a MirrorMode configuration. I have load balancer which > points a single VIP to the server that I want to be the authoritative writer > at any point in time. > > Around the world I have around 42 servers that I would like to slave off > these master servers. > > First off does anyone think having 42 slaves to a single master is going to > kill the server. It is an 8 core box with gobs of RAM. > > The other question is on how I obtain replication redundancy. Do I simply > point my syncrepl provider to the VIP that hosts the master server. When the > VIP re points in case the a server failure the salvea should just > reconnect? Has anyone ever used 2 syncrepl stanzas against the same DIT. > Something like below. This way the slaves always has a connection to both > servers in the MirrorMode config. If one goes down then the other > replication thread will continue getting updates. Is this a supported > configor does it create a lot of conflicts in deciding who to get the > updates from since it will receive 2 updates when both servers are live. my understanding of mirrormode was that you would point your servers (for writing) at a vip (say master.yourname) or back-ldap server, which refers to the preferred server master1.yourname, and only if that is unavailable, would the vip send traffic to master2.yourname. in this case where one master is preferred, replication traffic between servers would predominately be in one direction, hence clock / replication issues or who-updated-who-first issues, would reduce or go away, which is why it is better than multimaster if your goal is redundancy. reads can be directed at either master1.yourname or master2.yourname, as both would be same for the purposes of reading. you can explicitly refer writes to your master server, in the slap.conf of your distributed servers above assumes writes are less frequent than reads, which is usually typical with ldap data.. your mileage may vary. Cheers Brett

1 0

Best method for redundant replication
by Mark S 14 Oct '08

14 Oct '08

I would some advice and how best to go about setting up a redundant infrastructure for my ldap consumer servers. I work for a company that has remote offices around the world. In our main office we have setup 2 OpenLDAP servers running 4.x version of the software in a MirrorMode configuration. I have load balancer which points a single VIP to the server that I want to be the authoritative writer at any point in time. Around the world I have around 42 servers that I would like to slave off these master servers. First off does anyone think having 42 slaves to a single master is going to kill the server. It is an 8 core box with gobs of RAM. The other question is on how I obtain replication redundancy. Do I simply point my syncrepl provider to the VIP that hosts the master server. When the VIP re points in case the a server failure the salvea should just reconnect? Has anyone ever used 2 syncrepl stanzas against the same DIT. Something like below. This way the slaves always has a connection to both servers in the MirrorMode config. If one goes down then the other replication thread will continue getting updates. Is this a supported configor does it create a lot of conflicts in deciding who to get the updates from since it will receive 2 updates when both servers are live. Thanks! syncrepl rid=100 provider=ldap://master1.nyc.example.com:389 bindmethod=simple binddn="cn=repl,dc=nyc,dc=example,dc=com" credentials=secret type=refreshAndPersist searchbase="dc=nyc,dc=example,dc=com" retry="5 5 10 10 60 +" schemachecking=off syncrepl rid=101 provider=ldap://master2.nyc.example.com:389 bindmethod=simple binddn="cn=repl,dc=nyc,dc=example,dc=com" credentials=secret type=refreshAndPersist searchbase="dc=nyc,dc=example,dc=com" retry="5 5 10 10 60 +" schemachecking=off

1 0

Translucent overlays & replication.
by John Maddock 14 Oct '08

14 Oct '08

Hi. With OpenLDAP 2.4.10 is it possible to replicate a translucent overlay's local changes to another server? Regards, John. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

7 10

Re: Logging bind password
by Pierangelo Masarati 14 Oct '08

14 Oct '08

----- "Alfonsas Stonis" <alfonsasstonis(a)gmail.com> wrote: > Hi, > > Is there any way to log password that was used during bind? > I tried adding option > loglevel 18446744073709551615 where did you find that documented? Since the log level is a mask, I doubt adding digits can help to any extent. > and many other options. Nothing helps. I get the following output > (without password) > > Oct 14 10:56:47 dr slapd[28331]: daemon: read activity on 12 > Oct 14 10:56:47 dr slapd[28331]: connection_get(12) > Oct 14 10:56:47 dr slapd[28331]: connection_get(12): got connid=2 > Oct 14 10:56:47 dr slapd[28331]: connection_read(12): checking for > input on id=2 > Oct 14 10:56:47 dr slapd[28331]: ber_get_next on fd 12 failed > errno=11 > (Resource temporarily unavailable) > Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=6 > active_threads=0 tvp=NULL > Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=7 > active_threads=0 tvp=NULL > Oct 14 10:56:47 dr slapd[28331]: do_bind > Oct 14 10:56:47 dr slapd[28331]: >>> dnPrettyNormal: > <cn=jbaker007,ou=users,o=arhub> > Oct 14 10:56:47 dr slapd[28331]: <<< dnPrettyNormal: > <cn=jbaker007,ou=users,o=arhub>, <cn=jbaker007,ou=users,o=arhub> > Oct 14 10:56:47 dr slapd[28331]: do_bind: version=3 > dn="cn=jbaker007,ou=users,o=arhub" method=128 > Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 BIND > dn="cn=jbaker007,ou=users,o=arhub" method=128 > Oct 14 10:56:47 dr slapd[28331]: ==> bdb_bind: dn: > cn=jbaker007,ou=users,o=arhub > Oct 14 10:56:47 dr slapd[28331]: > bdb_dn2entry("cn=jbaker007,ou=users,o=arhub") > Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access to > "cn=jbaker007,ou=users,o=arhub" "userPassword" requested > Oct 14 10:56:47 dr slapd[28331]: => acl_get: [1] attr userPassword > Oct 14 10:56:47 dr slapd[28331]: => acl_mask: access to entry > "cn=jbaker007,ou=users,o=arhub", attr "userPassword" requested > Oct 14 10:56:47 dr slapd[28331]: => acl_mask: to all values by "", > (=n) > Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: ou=rba,o=arhub > Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: self > Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: * > Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] applying auth(=x) > (stop) > Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] mask: auth(=x) > Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access > granted by auth(=x) > Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: conn=2 op=0 p=3 > Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: err=49 matched="" > text="" > Oct 14 10:56:47 dr slapd[28331]: send_ldap_response: msgid=1 tag=97 > err=49 > Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 RESULT tag=97 err=49 > text= > Oct 14 10:56:47 dr slapd[28331]: daemon: activity on 1 descriptors > Oct 14 10:56:47 dr slapd[28331]: daemon: activity on: > > The problem is that I know that I have correct password but ldap > keeps > rejecting it. So, I need to test maybe application is somehow > changing > it, but I can not see it. > Can someone help me? Try "packets"; you'll get something like slapd starting ldap_read: want=8, got=8 0000: 30 2e 02 01 01 60 29 02 0....`). ldap_read: want=40, got=40 0000: 01 03 04 1c 63 6e 3d 6d 61 6e 61 67 65 72 2c 64 ....cn=manager,d 0010: 63 3d 65 78 61 6d 70 6c 65 2c 64 63 3d 63 6f 6d c=example,dc=com 0020: 80 06 73 65 63 72 65 74 ..secret ldap_read: want=8 error=Resource temporarily unavailable p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

slapadd newbie
by ELCIN HAKTANIR 14 Oct '08

14 Oct '08

Hi i am suffering from slow slapadd for a 100,000 subscriber. It is 27 minutes. this is not what i am expecting . My test environment and the openLDAP release i have installed symas-openldap-silver-2.4.11.0.sun4u.pkg to a System Configuration: Sun Microsystems sun4v SPARC Enterprise T5220 Memory size: 32640 Megabytes Is it rational that slapadd took 26 minutes for 100,000 entries(23Kbyte per subscriber i guess) without index.? I think it is so slow.isn't it? What have i done wrong then?Could you please help to reduce this time ? And how can i learn what db_stat exactly mean to me while doing slapadd? Configuration information about my Environment: --------------------------------------------------------------------- symas-openldap-silver-2.4.11.0.sun4u.pkg installed on a System with Configuration: Sun Microsystems sun4v SPARC Enterprise T5220 Memory size: 32640 Megabytes My slapadd command: ------------------------------------- /opt/symas/bin/sparcv9/slapadd -l /opt/symas/etc/openldap/ldifs/subscribersPart100.ldif -f /opt/symas/etc/openldap/slapd.conf -b o=sdftest -q my DB_CONFIG file is: --------------------------------------- set_cachesize 10 0 0 set_flags DB_LOG_AUTOREMOVE set_flags DB_TXN_NOSYNC set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /opt/symas/etc/openldap/transactionlog my slapd.conf file is: --------------------------------- tool-threads 2 access to dn="" by * read access to * by self write by users read by anonymous auth database bdb suffix "o=sdftest" rootdn "cn=sdf,o=sdftest" rootpw admin234 index default eq index objectClass index cn directory /var/symas/openldap-data/ checkpoint 256000 60 one of the db_stat result root@typhoon:/# /opt/symas/bin/sparcv9/db_stat -h /var/symas/openldap-data/ -m 2GB 25MB Total cache size 1 Number of caches 1 Maximum number of caches 2GB 25MB Pool individual cache size 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 91M Requested pages found in the cache (99%) 294 Requested pages not found in the cache 307399 Pages created in the cache 294 Pages read into the cache 307935 Pages written from the cache to the backing file 31233 Clean pages forced from the cache 33201 Dirty pages forced from the cache 103701 Dirty pages written by trickle-sync thread 243256 Current total page count 243256 Current clean page count 0 Current dirty page count 262147 Number of hash buckets used for page location 90M Total number of times hash chains searched for a page (90995964) 2 The longest hash chain searched for a page 120M Total number of hash chain entries checked for page (120028164) 31 The number of hash bucket locks that required waiting (0%) 4 The maximum number of times any hash bucket lock was waited for (0%) 9 The number of region locks that required waiting (0%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 307713 The number of page allocations 257629 The number of hash buckets examined during allocations 60205 The maximum number of hash buckets examined for an allocation 64434 The number of pages examined during allocations 5844 The max number of pages examined for an allocation 21 Threads waited on page I/O Pool File: id2entry.bdb 16384 Page size 0 Requested pages mapped into the process' address space 2999318 Requested pages found in the cache (99%) 3 Requested pages not found in the cache 136414 Pages created in the cache 3 Pages read into the cache 136659 Pages written from the cache to the backing file Pool File: dn2id.bdb 4096 Page size 0 Requested pages mapped into the process' address space 53M Requested pages found in the cache (99%) 2 Requested pages not found in the cache 168604 Pages created in the cache 2 Pages read into the cache 168607 Pages written from the cache to the backing file Pool File: objectClass.bdb 4096 Page size 0 Requested pages mapped into the process' address space 25M Requested pages found in the cache (99%) 2 Requested pages not found in the cache 694 Pages created in the cache 2 Pages read into the cache 695 Pages written from the cache to the backing file Pool File: cn.bdb 4096 Page size 0 Requested pages mapped into the process' address space 9191165 Requested pages found in the cache (99%) 287 Requested pages not found in the cache 1687 Pages created in the cache 287 Pages read into the cache 1974 Pages written from the cache to the backing file -------------------------------------- Bu elektronik posta ve onunla iletilen bütün dosyalar gizlidir sadece yukarıda isimleri belirtilen kişiler arasında özel haberleşme amacını taşımaktadır. Size yanlışlıkla ulaşmıssa bu elektonik postanın içeriğini açıklamanız , kopyalamanız, yönlendirmeniz ve kullanmanız kesinlikle yasaktır. Lütfen mesajı geri gönderiniz ve sisteminizden siliniz. Vodafone Teknoloji Hizmetleri A.Ş. bu mesajın içeriği ile ilgili olarak hiç bir hukuksal sorumluluğu kabul etmez. This electonic mail and any files transmitted with it are intended for the private use of the persons named above. If you received this message in error, forwarding, copying or use of any of the information is strictly prohibited. Please immediately notify the sender and delete it from your system. Vodafone Teknoloji Hizmetleri A.S. does not accept legal responsibility for the contents of this message. --------------------------------------

2 1

OpenLDAP Kerberos Authentication fails
by Loren M. Lang 13 Oct '08

13 Oct '08

I am using OpenLDAP 2.4.9 on Ubuntu Linux 8.04.1 with MIT Kerberos 1.6.3. Created a keytab file dedicated to slapd and set the path to it using the environment variable KRB5_KTNAME in my startup scripts. The file is owned by root and read-only by the openldap group. When I attempt to use ldapsearch with GSSAPI to login to slapd I get back a implementation error 80. Checking the server logs, slapd reported the following error: Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable) I tried removing the group read permission on the keytab file and restarted slapd as a test on the file to see if slapd was actually reading it and the minor code on the former error message changed to Permission denied. I then added a letter to the keytab file name in my startup script and the error changed to File not found. After reseting the keytab filename and permissions the error was once again Resource temporarily unavailable. I tried deleting the keytab and re-extracting the key using kadmin and setting the permissions appropriately including making openldap the owner as well. I then destroyed my ccache and reacquiring a ticket. When I ran ldapsearch, the error was still resource temporarily unavailable. The client and server are the same computer. The service principal is ldap/host.example.com(a)EXAMPLE.COM and klist shows that is did acquire a service ticket for that principal. The hostname command returns host.example.com for the hostname and that hostname is in /etc/hosts as the first (primary) name for the server's ip address. -- Loren M. Lang lorenl(a)north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B

2 1

Logging bind password
by Alfonsas Stonis 13 Oct '08

13 Oct '08

Hi, Is there any way to log password that was used during bind? I tried adding option loglevel 18446744073709551615 and many other options. Nothing helps. I get the following output (without password) Oct 14 10:56:47 dr slapd[28331]: daemon: read activity on 12 Oct 14 10:56:47 dr slapd[28331]: connection_get(12) Oct 14 10:56:47 dr slapd[28331]: connection_get(12): got connid=2 Oct 14 10:56:47 dr slapd[28331]: connection_read(12): checking for input on id=2 Oct 14 10:56:47 dr slapd[28331]: ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=6 active_threads=0 tvp=NULL Oct 14 10:56:47 dr slapd[28331]: daemon: select: listen=7 active_threads=0 tvp=NULL Oct 14 10:56:47 dr slapd[28331]: do_bind Oct 14 10:56:47 dr slapd[28331]: >>> dnPrettyNormal: <cn=jbaker007,ou=users,o=arhub> Oct 14 10:56:47 dr slapd[28331]: <<< dnPrettyNormal: <cn=jbaker007,ou=users,o=arhub>, <cn=jbaker007,ou=users,o=arhub> Oct 14 10:56:47 dr slapd[28331]: do_bind: version=3 dn="cn=jbaker007,ou=users,o=arhub" method=128 Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 BIND dn="cn=jbaker007,ou=users,o=arhub" method=128 Oct 14 10:56:47 dr slapd[28331]: ==> bdb_bind: dn: cn=jbaker007,ou=users,o=arhub Oct 14 10:56:47 dr slapd[28331]: bdb_dn2entry("cn=jbaker007,ou=users,o=arhub") Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access to "cn=jbaker007,ou=users,o=arhub" "userPassword" requested Oct 14 10:56:47 dr slapd[28331]: => acl_get: [1] attr userPassword Oct 14 10:56:47 dr slapd[28331]: => acl_mask: access to entry "cn=jbaker007,ou=users,o=arhub", attr "userPassword" requested Oct 14 10:56:47 dr slapd[28331]: => acl_mask: to all values by "", (=n) Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: ou=rba,o=arhub Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: self Oct 14 10:56:47 dr slapd[28331]: <= check a_dn_pat: * Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] applying auth(=x) (stop) Oct 14 10:56:47 dr slapd[28331]: <= acl_mask: [3] mask: auth(=x) Oct 14 10:56:47 dr slapd[28331]: => access_allowed: auth access granted by auth(=x) Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: conn=2 op=0 p=3 Oct 14 10:56:47 dr slapd[28331]: send_ldap_result: err=49 matched="" text="" Oct 14 10:56:47 dr slapd[28331]: send_ldap_response: msgid=1 tag=97 err=49 Oct 14 10:56:47 dr slapd[28331]: conn=2 op=0 RESULT tag=97 err=49 text= Oct 14 10:56:47 dr slapd[28331]: daemon: activity on 1 descriptors Oct 14 10:56:47 dr slapd[28331]: daemon: activity on: The problem is that I know that I have correct password but ldap keeps rejecting it. So, I need to test maybe application is somehow changing it, but I can not see it. Can someone help me? Alfas

1 0

RE24: Locker killed to resolve a deadlock
by Michael Ströder 13 Oct '08

13 Oct '08

HI! Playing with recent RE24 and MIT Kerberos' LDAP backend I noticed this in syslog: Oct 11 10:15:35 nb2 slapd[3888]: => bdb_dn2id_add 0x8d: put failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 Oct 11 10:15:35 nb2 slapd[3888]: => bdb_dn2id_add 0x8c: put failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 Oct 11 10:15:35 nb2 slapd[3888]: conn=5 fd=29 closed Oct 11 10:15:35 nb2 slapd[3888]: => bdb_dn2id_add 0x8d: put failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 Can't reproduce though. Under which circumstances can this happen? Ciao, Michael.

2 1

pwdAccountLockedTime and delta-syncrepl
by Sam Tran 11 Oct '08

11 Oct '08

Dear All, I have an LDAP provider and its consumer running OpenLDAP 2.3.43, the replication mode being delta-syncrepl. Password policy is enabled on both servers. I performed the following tests: 1- Tried N bind attempts to *LDAP provider* with N = pwdMaxFailure and wrong password. N pwdFailureTime attributes and one pwdAccountLockedTime attribute were added to the binding DN on provider. All changes were replicated to the consumer. As a result it was *not* possible to bind to either the provider or the consumer using the correct password. Changing the password on the provider removed the pwdFailureTime and pwdAccountLockedTime attributes on the provider. Changes were replicated to the consumer. As a result it was possible to bind to either the provider or the consumer using the new password. All works as designed. 2- Tried N bind attempts to *LDAP consumer* with N = pwdMaxFailure and wrong password. N pwdFailureTime attributes and one pwdAccountLockedTime attribute were added to the binding DN on consumer. As a result it was *not* possible to bind to the consumer using the correct password. Changing the password on the provider caused the pwdFailureTime attributes to be removed on the consumer. But the pwdAccountLockedTime attribute was still present in the binding DN on the consumer. As a result it was *still not* possible to bind to the consumer using the new password. Is this the expected behavior? I thought that changing the password on the provider would remove both the pwdFailureTime and pwdAccountLockedTime attributes on the consumer, thus allowing me to bind to the consumer. Any help on the matter would be very much appreciated. Thanks. -- Sam

2 4

Re: load problem in mirror mode
by ghenry＠OpenLDAP.org 10 Oct '08

10 Oct '08

----- "Hugo Monteiro" <hugo.monteiro(a)fct.unl.pt> wrote: > Gavin Henry wrote: > > Can you put your config online somewhere? > > > > Thanks. > > > > > > My appologies for the late reply, but life got in the way. :) > > The configuration files for both nodes, their respective DB_CONFIG > file, > and the ldap proxy config file can be reached here: > > http://pessoa.fct.unl.pt/hmmm/ > There were some mistakes in the docs that have been fixed: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/admin/replication.sdf?r… Also, you don't have a serverID -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software