From: Rich West <Rich.West@wesmo.com>
To: autofs@linux.kernel.org
Subject: autofs5 + ldap + ldap replication
Date: Sat, 14 Jul 2007 22:26:39 -0400 [thread overview]
Message-ID: <469985DF.9010607@wesmo.com> (raw)
We have an LDAP infrastructure where all of the automount maps
(auto.master and auto.home) are pulled out of LDAP. In this instance,
we have two LDAP servers, one primary, and the other is a replica. The
clients are all Fedora/Redhat systems. Most of them are running
autofs4, and a few newer ones are running autofs5.
/etc/openldap/ldap.conf has both the primary and replica hosts in the URI.
The problem we are having is with the client hosts running autofs5. For
some reason, if we have the replica host first in the URI line, autofs5
is unable to get any automount data. All of the other LDAP related stuff
works just fine with both entries (in /etc/ldap.conf and in
/etc/openldap/ldap.conf). I was able to narrow things down to the
replica host itself. If I just had the replica address in the URI,
autofs5 doesn't seem to like it.
Jul 14 22:18:09 myhost automount[12143]: Starting automounter version
5.0.1-0.rc3.31, master map auto.master
Jul 14 22:18:09 myhost automount[12143]: using kernel protocol version 5.00
Jul 14 22:18:09 myhost automount[12143]: mounted indirect mount on /misc
with timeout 60, freq 15 seconds
Jul 14 22:18:09 myhost automount[12143]: mounted indirect mount on /net
with timeout 60, freq 15 seconds
Jul 14 22:18:09 myhost automount[12143]: read_file_source_instance: file
map /etc/ldap not found
Jul 14 22:18:09 myhost automount[12143]: lookup_init: lookup(ldap):
failed to get query dn
Jul 14 22:18:09 myhost automount[12143]: mount_autofs_indirect: failed
to read map for /home
Jul 14 22:18:09 myhost automount[12143]: handle_mounts: mount of /home
failed!
Jul 14 22:18:09 myhost automount[12143]: master_do_mount: failed to
startup mount
The exact same configuration works fine on the older systems running
autofs4.
I've confirmed that everything is ok with both the primary and the
replica (this works for all of the autofs4 based hosts). phpMyAdmin
happily browses to the replica's contents. I can perform ldapsearch's
with no problems from all of the hosts. When running automount with the
"-d" and "-v" flags on the autofs5 hosts, I get the above message in
/var/log/messages and I see the following ldap query:
Jul 14 22:18:09 myhost slapd[5410]: conn=315 fd=9 ACCEPT from
IP=192.168.0.100:35494 (IP=0.0.0.0:389)
Jul 14 22:18:09 myhost slapd[5410]: conn=315 op=0 BIND dn="" method=128
Jul 14 22:18:09 myhost slapd[5410]: conn=315 op=0 RESULT tag=97 err=0 text=
Jul 14 22:18:09 myhost slapd[5410]: conn=315 op=1 SRCH
base="dc=mydomain,dc=com" scope=2 deref=0
filter="(&(objectClass=automountMap)(ou=auto.master))"
Jul 14 22:18:09 myhost slapd[5410]: conn=315 op=1 SRCH attr=1.1
Jul 14 22:18:09 myhost slapd[5410]: conn=315 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Jul 14 22:18:09 myhost slapd[5410]: conn=315 op=2 UNBIND
Jul 14 22:18:09 myhost slapd[5410]: conn=315 fd=9 closed
Jul 14 22:18:09 myhost slapd[5410]: conn=316 fd=9 ACCEPT from
IP=192.168.0.100:35495 (IP=0.0.0.0:389)
Jul 14 22:18:09 myhost slapd[5410]: conn=316 op=0 BIND dn="" method=128
Jul 14 22:18:09 myhost slapd[5410]: conn=316 op=0 RESULT tag=97 err=0 text=
Jul 14 22:18:09 myhost slapd[5410]: conn=316 op=1 SRCH
base="ou=auto.master,dc=mydomain,dc=com" scope=2 deref=0
filter="(objectClass=automount)"
Jul 14 22:18:09 myhost slapd[5410]: conn=316 op=1 SRCH attr=cn
automountInformation
Jul 14 22:18:09 myhost slapd[5410]: conn=316 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Jul 14 22:18:09 myhost slapd[5410]: conn=316 op=2 UNBIND
Jul 14 22:18:09 myhost slapd[5410]: conn=316 fd=9 closed
Jul 14 22:18:09 myhost slapd[5410]: conn=317 fd=9 ACCEPT from
IP=192.168.0.100:35496 (IP=0.0.0.0:389)
Jul 14 22:18:09 myhost slapd[5410]: conn=317 op=0 BIND dn="" method=128
Jul 14 22:18:09 myhost slapd[5410]: conn=317 op=0 RESULT tag=97 err=0 text=
Jul 14 22:18:09 myhost slapd[5410]: conn=317 op=1 SRCH
base="dc=mydomain,dc=com" scope=2 deref=0
filter="(&(objectClass=automountMap)(ou=ldap))"
Jul 14 22:18:09 myhost slapd[5410]: conn=317 op=1 SRCH attr=1.1
Jul 14 22:18:09 myhost slapd[5410]: conn=317 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jul 14 22:18:09 myhost slapd[5410]: conn=317 op=2 UNBIND
Jul 14 22:18:09 myhost slapd[5410]: conn=317 fd=9 closed
I'm at a loss. I'm just trying to get the LDAP redundancy in place, but
autofs5 just doesn't seem to want to play nice. Any pointers in the
right direction would be happily appreciated!
-Rich
next reply other threads:[~2007-07-15 2:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-15 2:26 Rich West [this message]
2007-07-15 8:31 ` autofs5 + ldap + ldap replication jehan procaccia
[not found] ` <469A39D5.8040304@wesmo.com>
2007-07-16 18:28 ` Rich West
2007-07-16 15:17 ` Ian Kent
2007-07-16 18:26 ` Rich West
2007-07-16 18:59 ` Jeff Moyer
2007-07-16 19:54 ` Rich West
2007-07-17 6:20 ` Ian Kent
2007-07-23 16:37 ` Rich West
2007-07-24 3:48 ` Ian Kent
2007-07-24 3:56 ` Ian Kent
2007-07-24 16:55 ` Rich West
-- strict thread matches above, loose matches on Subject: below --
2007-08-07 1:32 Rich West
2007-08-07 14:33 ` Jim Summers
2007-08-07 15:24 ` Rich West
2007-08-07 16:52 ` Jim Summers
2007-08-08 11:33 ` Ian Kent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=469985DF.9010607@wesmo.com \
--to=rich.west@wesmo.com \
--cc=autofs@linux.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.