openldap-software March 2010

openldap-software@openldap.org

55 participants
43 discussions

Re: kerberized OpenLDAP
by Andy Cobaugh 29 Mar '10

29 Mar '10

On 2010-03-29 at 10:26, Wolf-Agathon Schaly ( schaly_wolf-agathon(a)arcor.de ) said: > > If I leave the LDAP server listening on the TCP address of localhost (127.0.0.1) declips is cool. > If I change the entry in /etc/openldap/ldap.conf from > URI=ldap://127.0.0.1/ > to > URI=ldap://10.1.1.1/ > I'm facing the same issue (gss_accept_sec_context) as on levante. /etc/openldap/ldap.conf is the ldap.conf file used by client tools (ldapsearch, ldapadd, etc). That has nothing to do with the server, whose configuration file is /etc/openldap/slapd.conf --andy

1 0

Re: slow slave performance
by Michael Ströder 29 Mar '10

29 Mar '10

HI! Please keep replies on the mailing list so others can answer and learn as well. Jefferson Davis wrote: > > what version of bdb shoudl I use - the latest stable openldap does not > like the 4.2 version currently installed. > > Same deal, just different previx? Yupp, different prefix. You can use the same for BDB 4.8.x, OpenLDAP 2.4 etc. That's how I recently did on RHEL 5. Ciao, Michael.

1 0

slow slave performance
by Jefferson Davis 29 Mar '10

29 Mar '10

I am trying to move from a central to a master-slave setup. everything works, buyt as soon as I put the server in slave mode performance gets very poor. Replication works fine. I am running on centos 4.8 w/openldap-servers-2.2.13-12.el4_8.2 TLS is enabled, though removing it seems to make no difference. Where should I direct my troubleshooting efforts, adn what additional information would you need to see in order to point me to the error of my ways? Thanks -- Jefferson K Davis Technology and Information Systems Manager Standard School District 1200 North Chester Ave Bakersfield, CA 93308 661.392.2110 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 2

Using back-ldap as a client-side proxy/cache
by Ryan Steele 27 Mar '10

27 Mar '10

Hey folks, In order to provide stability to my OpenLDAP clients in the event of a network outage, I would like to implement some client-side caching. I've done some research, and have concluded that nscd is evil and should be avoided at all costs, and thus eventually settled on using back-ldap as a proxy and caching mechanism on the clients. Ideally, clients would query a local cache first, and if the information was not available, back-ldap would then forward the connection on to my root OpenLDAP server(s). However, I didn't see much information in the admin guide with respect to such configurations other than a reference to the back-ldap man page, and given that I've got no real experience with setting up back-ldap, I was wondering if somebody who did/does would have some recommendations, advice, or knew of a good documentation source describing this sort of setup? The other question I have is that it seems most people use back-ldap with a slapd.conf-style configuration, versus a cn=config type of setup. In this sort of circumstance, where one is not configuring a full-on OpenLDAP server/replica, that seems like it might be a good thing in the interest of keeping the client configurations simple. Nonetheless, I wanted to verify that it was the recommended way, since slapd.conf (in the context of a fully fleshed-out OpenLDAP server) is deprecated. Thanks as always for insights, advice, and criticisms. Respectfully, Ryan

4 14

Will slapadd work with delta-syncrepl?
by Khoa Nguyen 27 Mar '10

27 Mar '10

I have set up delta-syncrepl between provider A and consumer B, and it seems to work ok. Online updates to A are synch'ed to B. However, about once a month, there is a large update which contains hundreds of million records. Online update is going to take days. I tried to bring A offline, do slapdadd, and bring A back online. But these new entries were not synch'ed to B. Is there a way I can make this work? Thanks, Khoa

4 4

Re: Replication problems.
by Quanah Gibson-Mount 26 Mar '10

26 Mar '10

--On Friday, March 26, 2010 5:41 PM +0000 Steve Button <steve(a)pointers-uk.net> wrote: > > On 26 March 2010 14:57, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > --On Friday, March 26, 2010 8:39 AM +0000 Steve Button > <steve(a)pointers-uk.net> wrote: > > > I'm checking this by comparing the date stamp in the contextCSN. Have > Any suggestions? > > Which release? > > --Quanah > > > > The release is 2.3 If you want help, please keep your replies on list. 2.3 is no longer release. Many known issues have been fixed (particularly with syncrepl) since the last version of 2.3. You fail to note the patchlevel in your reply as well. The only replication mechanism that works reliably for me with 2.3.43 is delta-syncrepl. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Replication problems.
by Steve Button 26 Mar '10

26 Mar '10

Hi, I'm having some problems getting replication to work. My master slapd.conf has these lines :- overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 and the slave has these :- syncrepl rid=123 provider=ldap://master-ldap.europe.example.com:389<http://master-ldap.europe.company.com:389/> type refreshOnly interval 00:00:05:00 retry="60 10 300 +" searchbase="dc=europe,dc=example,dc=com" scope=sub attrs="*,+" schemachecking=off updateref ldap://master-server.europe.example.com:389<http://master-server.europe.nokia.com:389/> I would have expected this to work every 5 minutes and replicate any changes, but nothing ever happens... except when I restart the slave. I'm checking this by comparing the date stamp in the contextCSN. Have tried many different combinations but nothing seems to make much difference. This is a particularly hacked around version of slapd.conf, but a stripped down version doesn't work either (but still works when I restart the slave!) Any suggestions? Steve -- http://ournaturalway.co.uk

2 1

Re: Multi-Master, referrals, and chaining
by Ryan Steele 25 Mar '10

25 Mar '10

Hey Darryl, I decided to use a mixture of MMR and slaves. Specifically, I'll have two masters doing MMR with a proxy (well, a floating IP/hostname that achieves the same thing, anyways) in front to direct traffic to the 'active' master, with the high-availability services being provided by Pacemaker, which will swap resources if the active master dies or becomes unresponsive). Additionally, I'll now have four slaves, each of which will happily perform reads and use an updateref to send writes to the active master. Along with that, I'll use chaining to have the slaves automatically chase the referrals for the clients, so it seems transparent from their end. With this model, I can still guarantee the consistency of my data, distribute whatever reads don't hit the local caches more evenly among the cluster for better performance, and still have a redundant set of masters to preserve continuity. The nice thing is that altering my current six-node MMR setup to fit this new architecture is pretty simple, requiring only a few changes to the newly demoted slaves (such as disabling MirrorMode and simplifying some of the ACLs). Thanks for the suggestion, though! Price, Darryl wrote: > Ryan, > > In order to do what you're suggesting, you'd probably need an intermediate layer ... a proxy server that routes write requests to a specific server. I know Sun's LDAP Proxy that ships with DSEE 6.x can do that and I'm sure there are others as well. I suppose you could also do this with MirrorMode replication rather than the multi-master model. See http://www.openldap.org/doc/admin24/replication.html#MirrorMode%20replicati… > > --Darryl > > -----Original Message----- > From: openldap-software-bounces+ldappro=gmail.com(a)OpenLDAP.org > [mailto:openldap-software-bounces+ldappro=gmail.com@OpenLDAP.org]On > Behalf Of Ryan Steele > Sent: Wednesday, March 24, 2010 12:38 PM > To: openldap-software(a)openldap.org > Subject: Re: Multi-Master, referrals, and chaining > > > I actually realized that my logic was slightly faulty - since each of the six masters is capable of performing the write > operation, the referral will never be chased. Given that, is it impossible to have an N-Way MultiMaster configuration > in which writes are possible on any node, but the writes at any given time are performed on only one of them to ensure > consistency? That is, short of doing what I'm doing now (sending ALL traffic to only one master), which doesn't scale > very well. > > Ryan Steele wrote: >> Hey folks, >> >> As it stands, I've got an environment with six slapd servers (2.4.18) in an N-Way Multi-Master configuration. At any >> given moment, only one of these six nodes is receiving client requests (reads, writes, etc.). We use Pacemaker to >> provide some basic high-availability services, such that if the current 'master' (a term I'll use in this thread to >> refer to the one node receiving all reads/writes from clients) croaks, a shared IP/hostname resource is migrated to the >> next available server. >> >> I would like to modify this setup such that ALL of these six nodes can receive client requests, but in the interest of >> preserving data consistency, I'd like to refer writes to just one of them (that one being the current 'master'), such >> that the rest receive the update(s) via syncrepl. From my own research and reading, it seems as though I'll need a >> combination of referrals (specifically, the 'updateref' directive) and chaining, with the latter being introduced so >> that the job of chasing the referrals is handled server-side instead of being offloaded to the clients. I have two >> questions about this setup, though: >> >> 1. In order to prevent an endless loop of referrals, I'm assuming that the terminal node (the 'master') should NOT have >> an updateref option that points to the 'master' shared IP/hostname (i.e., itself), like the rest of the nodes do. Is >> this correct, or will slapd realize that the referral target is itself, and answer authoritatively? >> >> 2. If the assumption in #1 is correct, what is the most advisable way to handle referrals in the situation where the >> identity of the terminal node is subject to change? My thought was to trigger an ldapmodify operation which effectively >> removes the olcUpdateRef option during the failover, but I'm open to better ideas if they exist. >> >> Thanks! >> >> -Ryan >> > The information contained in this message and any attachment may be > proprietary, confidential, and privileged or subject to the work > product doctrine and thus protected from disclosure. If the reader > of this message is not the intended recipient, or an employee or > agent responsible for delivering this message to the intended > recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. > If you have received this communication in error, please notify me > immediately by replying to this message and deleting it and all > copies and backups thereof. Thank you. > >

1 0

Multi-Master, referrals, and chaining
by Ryan Steele 25 Mar '10

25 Mar '10

Hey folks, As it stands, I've got an environment with six slapd servers (2.4.18) in an N-Way Multi-Master configuration. At any given moment, only one of these six nodes is receiving client requests (reads, writes, etc.). We use Pacemaker to provide some basic high-availability services, such that if the current 'master' (a term I'll use in this thread to refer to the one node receiving all reads/writes from clients) croaks, a shared IP/hostname resource is migrated to the next available server. I would like to modify this setup such that ALL of these six nodes can receive client requests, but in the interest of preserving data consistency, I'd like to refer writes to just one of them (that one being the current 'master'), such that the rest receive the update(s) via syncrepl. From my own research and reading, it seems as though I'll need a combination of referrals (specifically, the 'updateref' directive) and chaining, with the latter being introduced so that the job of chasing the referrals is handled server-side instead of being offloaded to the clients. I have two questions about this setup, though: 1. In order to prevent an endless loop of referrals, I'm assuming that the terminal node (the 'master') should NOT have an updateref option that points to the 'master' shared IP/hostname (i.e., itself), like the rest of the nodes do. Is this correct, or will slapd realize that the referral target is itself, and answer authoritatively? 2. If the assumption in #1 is correct, what is the most advisable way to handle referrals in the situation where the identity of the terminal node is subject to change? My thought was to trigger an ldapmodify operation which effectively removes the olcUpdateRef option during the failover, but I'm open to better ideas if they exist. Thanks! -Ryan

3 3

Preauth error ldap heimdal kerberos
by Μανόλης Βλαχάκης 24 Mar '10

24 Mar '10

Hallo there everyone i hope you can help me with my issue cause it really bothers me for a week i set up an ldap on gentoo and after modifying heimdal kerberos and tls i am stuck to that point: i get these errors... additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context + AS-REQ host/proof.teipir.gr(a)TEIPIR.GR <http://teipir.gr/> from IPv4:10.0.0.12 for krbtgt/TEIPIR.GR <http://teipir.gr/>@TEIPIR.GR<http://teipir.gr/> 2010-03-18T16:32:58 Client sent patypes: none 2010-03-18T16:32:58 Looking for ENC-TS pa-data -- host/proof.teipir.gr@ TEIPIR.GR <http://teipir.gr/> 2010-03-18T16:32:58 No preauth found, returning PREAUTH-REQUIRED -- host/ proof.teipir.gr(a)TEIPIR.GR <http://teipir.gr/> 2010-03-18T16:32:58 sending 268 bytes to IPv4:10.0.0.12 any ideas what files to check cause i am a bit lost... Thank you very much

4 28

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software March 2010