From: Guillaume Rousse <Guillaume.Rousse@inria.fr>
To: autofs@linux.kernel.org
Subject: getting rid of spurious log warnings
Date: Fri, 03 Feb 2006 17:30:25 +0100 [thread overview]
Message-ID: <43E38521.7070002@inria.fr> (raw)
I get lot of similar warnings in my logs, every time I try to access an
automount-managed filesystem:
Feb 3 16:21:54 pomerol automount[8854]: lookup(ldap): got answer, but
no first entry for (&(objectclass=nisObject)(cn=infosystems))
Feb 3 16:21:54 pomerol automount[8854]: lookup(ldap): got answer, but
no first entry for (&(objectclass=automount)(cn=infosystems))
Feb 3 16:21:54 pomerol automount[8854]: lookup(ldap): got answer, but
no first entry for (&(objectclass=nisObject)(cn=/))
According to detailed informations found at
http://www.ldapguru.com/modules/newbb/viewtopic.php?topic_id=2029&forum=6&viewmode=flat&order=ASC&start=0
it seems to be caused by a two pass querying mechanism from autofs,
first one using Sun legacy schema, second one using autofs specific
schema. The first two queries seems to be attempts to retrieve an
explicit mapping for the first path element in the client map, the third
one a fallback to a generic root mapping.
Is there any way to configure autofs to directly use the correct schema
? I found some references to using nss_map_objectclass directives in nss
_ldap configuration, but it doesn't seem to work (and I'm not really
sure autofs rely on nss configuration). Otherwise, I could also just
change my ldap content, but I find using 'automount' instead of 'nis'
simpler.
I'm using linux-only setup, with an openldap 2.2 server. Here is an
exemple of a client map.
dn: ou=auto.net.graves,ou=autofs,dc=village,dc=inria,dc=fr
objectClass: top
objectClass: automountMap
ou: auto.net.graves
dn: cn=/,ou=auto.net.graves,ou=autofs,dc=village,dc=inria,dc=fr
objectClass: top
objectClass: automount
cn: /
automountInformation: -fstype=nfs,hard,intr graves:/home/graves/ftp/&
--
The bullet that is forgotten while installing an antenna systems will
always be at the base of the antenna, and discovered at 5pm on a Friday
after the tower crew has left
-- Murphy's Laws of Broadcast Engineering n°7
reply other threads:[~2006-02-03 16:30 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=43E38521.7070002@inria.fr \
--to=guillaume.rousse@inria.fr \
--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.