using both nfs3 and nfs4 in a single mount map

using both nfs3 and nfs4 in a single mount map

[Lukas Kolbe]

Hi!

Is it possible to us nfs4 and as a fallback nfs3 in a single mount map?

We have /homes coming from many different servers, the older ones only
speak v3 and the newer ones would love to speak v4 as we would.
Currently, auto.master looks like this:

/homes  yp:auto_homes	-nosuid,grpid,nobrowse,-fstype=nfs4,proto=tcp,port=2049

This of course only works for the nfs4-capable fileservers. Is there any
way to also get the old fileservers into this game again?
Using only nfsv3 is no option unfortunately; as is converting all to
nfs4 at once :(

-- 
Lukas

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Fri, 2007-07-27 at 17:24 +0200, Lukas Kolbe wrote:
> Hi!
> 
> Is it possible to us nfs4 and as a fallback nfs3 in a single mount map?
> 
> We have /homes coming from many different servers, the older ones only
> speak v3 and the newer ones would love to speak v4 as we would.
> Currently, auto.master looks like this:
> 
> /homes  yp:auto_homes	-nosuid,grpid,nobrowse,-fstype=nfs4,proto=tcp,port=2049
> 
> This of course only works for the nfs4-capable fileservers. Is there any
> way to also get the old fileservers into this game again?
> Using only nfsv3 is no option unfortunately; as is converting all to
> nfs4 at once :(

I'll have to think about for a while and have a look at the code.

What does your auto_homes look like?
What version of autofs and kernel?

Ian

Re: using both nfs3 and nfs4 in a single mount map

[Lukas Kolbe]

Hi Ian,
> 
> I'll have to think about for a while and have a look at the code.

Thank you :)

> What does your auto_homes look like?

ypmatch is my friend:

lkolbe@komagatake ypmatch lkolbe auto_homes
figaro:/users/rbghiwis01/rbghiwis/&
lkolbe@komagatake ypmatch fstest auto_homes
thor:/export/rbg/homes/staff/&
lkolbe@komagatake ypmatch vkgnome auto_homes
figaro:/users/stud09/stud/&

Where figaro is a Solaris 8 or 9 server serving nfs3, thor is a solaris
10 box serving nfs4 from zfs-volumes.

> What version of autofs and kernel?
> 
I currently tried it for testing on linux 2.6.18 (ubuntu dapper), autofs
5.0.2 (backported from debian experimental). That would be the
production environment for a few more months :)

> Ian
> 

-- 
Lukas

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Fri, 2007-07-27 at 17:45 +0200, Lukas Kolbe wrote:
> Hi Ian,
> > 
> > I'll have to think about for a while and have a look at the code.
> 
> Thank you :)
> 
> > What does your auto_homes look like?
> 
> ypmatch is my friend:
> 
> lkolbe@komagatake ypmatch lkolbe auto_homes
> figaro:/users/rbghiwis01/rbghiwis/&
> lkolbe@komagatake ypmatch fstest auto_homes
> thor:/export/rbg/homes/staff/&
> lkolbe@komagatake ypmatch vkgnome auto_homes
> figaro:/users/stud09/stud/&
> 
> Where figaro is a Solaris 8 or 9 server serving nfs3, thor is a solaris
> 10 box serving nfs4 from zfs-volumes.

Presumably the exports are distinct, in which case using a list of
server should allow autofs to try each one?

What about trying something like:

In the master map put:
/homes	auto_homes	nosuid,grpid,nobrowse,proto=tcp,port=2049

In NIS auto_homes put:
*	thor:/export/rbg/homes/staff/& figaro:/users/rbghiwis01/rbghiwis/& figaro:/users/stud09/stud/&

With the order determined by the server likely to get the most hits.

Ensure that /etc/nsswitch has:
automount: files nis

and /etc/auto_homes, either doesn't exist or contains, as the last line,
+auto_homes

And finally this patch.
Beware, I haven't even compile tested this and I know I excluded the
NFS4 here for a reason, which I can't remember atm.

Ian

---
diff --git a/modules/mount_nfs.c b/modules/mount_nfs.c
index 25f72b9..7083200 100644
--- a/modules/mount_nfs.c
+++ b/modules/mount_nfs.c
@@ -130,8 +130,10 @@ int mount_mount(struct autofs_point *ap, const char *root, const char *name, int
 
 	if (strcmp(fstype, "nfs4") == 0)
 		vers = NFS4_VERS_MASK | NFS_PROTO_MASK;
-	else
+	else if (strcmp(fstype, "nfs") == 0)
 		vers = NFS_VERS_MASK | NFS_PROTO_MASK;
+	else
+		vers = NFS4_VERS_MASK | NFS_VERS_MASK | NFS_PROTO_MASK;
 
 	if (!parse_location(&hosts, what)) {
 		warn(ap->logopt, MODPREFIX "no hosts available");

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Sat, 2007-07-28 at 15:15 +0800, Ian Kent wrote:
> On Fri, 2007-07-27 at 17:45 +0200, Lukas Kolbe wrote:
> > Hi Ian,
> > > 
> > > I'll have to think about for a while and have a look at the code.
> > 
> > Thank you :)
> > 
> > > What does your auto_homes look like?
> > 
> > ypmatch is my friend:
> > 
> > lkolbe@komagatake ypmatch lkolbe auto_homes
> > figaro:/users/rbghiwis01/rbghiwis/&
> > lkolbe@komagatake ypmatch fstest auto_homes
> > thor:/export/rbg/homes/staff/&
> > lkolbe@komagatake ypmatch vkgnome auto_homes
> > figaro:/users/stud09/stud/&
> > 
> > Where figaro is a Solaris 8 or 9 server serving nfs3, thor is a solaris
> > 10 box serving nfs4 from zfs-volumes.
> 
> Presumably the exports are distinct, in which case using a list of
> server should allow autofs to try each one?
> 
> What about trying something like:

On second thoughts this may get only the nfs4 or only the nfs3 servers
as well.

> 
> In the master map put:
> /homes	auto_homes	nosuid,grpid,nobrowse,proto=tcp,port=2049
> 
> In NIS auto_homes put:
> *	thor:/export/rbg/homes/staff/& figaro:/users/rbghiwis01/rbghiwis/& figaro:/users/stud09/stud/&
> 
> With the order determined by the server likely to get the most hits.
> 
> Ensure that /etc/nsswitch has:
> automount: files nis
> 
> and /etc/auto_homes, either doesn't exist or contains, as the last line,
> +auto_homes
> 
> And finally this patch.
> Beware, I haven't even compile tested this and I know I excluded the
> NFS4 here for a reason, which I can't remember atm.
> 
> Ian
> 
> ---
> diff --git a/modules/mount_nfs.c b/modules/mount_nfs.c
> index 25f72b9..7083200 100644
> --- a/modules/mount_nfs.c
> +++ b/modules/mount_nfs.c
> @@ -130,8 +130,10 @@ int mount_mount(struct autofs_point *ap, const char *root, const char *name, int
>  
>  	if (strcmp(fstype, "nfs4") == 0)
>  		vers = NFS4_VERS_MASK | NFS_PROTO_MASK;
> -	else
> +	else if (strcmp(fstype, "nfs") == 0)
>  		vers = NFS_VERS_MASK | NFS_PROTO_MASK;
> +	else
> +		vers = NFS4_VERS_MASK | NFS_VERS_MASK | NFS_PROTO_MASK;
>  
>  	if (!parse_location(&hosts, what)) {
>  		warn(ap->logopt, MODPREFIX "no hosts available");
> 
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

Re: using both nfs3 and nfs4 in a single mount map

[Lukas Kolbe]

Hi Ian, thanks for your support!
> > 
> > Presumably the exports are distinct, in which case using a list of
> > server should allow autofs to try each one?

Yep, they are - differnet homes come from different servers. 
 
> > What about trying something like:
> 
> On second thoughts this may get only the nfs4 or only the nfs3 servers
> as well.

Automount now mounts fine from all servers, but still nfs3
only. /proc/mounts shows me:

figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0

where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
really would like to use v4.

In fact, we have to use v4 here as every home directory is a seperate
ZFS volume, and nfs3 has issues scaling to over a hundered simultanous
mounts on linux that nfs4 has not.

On the old fileservers, we have the homes sitting in about 10 to 20
different volumes and use a hack to only mount these few volumes per
nfs3 and then bind-mount each individual home locally.

> > 
> > In the master map put:
> > /homes	auto_homes	nosuid,grpid,nobrowse,proto=tcp,port=2049
> > 
> > In NIS auto_homes put:
> > *	thor:/export/rbg/homes/staff/& figaro:/users/rbghiwis01/rbghiwis/& figaro:/users/stud09/stud/&
> > 
> > With the order determined by the server likely to get the most hits.
> > 
> > Ensure that /etc/nsswitch has:
> > automount: files nis

This works indeed like a charme, autofs is also expiring the mounts
correctly. 

> > and /etc/auto_homes, either doesn't exist or contains, as the last line,
> > +auto_homes
> > 
> > And finally this patch.
> > Beware, I haven't even compile tested this and I know I excluded the
> > NFS4 here for a reason, which I can't remember atm.

I don't really know what this patch is supposed to do :), but it applied
and works. 
I suppose it should try nfs4 if no explicit -fstype= is given?


Apropros expiring mounts: I get 

Jul 30 15:31:12 sorpe automount[14121]: umount_multi: could not stat fs of /homes/yyy

in syslog and /homes/yyy is still mounted; but I guess this is an Issue
that I'll try to cover after the nfs3 versus nfs4 thing.

By the way thanks to your patient support I slowly begin to understand
how autofs really works. Thanks!

-- 
Lukas

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Mon, 2007-07-30 at 15:36 +0200, Lukas Kolbe wrote:
> Hi Ian, thanks for your support!
> > > 
> > > Presumably the exports are distinct, in which case using a list of
> > > server should allow autofs to try each one?
> 
> Yep, they are - differnet homes come from different servers. 
>  
> > > What about trying something like:
> > 
> > On second thoughts this may get only the nfs4 or only the nfs3 servers
> > as well.
> 
> Automount now mounts fine from all servers, but still nfs3
> only. /proc/mounts shows me:
> 
> figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
> bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
> 
> where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
> really would like to use v4.

That is difficult because the selection is supposed to return the
largest list of servers that support the highest protocol version,
sorted by rpc ping response time.

If we change it to return a list ordered by nfs version with each
version sorted by rpc response then it no longer satisfies the
requirements of replicated server selection.

> 
> In fact, we have to use v4 here as every home directory is a seperate
> ZFS volume, and nfs3 has issues scaling to over a hundered simultanous
> mounts on linux that nfs4 has not.
> 
> On the old fileservers, we have the homes sitting in about 10 to 20
> different volumes and use a hack to only mount these few volumes per
> nfs3 and then bind-mount each individual home locally.
> 
> > > 
> > > In the master map put:
> > > /homes	auto_homes	nosuid,grpid,nobrowse,proto=tcp,port=2049
> > > 
> > > In NIS auto_homes put:
> > > *	thor:/export/rbg/homes/staff/& figaro:/users/rbghiwis01/rbghiwis/& figaro:/users/stud09/stud/&
> > > 
> > > With the order determined by the server likely to get the most hits.
> > > 
> > > Ensure that /etc/nsswitch has:
> > > automount: files nis
> 
> This works indeed like a charme, autofs is also expiring the mounts
> correctly. 
> 
> > > and /etc/auto_homes, either doesn't exist or contains, as the last line,
> > > +auto_homes
> > > 
> > > And finally this patch.
> > > Beware, I haven't even compile tested this and I know I excluded the
> > > NFS4 here for a reason, which I can't remember atm.
> 
> I don't really know what this patch is supposed to do :), but it applied
> and works. 
> I suppose it should try nfs4 if no explicit -fstype= is given?

At some point I found I had to treat nfs4 a little differently and
that's why they were seperated.

> 
> 
> Apropros expiring mounts: I get 
> 
> Jul 30 15:31:12 sorpe automount[14121]: umount_multi: could not stat fs of /homes/yyy
> 
> in syslog and /homes/yyy is still mounted; but I guess this is an Issue
> that I'll try to cover after the nfs3 versus nfs4 thing.

Not sure about that but perhaps later.

> By the way thanks to your patient support I slowly begin to understand
> how autofs really works. Thanks!
> 

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Mon, 2007-07-30 at 15:36 +0200, Lukas Kolbe wrote:
> Hi Ian, thanks for your support!
> > > 
> > > Presumably the exports are distinct, in which case using a list of
> > > server should allow autofs to try each one?
> 
> Yep, they are - differnet homes come from different servers. 
>  
> > > What about trying something like:
> > 
> > On second thoughts this may get only the nfs4 or only the nfs3 servers
> > as well.
> 
> Automount now mounts fine from all servers, but still nfs3
> only. /proc/mounts shows me:
> 
> figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
> bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
> 
> where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
> really would like to use v4.

Actually, a multi map entry in the master map would probably work.
Initially I missed this out of version 5 (by accident) so you'll need
the patch on kernel.org that adds it. In fact I'd recommend applying all
the 5.0.2 patches.

So forget the last suggestion and patch and apply all the 5.0.2 patches
on kernel.org and try a line in the master map like:

/homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049

and see if that gets what you need. The nfs4 one needs to be first
because the v4 servers provide both v4 and v3.

Ian

AutoFS5 Ldap base strangeness

[Jim Summers]

hello all,

I am just about to get my automounting working with autofs5 and my ldap.  I am 
able to start the automount daemon and it loads and reads /home map, which 
points at ou=auto.home for the user's home directory location and options.

but when i attempt to su - <user> it can not mount the user's home.  here is 
what i see in the ldap server's access log:
===
[31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH 
base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2 
filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))" 
attrs="automountKey automountInformation"
[31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0 
etime=0
[31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
===

the weird part of the above is, in the first line it says "cn=sfu" but then 
also says automountKey=tmac

the su command is:  su - tmac

so the correct username is tmac not sfu.

any ideas where the sfu thing is coming from??

is the info cached somewhere?  I ask because when I start the daemon, i can 
see in the logs where it does:
===
[31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH 
base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2 
filter="(objectClass=automount)" attrs="1.1"
[31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617 
etime=0
===
which is returning 617 entries.

not sure what i have wroong here??

TIA
-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Re: using both nfs3 and nfs4 in a single mount map

[Lukas Kolbe]

Hi Ian,

> > figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
> > bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
> > 
> > where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
> > really would like to use v4.
> 
> Actually, a multi map entry in the master map would probably work.
> Initially I missed this out of version 5 (by accident) so you'll need
> the patch on kernel.org that adds it. In fact I'd recommend applying all
> the 5.0.2 patches.
> 
> So forget the last suggestion and patch and apply all the 5.0.2 patches
> on kernel.org and try a line in the master map like:

Ok, done that :).

> /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
> 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
> 
> and see if that gets what you need. The nfs4 one needs to be first
> because the v4 servers provide both v4 and v3.

This only gives me the nfs4 mounts, it seems like the second part of the
multimount is not evaluated when the first one says "I don't have that
directory you asked me about":

root@sorpe:/# ls -la /homes/yyy
ls: /homes/yyy: Permission denied

Which is correct and comes from bongossi,

root@sorpe:/# ls -la /homes/xxx
ls: /homes/xxx: No such file or directory

which should also say permission denied and should come from figaro.

> Ian

-- 
Lukas

Re: using both nfs3 and nfs4 in a single mount map

[Murata, Dennis]

I have also tried the multi feature with autofs-5.0.2-7 on a RHEL 5
workstation.  The auto.master entry I used on RHEL 3 autofs-4.1.3--184
was:

/pa  multi:file /etc/auto.pa -- yp auto.pa

The /etc/auto.pa and the yp map auto.pa were single line entries:

*  server:/local/foo/&
and
*  server:/local/foo1/&
 
I modified the auto.master entry for autofs-5.0.2-7:

/pa multi file /etc/auto.pa -- yp auto.pa

And tried to use the same /etc/auto.pa and nis auto.pa.  This did not
work, it would not search the second entry.  If I added +auto.pa to the
/etc/auto.pa file, it would only search the yp map.  If I changed the
file /etc/auto.pa from using a wildcard to specifying each directory
things started working.  Is this the problem you are seeing?  Is there
anyway to allow wildcards in both maps?

Wayne

-----Original Message-----
From: autofs-bounces@linux.kernel.org
[mailto:autofs-bounces@linux.kernel.org] On Behalf Of Lukas Kolbe
Sent: Wednesday, August 01, 2007 8:14 AM
To: Ian Kent
Cc: autofs@linux.kernel.org
Subject: Re: [autofs] using both nfs3 and nfs4 in a single mount map

Hi Ian,

> > figaro:/users/xxx /homes/xxx nfs 
> > rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=6
> > 00,retrans=2,sec=sys,addr=figaro 0 0 bongossi:/export/yyy /homes/yyy

> > nfs 
> > rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,tim
> > eo=600,retrans=2,sec=sys,addr=bongossi 0 0
> > 
> > where figaro only exports nfs v3, bongossi exports both v4 and v3 
> > and we really would like to use v4.
> 
> Actually, a multi map entry in the master map would probably work.
> Initially I missed this out of version 5 (by accident) so you'll need 
> the patch on kernel.org that adds it. In fact I'd recommend applying 
> all the 5.0.2 patches.
> 
> So forget the last suggestion and patch and apply all the 5.0.2 
> patches on kernel.org and try a line in the master map like:

Ok, done that :).

> /homes  multi yp auto_homes
-fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
> 		yp auto_homes
-fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
> 
> and see if that gets what you need. The nfs4 one needs to be first 
> because the v4 servers provide both v4 and v3.

This only gives me the nfs4 mounts, it seems like the second part of the
multimount is not evaluated when the first one says "I don't have that
directory you asked me about":

root@sorpe:/# ls -la /homes/yyy
ls: /homes/yyy: Permission denied

Which is correct and comes from bongossi,

root@sorpe:/# ls -la /homes/xxx
ls: /homes/xxx: No such file or directory

which should also say permission denied and should come from figaro.

> Ian

--
Lukas


_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Wed, 2007-08-01 at 15:13 +0200, Lukas Kolbe wrote:
> Hi Ian,
> 
> > > figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
> > > bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
> > > 
> > > where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
> > > really would like to use v4.
> > 
> > Actually, a multi map entry in the master map would probably work.
> > Initially I missed this out of version 5 (by accident) so you'll need
> > the patch on kernel.org that adds it. In fact I'd recommend applying all
> > the 5.0.2 patches.
> > 
> > So forget the last suggestion and patch and apply all the 5.0.2 patches
> > on kernel.org and try a line in the master map like:
> 
> Ok, done that :).
> 
> > /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
> > 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
> > 
> > and see if that gets what you need. The nfs4 one needs to be first
> > because the v4 servers provide both v4 and v3.
> 
> This only gives me the nfs4 mounts, it seems like the second part of the
> multimount is not evaluated when the first one says "I don't have that
> directory you asked me about":

Aaah yes, of course, sorry about that.
That would be because the first encountered key is used to decide pass
or fail.

We've discussed this behavior in the past so it really has to remain.

Ian

Re: using both nfs3 and nfs4 in a single mount map

[Jeff Moyer]

Ian Kent <raven@themaw.net> writes:

> On Wed, 2007-08-01 at 15:13 +0200, Lukas Kolbe wrote:
>> Hi Ian,
>> 
>> > > figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
>> > > bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
>> > > 
>> > > where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
>> > > really would like to use v4.
>> > 
>> > Actually, a multi map entry in the master map would probably work.
>> > Initially I missed this out of version 5 (by accident) so you'll need
>> > the patch on kernel.org that adds it. In fact I'd recommend applying all
>> > the 5.0.2 patches.
>> > 
>> > So forget the last suggestion and patch and apply all the 5.0.2 patches
>> > on kernel.org and try a line in the master map like:
>> 
>> Ok, done that :).
>> 
>> > /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
>> > 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
>> > 
>> > and see if that gets what you need. The nfs4 one needs to be first
>> > because the v4 servers provide both v4 and v3.
>> 
>> This only gives me the nfs4 mounts, it seems like the second part of the
>> multimount is not evaluated when the first one says "I don't have that
>> directory you asked me about":
>
> Aaah yes, of course, sorry about that.
> That would be because the first encountered key is used to decide pass
> or fail.

No, it is because the second key was never added to the cache.  See my
earlier, somewhat cryptic message on this.

As Pete said, if the default should be nfs4, that should happen in mount.

-Jeff

Re: using both nfs3 and nfs4 in a single mount map

[Lukas Kolbe]

Hi!


> >> > /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
> >> > 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
> >> > 
> >> > and see if that gets what you need. The nfs4 one needs to be first
> >> > because the v4 servers provide both v4 and v3.
> >> 
> >> This only gives me the nfs4 mounts, it seems like the second part of the
> >> multimount is not evaluated when the first one says "I don't have that
> >> directory you asked me about":
> >
> > Aaah yes, of course, sorry about that.
> > That would be because the first encountered key is used to decide pass
> > or fail.
> 
> No, it is because the second key was never added to the cache.  See my
> earlier, somewhat cryptic message on this.
> 
> As Pete said, if the default should be nfs4, that should happen in mount.

Yes and no :)

I'm currently trying to understand the autofs5 code and stumbled upon
modules/replicated.c, function prune_host_list that get's called from
mount_nfs.c and *somehow* decides wether to try nfs4 or other nfs
versions. Would any of you be so kind and explain the way that the
information from the entry in the auto.master-map (-fstype=nfs4 or =nfs)
gets propagated down to the actual mount command? 

> -Jeff

-- 
Lukas

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Fri, 2007-08-10 at 15:25 +0200, Lukas Kolbe wrote:
> Hi!
> 
> 
> > >> > /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
> > >> > 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
> > >> > 
> > >> > and see if that gets what you need. The nfs4 one needs to be first
> > >> > because the v4 servers provide both v4 and v3.
> > >> 
> > >> This only gives me the nfs4 mounts, it seems like the second part of the
> > >> multimount is not evaluated when the first one says "I don't have that
> > >> directory you asked me about":
> > >
> > > Aaah yes, of course, sorry about that.
> > > That would be because the first encountered key is used to decide pass
> > > or fail.
> > 
> > No, it is because the second key was never added to the cache.  See my
> > earlier, somewhat cryptic message on this.
> > 
> > As Pete said, if the default should be nfs4, that should happen in mount.
> 
> Yes and no :)
> 
> I'm currently trying to understand the autofs5 code and stumbled upon
> modules/replicated.c, function prune_host_list that get's called from
> mount_nfs.c and *somehow* decides wether to try nfs4 or other nfs
> versions. Would any of you be so kind and explain the way that the
> information from the entry in the auto.master-map (-fstype=nfs4 or =nfs)
> gets propagated down to the actual mount command? 

You probably just want to look at modules/mount_nfs.c.

The actual chain of events is:
1) Parse master map and mount automounts, create
daemon/automount.c:handle_mounts thread for each mount.
2) daemon/automount.c:handle_mounts dispatches events as they come in.
3) A missing packet for an indirect mount leads to a call to
daemon/indirect.c:handle_packet_missing_indirect.
4) Then -> daemon/indirect.c:do_mount_indirect ->
daemon/lookup.c:lookup.c -> modules/lookup_<type>.c:lookup_mount ->
modules/parse_sun.c:parse_mount -> modules/mount_<type>.c:mount_mount.

Ian

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Mon, 2007-08-13 at 11:22 +0800, Ian Kent wrote:
> On Fri, 2007-08-10 at 15:25 +0200, Lukas Kolbe wrote:
> > Hi!
> > 
> > 
> > > >> > /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
> > > >> > 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
> > > >> > 
> > > >> > and see if that gets what you need. The nfs4 one needs to be first
> > > >> > because the v4 servers provide both v4 and v3.
> > > >> 
> > > >> This only gives me the nfs4 mounts, it seems like the second part of the
> > > >> multimount is not evaluated when the first one says "I don't have that
> > > >> directory you asked me about":
> > > >
> > > > Aaah yes, of course, sorry about that.
> > > > That would be because the first encountered key is used to decide pass
> > > > or fail.
> > > 
> > > No, it is because the second key was never added to the cache.  See my
> > > earlier, somewhat cryptic message on this.
> > > 
> > > As Pete said, if the default should be nfs4, that should happen in mount.
> > 
> > Yes and no :)
> > 
> > I'm currently trying to understand the autofs5 code and stumbled upon
> > modules/replicated.c, function prune_host_list that get's called from
> > mount_nfs.c and *somehow* decides wether to try nfs4 or other nfs
> > versions. Would any of you be so kind and explain the way that the
> > information from the entry in the auto.master-map (-fstype=nfs4 or =nfs)
> > gets propagated down to the actual mount command? 
> 
> You probably just want to look at modules/mount_nfs.c.
> 

Mistake.

> The actual chain of events is:
> 1) Parse master map and mount automounts, create
> daemon/automount.c:handle_mounts thread for each mount.
> 2) daemon/automount.c:handle_mounts dispatches events as they come in.
> 3) A missing packet for an indirect mount leads to a call to
> daemon/indirect.c:handle_packet_missing_indirect.
> 4) Then -> daemon/indirect.c:do_mount_indirect ->
> daemon/lookup.c:lookup.c -> modules/lookup_<type>.c:lookup_mount ->
  daqemon/lookup.c:lookup_nss_mount
> modules/parse_sun.c:parse_mount -> modules/mount_<type>.c:mount_mount.
> 
> Ian

Re: using both nfs3 and nfs4 in a single mount map

[Lukas Kolbe]

Hi Ian and list,

> > > I'm currently trying to understand the autofs5 code and stumbled upon
> > > modules/replicated.c, function prune_host_list that get's called from
> > > mount_nfs.c and *somehow* decides wether to try nfs4 or other nfs
> > > versions. Would any of you be so kind and explain the way that the
> > > information from the entry in the auto.master-map (-fstype=nfs4 or =nfs)
> > > gets propagated down to the actual mount command? 
> > 
> > You probably just want to look at modules/mount_nfs.c.
> > 
> 
> Mistake.
> 
> > The actual chain of events is:
> > 1) Parse master map and mount automounts, create
> > daemon/automount.c:handle_mounts thread for each mount.
> > 2) daemon/automount.c:handle_mounts dispatches events as they come in.
> > 3) A missing packet for an indirect mount leads to a call to
> > daemon/indirect.c:handle_packet_missing_indirect.
> > 4) Then -> daemon/indirect.c:do_mount_indirect ->
> > daemon/lookup.c:lookup.c -> modules/lookup_<type>.c:lookup_mount ->
>   daqemon/lookup.c:lookup_nss_mount
> > modules/parse_sun.c:parse_mount -> modules/mount_<type>.c:mount_mount.
> > 
> > Ian


Thanks for this, I start digging deeper now :)

-- 
Lukas

Re: using both nfs3 and nfs4 in a single mount map

[Jeff Moyer]

Ian Kent <raven@themaw.net> writes:

> On Mon, 2007-07-30 at 15:36 +0200, Lukas Kolbe wrote:
>> Hi Ian, thanks for your support!
>> > > 
>> > > Presumably the exports are distinct, in which case using a list of
>> > > server should allow autofs to try each one?
>> 
>> Yep, they are - differnet homes come from different servers. 
>>  
>> > > What about trying something like:
>> > 
>> > On second thoughts this may get only the nfs4 or only the nfs3 servers
>> > as well.
>> 
>> Automount now mounts fine from all servers, but still nfs3
>> only. /proc/mounts shows me:
>> 
>> figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
>> bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
>> 
>> where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
>> really would like to use v4.
>
> Actually, a multi map entry in the master map would probably work.
> Initially I missed this out of version 5 (by accident) so you'll need
> the patch on kernel.org that adds it. In fact I'd recommend applying all
> the 5.0.2 patches.
>
> So forget the last suggestion and patch and apply all the 5.0.2 patches
> on kernel.org and try a line in the master map like:
>
> /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
> 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
>
> and see if that gets what you need. The nfs4 one needs to be first
> because the v4 servers provide both v4 and v3.

That won't work as the cache code will not even add the second set of
entries for the keys:

cache_update:
	} else {
		/* Already seen one of these */
		if (me->age == age)
			return CHE_OK;

-Jeff

Re: using both nfs3 and nfs4 in a single mount map

[Peter Staubach]

Jeff Moyer wrote:
> Ian Kent <raven@themaw.net> writes:
>
>   
>> On Mon, 2007-07-30 at 15:36 +0200, Lukas Kolbe wrote:
>>     
>>> Hi Ian, thanks for your support!
>>>       
>>>>> Presumably the exports are distinct, in which case using a list of
>>>>> server should allow autofs to try each one?
>>>>>           
>>> Yep, they are - differnet homes come from different servers. 
>>>  
>>>       
>>>>> What about trying something like:
>>>>>           
>>>> On second thoughts this may get only the nfs4 or only the nfs3 servers
>>>> as well.
>>>>         
>>> Automount now mounts fine from all servers, but still nfs3
>>> only. /proc/mounts shows me:
>>>
>>> figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
>>> bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
>>>
>>> where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
>>> really would like to use v4.
>>>       
>> Actually, a multi map entry in the master map would probably work.
>> Initially I missed this out of version 5 (by accident) so you'll need
>> the patch on kernel.org that adds it. In fact I'd recommend applying all
>> the 5.0.2 patches.
>>
>> So forget the last suggestion and patch and apply all the 5.0.2 patches
>> on kernel.org and try a line in the master map like:
>>
>> /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
>> 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
>>
>> and see if that gets what you need. The nfs4 one needs to be first
>> because the v4 servers provide both v4 and v3.
>>     
>
> That won't work as the cache code will not even add the second set of
> entries for the keys:
>
> cache_update:
> 	} else {
> 		/* Already seen one of these */
> 		if (me->age == age)
> 			return CHE_OK;

All these excellent suggestions and analysis notwithstanding,
wouldn't it be easier to build a version of the NFS mount
command which defaulted to NFSv4?

    Thanx...

       ps

Re: using both nfs3 and nfs4 in a single mount map

[Jeff Moyer]

Peter Staubach <staubach@redhat.com> writes:

> Jeff Moyer wrote:
>> Ian Kent <raven@themaw.net> writes:
>>
>>
>>> On Mon, 2007-07-30 at 15:36 +0200, Lukas Kolbe wrote:
>>>
>>>> Hi Ian, thanks for your support!
>>>>
>>>>>> Presumably the exports are distinct, in which case using a list of
>>>>>> server should allow autofs to try each one?
>>>>>>
>>>> Yep, they are - differnet homes come from different servers.
>>>>>> What about trying something like:
>>>>>>
>>>>> On second thoughts this may get only the nfs4 or only the nfs3 servers
>>>>> as well.
>>>>>
>>>> Automount now mounts fine from all servers, but still nfs3
>>>> only. /proc/mounts shows me:
>>>>
>>>> figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
>>>> bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
>>>>
>>>> where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
>>>> really would like to use v4.
>>>>
>>> Actually, a multi map entry in the master map would probably work.
>>> Initially I missed this out of version 5 (by accident) so you'll need
>>> the patch on kernel.org that adds it. In fact I'd recommend applying all
>>> the 5.0.2 patches.
>>>
>>> So forget the last suggestion and patch and apply all the 5.0.2 patches
>>> on kernel.org and try a line in the master map like:
>>>
>>> /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
>>> 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
>>>
>>> and see if that gets what you need. The nfs4 one needs to be first
>>> because the v4 servers provide both v4 and v3.
>>>
>>
>> That won't work as the cache code will not even add the second set of
>> entries for the keys:
>>
>> cache_update:
>> 	} else {
>> 		/* Already seen one of these */
>> 		if (me->age == age)
>> 			return CHE_OK;
>
> All these excellent suggestions and analysis notwithstanding,
> wouldn't it be easier to build a version of the NFS mount
> command which defaulted to NFSv4?

Precisely.  I wasn't sure if that was an option, though.  We were slow
to move to nfsv3 as the default, as I recall.

-Jeff

Re: using both nfs3 and nfs4 in a single mount map

[Peter Staubach]

Jeff Moyer wrote:
> Peter Staubach <staubach@redhat.com> writes:
>
>   
>> Jeff Moyer wrote:
>>     
>>> Ian Kent <raven@themaw.net> writes:
>>>
>>>
>>>       
>>>> On Mon, 2007-07-30 at 15:36 +0200, Lukas Kolbe wrote:
>>>>
>>>>         
>>>>> Hi Ian, thanks for your support!
>>>>>
>>>>>           
>>>>>>> Presumably the exports are distinct, in which case using a list of
>>>>>>> server should allow autofs to try each one?
>>>>>>>
>>>>>>>               
>>>>> Yep, they are - differnet homes come from different servers.
>>>>>           
>>>>>>> What about trying something like:
>>>>>>>
>>>>>>>               
>>>>>> On second thoughts this may get only the nfs4 or only the nfs3 servers
>>>>>> as well.
>>>>>>
>>>>>>             
>>>>> Automount now mounts fine from all servers, but still nfs3
>>>>> only. /proc/mounts shows me:
>>>>>
>>>>> figaro:/users/xxx /homes/xxx nfs rw,nosuid,vers=3,rsize=32768,wsize=32768,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=figaro 0 0
>>>>> bongossi:/export/yyy /homes/yyy nfs rw,nosuid,vers=3,rsize=1048576,wsize=1048576,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=bongossi 0 0
>>>>>
>>>>> where figaro only exports nfs v3, bongossi exports both v4 and v3 and we
>>>>> really would like to use v4.
>>>>>
>>>>>           
>>>> Actually, a multi map entry in the master map would probably work.
>>>> Initially I missed this out of version 5 (by accident) so you'll need
>>>> the patch on kernel.org that adds it. In fact I'd recommend applying all
>>>> the 5.0.2 patches.
>>>>
>>>> So forget the last suggestion and patch and apply all the 5.0.2 patches
>>>> on kernel.org and try a line in the master map like:
>>>>
>>>> /homes  multi yp auto_homes -fstype=nfs4,nosuid,grpid,nobrowse,proto=tcp,port=2049 -- \
>>>> 		yp auto_homes -fstype=nfs,nosuid,grpid,nobrowse,proto=tcp,port=2049
>>>>
>>>> and see if that gets what you need. The nfs4 one needs to be first
>>>> because the v4 servers provide both v4 and v3.
>>>>
>>>>         
>>> That won't work as the cache code will not even add the second set of
>>> entries for the keys:
>>>
>>> cache_update:
>>> 	} else {
>>> 		/* Already seen one of these */
>>> 		if (me->age == age)
>>> 			return CHE_OK;
>>>       
>> All these excellent suggestions and analysis notwithstanding,
>> wouldn't it be easier to build a version of the NFS mount
>> command which defaulted to NFSv4?
>>     
>
> Precisely.  I wasn't sure if that was an option, though.  We were slow
> to move to nfsv3 as the default, as I recall.

Actually, I was thinking that these folks who really want to use
NFSv4 could build their version...

Or, they could build a pseudo-wrapper sort of thing for the mount
command and have autofs invoke it.  This way, they could move the
smarts for their policy into it instead of attempting to depend
upon and/or mangle autofs into doing it.

    Thanx...

       ps

Re: using both nfs3 and nfs4 in a single mount map

[Lukas Kolbe]

Hello List!


> We have /homes coming from many different servers, the older ones only
> speak v3 and the newer ones would love to speak v4 as we would.

We do have a solution for this problem now, it seems. A bit of testing
worked fine at least: We just use different yp-maps for solaris and
Linux, and the linux map contains the
"-fstype=nfs4,proto=tcp,port=2049"-Option for the entries on servers
that support it. It seems like a hack, but at least it works.

For this to work, we just have to absolutely make sure that every single
linux machine on the network supports nfs4 ... and I have yet to see a
single one that does this well ;)

-- 
Lukas

Re: using both nfs3 and nfs4 in a single mount map

[Ian Kent]

On Mon, 2007-10-01 at 22:16 +0200, Lukas Kolbe wrote:
> Hello List!
> 
> 
> > We have /homes coming from many different servers, the older ones only
> > speak v3 and the newer ones would love to speak v4 as we would.
> 
> We do have a solution for this problem now, it seems. A bit of testing
> worked fine at least: We just use different yp-maps for solaris and
> Linux, and the linux map contains the
> "-fstype=nfs4,proto=tcp,port=2049"-Option for the entries on servers
> that support it. It seems like a hack, but at least it works.

At least there's a workaround.

> 
> For this to work, we just have to absolutely make sure that every single
> linux machine on the network supports nfs4 ... and I have yet to see a
> single one that does this well ;)
> 

Hehe.

Ian

AutoFS5 Ldap base strangeness

[Jim Summers]

hello all,

I am just about to get my automounting working with autofs5 and my ldap.  I am
able to start the automount daemon and it loads and reads /home map, which
points at ou=auto.home for the user's home directory location and options.

but when i attempt to su - <user> it can not mount the user's home.  here is
what i see in the ldap server's access log:
===
[31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
attrs="automountKey automountInformation"
[31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
etime=0
[31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
===

the weird part of the above is, in the first line it says "cn=sfu" but then
also says automountKey=tmac

the su command is:  su - tmac

so the correct username is tmac not sfu.

any ideas where the sfu thing is coming from??

is the info cached somewhere?  I ask because when I start the daemon, i can
see in the logs where it does:
===
[31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
filter="(objectClass=automount)" attrs="1.1"
[31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
etime=0
===
which is returning 617 entries.

not sure what i have wroong here??

TIA
-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Re: AutoFS5 Ldap base strangeness

[Jeff Moyer]

Jim Summers <jsummers@bachman.cs.ou.edu> writes:

> hello all,
>
> I am just about to get my automounting working with autofs5 and my ldap.  I am
> able to start the automount daemon and it loads and reads /home map, which
> points at ou=auto.home for the user's home directory location and options.
>
> but when i attempt to su - <user> it can not mount the user's home.  here is
> what i see in the ldap server's access log:
> ===
> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
> attrs="automountKey automountInformation"
> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
> etime=0
> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
> ===
>
> the weird part of the above is, in the first line it says "cn=sfu" but then
> also says automountKey=tmac
>
> the su command is:  su - tmac
>
> so the correct username is tmac not sfu.
>
> any ideas where the sfu thing is coming from??
>
> is the info cached somewhere?  I ask because when I start the daemon, i can
> see in the logs where it does:
> ===
> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> filter="(objectClass=automount)" attrs="1.1"
> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
> etime=0
> ===
> which is returning 617 entries.
>
> not sure what i have wroong here??

Please send a debug log:
  http://people.redhat.com/jmoyer

-Jeff

Re: AutoFS5 Ldap base strangeness

[Jim Summers]

Jeff Moyer wrote:
> Jim Summers <jsummers@bachman.cs.ou.edu> writes:
> 
>> hello all,
>>
>> I am just about to get my automounting working with autofs5 and my ldap.  I am
>> able to start the automount daemon and it loads and reads /home map, which
>> points at ou=auto.home for the user's home directory location and options.
>>
>> but when i attempt to su - <user> it can not mount the user's home.  here is
>> what i see in the ldap server's access log:
>> ===
>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
>> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
>> attrs="automountKey automountInformation"
>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
>> etime=0
>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
>> ===
>>
>> the weird part of the above is, in the first line it says "cn=sfu" but then
>> also says automountKey=tmac
>>
>> the su command is:  su - tmac
>>
>> so the correct username is tmac not sfu.
>>
>> any ideas where the sfu thing is coming from??
>>
>> is the info cached somewhere?  I ask because when I start the daemon, i can
>> see in the logs where it does:
>> ===
>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
>> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>> filter="(objectClass=automount)" attrs="1.1"
>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
>> etime=0
>> ===
>> which is returning 617 entries.
>>
>> not sure what i have wroong here??
> 
> Please send a debug log:
>   http://people.redhat.com/jmoyer

Will do Jeff.  Just to cut some time out how can i generate the debug log?  In 
/etc/sysconfig/autofs, i have set:

LOGGING="debug"
and
OPTIONS="-v"

but that seems to only increase the noise in /var/log/messages a little.

i do have the following installed:

autofs-5.0.1-20
autofs-debuginfo-5.0.1-20

and by the way, i am building those from source rpms. before i actually do an 
rpmbuild i run a patch that Ian had sent me.  it fixes a syntax issue when you 
have a dc that is named ou.  after the last updates it quit working, so i 
grabbed the src.rpm and rebuilt again.  i guess the patch hasn't made into the 
repos yet.

thanks again


> 
> -Jeff
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Re: AutoFS5 Ldap base strangeness

[Jeff Moyer]

Jim Summers <jsummers@bachman.cs.ou.edu> writes:

> Jeff Moyer wrote:
>> Jim Summers <jsummers@bachman.cs.ou.edu> writes:
>>
>>> hello all,
>>>
>>> I am just about to get my automounting working with autofs5 and my ldap.  I am
>>> able to start the automount daemon and it loads and reads /home map, which
>>> points at ou=auto.home for the user's home directory location and options.
>>>
>>> but when i attempt to su - <user> it can not mount the user's home.  here is
>>> what i see in the ldap server's access log:
>>> ===
>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
>>> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>>> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
>>> attrs="automountKey automountInformation"
>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
>>> etime=0
>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
>>> ===
>>>
>>> the weird part of the above is, in the first line it says "cn=sfu" but then
>>> also says automountKey=tmac
>>>
>>> the su command is:  su - tmac
>>>
>>> so the correct username is tmac not sfu.
>>>
>>> any ideas where the sfu thing is coming from??
>>>
>>> is the info cached somewhere?  I ask because when I start the daemon, i can
>>> see in the logs where it does:
>>> ===
>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
>>> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>>> filter="(objectClass=automount)" attrs="1.1"
>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
>>> etime=0
>>> ===
>>> which is returning 617 entries.
>>>
>>> not sure what i have wroong here??
>>
>> Please send a debug log:
>>   http://people.redhat.com/jmoyer
>
> Will do Jeff.  Just to cut some time out how can i generate the debug
> log?  In /etc/sysconfig/autofs, i have set:
>
> LOGGING="debug"
> and
> OPTIONS="-v"
>
> but that seems to only increase the noise in /var/log/messages a little.
>
> i do have the following installed:
>
> autofs-5.0.1-20
> autofs-debuginfo-5.0.1-20

From the web page to which I pointed you:

---
debug output.

    * Add a line like the following to your /etc/syslog.conf:

      daemon.*			/var/log/debug

Restart syslogd (or send it a HUP signal).
---

-Jeff

Re: AutoFS5 Ldap base strangeness

[Jim Summers]

[-- Attachment #1: Type: text/plain, Size: 2882 bytes --]

Jeff Moyer wrote:
> Jim Summers <jsummers@bachman.cs.ou.edu> writes:
> 
>> Jeff Moyer wrote:
>>> Jim Summers <jsummers@bachman.cs.ou.edu> writes:
>>>
>>>> hello all,
>>>>
>>>> I am just about to get my automounting working with autofs5 and my ldap.  I am
>>>> able to start the automount daemon and it loads and reads /home map, which
>>>> points at ou=auto.home for the user's home directory location and options.
>>>>
>>>> but when i attempt to su - <user> it can not mount the user's home.  here is
>>>> what i see in the ldap server's access log:
>>>> ===
>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
>>>> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>>>> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
>>>> attrs="automountKey automountInformation"
>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
>>>> etime=0
>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
>>>> ===
>>>>
>>>> the weird part of the above is, in the first line it says "cn=sfu" but then
>>>> also says automountKey=tmac
>>>>
>>>> the su command is:  su - tmac
>>>>
>>>> so the correct username is tmac not sfu.
>>>>
>>>> any ideas where the sfu thing is coming from??
>>>>
>>>> is the info cached somewhere?  I ask because when I start the daemon, i can
>>>> see in the logs where it does:
>>>> ===
>>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
>>>> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>>>> filter="(objectClass=automount)" attrs="1.1"
>>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
>>>> etime=0
>>>> ===
>>>> which is returning 617 entries.
>>>>
>>>> not sure what i have wroong here??
>>> Please send a debug log:
>>>   http://people.redhat.com/jmoyer
>> Will do Jeff.  Just to cut some time out how can i generate the debug
>> log?  In /etc/sysconfig/autofs, i have set:
>>
>> LOGGING="debug"
>> and
>> OPTIONS="-v"
>>
>> but that seems to only increase the noise in /var/log/messages a little.
>>
>> i do have the following installed:
>>
>> autofs-5.0.1-20
>> autofs-debuginfo-5.0.1-20
> 

>>From the web page to which I pointed you:
> 
> ---
> debug output.
> 
>     * Add a line like the following to your /etc/syslog.conf:
> 
>       daemon.*			/var/log/debug
> 
> Restart syslogd (or send it a HUP signal).
> ---
> 
> -Jeff

Sorry Jeff.  Got it done.  i have attached the debug file.  let me know if I 
should inline it or what works best.

from what i can decipher it appears to be trying to pull the auto.home stuff 
from under the cn=sfu.  but that doesn't make sense to me.

thanks again.

> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

[-- Attachment #2: debug --]
[-- Type: text/plain, Size: 34630 bytes --]

Aug  2 16:21:44 leech automount[13929]: Starting automounter version 5.0.1-20, master map auto.master
Aug  2 16:21:44 leech automount[13929]: using kernel protocol version 5.00
Aug  2 16:21:44 leech automount[13929]: lookup_nss_read_master: reading master files auto.master
Aug  2 16:21:44 leech automount[13929]: parse_init: parse(sun): init gathered global options: (null)
Aug  2 16:21:44 leech automount[13929]: mount_init: mount(bind): bind_works = 1
Aug  2 16:21:44 leech automount[13929]: lookup_read_master: lookup(file): read entry /misc
Aug  2 16:21:44 leech automount[13929]: lookup_read_master: lookup(file): read entry /net
Aug  2 16:21:44 leech automount[13929]: lookup_read_master: lookup(file): read entry /home
Aug  2 16:21:44 leech automount[13929]: master_do_mount: mounting /misc
Aug  2 16:21:44 leech automount[13929]: lookup_nss_read_map: reading map file /etc/auto.misc
Aug  2 16:21:44 leech automount[13929]: parse_init: parse(sun): init gathered global options: (null)
Aug  2 16:21:44 leech automount[13929]: mount_init: mount(bind): bind_works = 1
Aug  2 16:21:44 leech automount[13929]: mounted indirect mount on /misc with timeout 300, freq 75 seconds
Aug  2 16:21:44 leech automount[13929]: master_do_mount: mounting /net
Aug  2 16:21:44 leech automount[13929]: lookup_nss_read_map: reading map hosts (null)
Aug  2 16:21:44 leech automount[13929]: parse_init: parse(sun): init gathered global options: (null)
Aug  2 16:21:44 leech automount[13929]: mounted indirect mount on /net with timeout 300, freq 75 seconds
Aug  2 16:21:44 leech automount[13929]: master_do_mount: mounting /home
Aug  2 16:21:44 leech automount[13929]: lookup_nss_read_map: reading map ldap //landin/ou=auto.home,dc=it,dc=ou,dc=edu
Aug  2 16:21:44 leech automount[13929]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "//landin/ou=auto.home,dc=it,dc=ou,dc=edu".
Aug  2 16:21:44 leech automount[13929]: parse_server_string: lookup(ldap): server "landin", base dn "ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:21:44 leech automount[13929]: parse_ldap_config: ldap authentication configured with the following options: 
Aug  2 16:21:44 leech automount[13929]: parse_ldap_config: use_tls: 0, tls_required: 0, auth_required: 1, sasl_mech: (null) 
Aug  2 16:21:44 leech automount[13929]: parse_ldap_config: user: (null), secret: unspecified, client principal: (null) 
Aug  2 16:21:44 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:21:44 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:21:44 leech automount[13929]: get_query_dn: lookup(ldap): query dn cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu
Aug  2 16:21:44 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:21:44 leech automount[13929]: parse_init: parse(sun): init gathered global options: (null)
Aug  2 16:21:44 leech automount[13929]: mounted indirect mount on /home with timeout 300, freq 75 seconds
Aug  2 16:22:52 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:52 leech automount[13929]: handle_packet_missing_indirect: token 100, name tmac, request pid 13941
Aug  2 16:22:52 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:52 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:52 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:52 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:52 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:52 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:52 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:52 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:52 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:52 leech automount[13929]: send_fail: token = 100
Aug  2 16:22:52 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:52 leech automount[13929]: handle_packet_missing_indirect: token 101, name tmac, request pid 13941
Aug  2 16:22:52 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:52 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:52 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:52 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:52 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:52 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:52 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:52 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:52 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:52 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 101
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 102, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 102
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 103, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 103
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 104, name tmac, request pid 13947
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 104
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 105, name tmac, request pid 13947
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 105
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 106, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 106
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 107, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 107
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 108, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 108
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 109, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 109
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 110, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 110
Aug  2 16:22:53 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:53 leech automount[13929]: handle_packet_missing_indirect: token 111, name tmac, request pid 13941
Aug  2 16:22:53 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:53 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:53 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:53 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:53 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:53 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:53 leech automount[13929]: send_fail: token = 111
Aug  2 16:22:53 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:54 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:54 leech automount[13929]: handle_packet_missing_indirect: token 112, name tmac, request pid 13941
Aug  2 16:22:54 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:54 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:54 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:54 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:54 leech automount[13929]: send_fail: token = 112
Aug  2 16:22:54 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:54 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:54 leech automount[13929]: handle_packet_missing_indirect: token 113, name tmac, request pid 13941
Aug  2 16:22:54 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:54 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:54 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:54 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:54 leech automount[13929]: send_fail: token = 113
Aug  2 16:22:54 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:54 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:54 leech automount[13929]: handle_packet_missing_indirect: token 114, name tmac, request pid 13941
Aug  2 16:22:54 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:54 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:54 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:54 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:54 leech automount[13929]: send_fail: token = 114
Aug  2 16:22:54 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:54 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:54 leech automount[13929]: handle_packet_missing_indirect: token 115, name tmac, request pid 13941
Aug  2 16:22:54 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:54 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:54 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:54 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:54 leech automount[13929]: send_fail: token = 115
Aug  2 16:22:54 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:54 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:54 leech automount[13929]: handle_packet_missing_indirect: token 116, name tmac, request pid 13941
Aug  2 16:22:54 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:54 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:54 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:54 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:54 leech automount[13929]: send_fail: token = 116
Aug  2 16:22:54 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:54 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:54 leech automount[13929]: handle_packet_missing_indirect: token 117, name tmac, request pid 13941
Aug  2 16:22:54 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:54 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:54 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:54 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:54 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:54 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:54 leech automount[13929]: send_fail: token = 117
Aug  2 16:22:54 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:57 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:57 leech automount[13929]: handle_packet_missing_indirect: token 118, name tmac, request pid 13941
Aug  2 16:22:57 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:57 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:57 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:57 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:57 leech automount[13929]: send_fail: token = 118
Aug  2 16:22:57 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:57 leech automount[13929]: handle_packet_missing_indirect: token 119, name tmac, request pid 13941
Aug  2 16:22:57 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:57 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:57 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:57 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:57 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:57 leech automount[13929]: send_fail: token = 119
Aug  2 16:22:57 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:57 leech automount[13929]: handle_packet_missing_indirect: token 120, name tmac, request pid 13941
Aug  2 16:22:57 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:57 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:57 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:57 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:57 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:57 leech automount[13929]: send_fail: token = 120
Aug  2 16:22:57 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:57 leech automount[13929]: handle_packet_missing_indirect: token 121, name tmac, request pid 13941
Aug  2 16:22:57 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:57 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:57 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:57 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:57 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:57 leech automount[13929]: send_fail: token = 121
Aug  2 16:22:57 leech automount[13929]: handle_packet: type = 3
Aug  2 16:22:57 leech automount[13929]: handle_packet_missing_indirect: token 122, name tmac, request pid 13941
Aug  2 16:22:57 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:22:57 leech automount[13929]: attempting to mount entry /home/tmac
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): looking up tmac
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): searching for "(&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))" under "cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu"
Aug  2 16:22:57 leech automount[13929]: do_connect: auth_required: 1, sasl_mech (null)
Aug  2 16:22:57 leech automount[13929]: do_connect: lookup(ldap): ldap anonymous bind returned 0
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): getting first entry for automountKey="tmac"
Aug  2 16:22:57 leech automount[13929]: lookup_one: lookup(ldap): got answer, but no entry for (&(objectclass=automount)(|(automountKey=tmac)(automountKey=/)))
Aug  2 16:22:57 leech automount[13929]: unbind_ldap_connection: use_tls: 0
Aug  2 16:22:57 leech automount[13929]: lookup_mount: lookup(ldap): check indirect map failure
Aug  2 16:22:57 leech automount[13929]: send_fail: token = 122
Aug  2 16:22:57 leech automount[13929]: failed to mount /home/tmac
Aug  2 16:23:02 leech automount[13929]: do_notify_state: signal 15
Aug  2 16:23:02 leech automount[13929]: master_notify_state_change: sig 15 switching /misc from 1 to 5
Aug  2 16:23:02 leech automount[13929]: st_prepare_shutdown: state 1 path /misc
Aug  2 16:23:02 leech automount[13929]: expire_proc: exp_proc = 3082414992 path /misc
Aug  2 16:23:02 leech automount[13929]: expire_cleanup: got thid 3082414992 path /misc stat 0
Aug  2 16:23:02 leech automount[13929]: expire_cleanup: sigchld: exp 3082414992 finished, switching from 5 to 7
Aug  2 16:23:02 leech automount[13929]: umount_multi: path /misc incl 0
Aug  2 16:23:02 leech automount[13929]: master_notify_state_change: sig 15 switching /net from 1 to 5
Aug  2 16:23:02 leech automount[13929]: st_prepare_shutdown: state 1 path /net
Aug  2 16:23:02 leech automount[13929]: expire_proc: exp_proc = 3082414992 path /net
Aug  2 16:23:02 leech automount[13929]: expire_cleanup: got thid 3082414992 path /net stat 0
Aug  2 16:23:02 leech automount[13929]: expire_cleanup: sigchld: exp 3082414992 finished, switching from 5 to 7
Aug  2 16:23:02 leech automount[13929]: umount_multi: path /net incl 0
Aug  2 16:23:02 leech automount[13929]: master_notify_state_change: sig 15 switching /home from 1 to 5
Aug  2 16:23:02 leech automount[13929]: st_prepare_shutdown: state 1 path /home
Aug  2 16:23:02 leech automount[13929]: expire_proc: exp_proc = 3082414992 path /home
Aug  2 16:23:02 leech automount[13929]: expire_cleanup: got thid 3082414992 path /home stat 0
Aug  2 16:23:02 leech automount[13929]: expire_cleanup: sigchld: exp 3082414992 finished, switching from 5 to 7
Aug  2 16:23:02 leech automount[13929]: umount_multi: path /home incl 0
Aug  2 16:23:02 leech automount[13929]: umounted indirect mount /home
Aug  2 16:23:02 leech automount[13929]: umounted indirect mount /misc
Aug  2 16:23:02 leech automount[13929]: umounted indirect mount /net
Aug  2 16:23:02 leech automount[13929]: shut down path /home
Aug  2 16:23:02 leech automount[13929]: shut down path /misc
Aug  2 16:23:02 leech automount[13929]: shut down path /net

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: AutoFS5 Ldap base strangeness

[Jeff Moyer]

Jim Summers <jsummers@bachman.cs.ou.edu> writes:

> Jeff Moyer wrote:
>> Jim Summers <jsummers@bachman.cs.ou.edu> writes:
>>
>>> Jeff Moyer wrote:
>>>> Jim Summers <jsummers@bachman.cs.ou.edu> writes:
>>>>
>>>>> hello all,
>>>>>
>>>>> I am just about to get my automounting working with autofs5 and my ldap.  I am
>>>>> able to start the automount daemon and it loads and reads /home map, which
>>>>> points at ou=auto.home for the user's home directory location and options.
>>>>>
>>>>> but when i attempt to su - <user> it can not mount the user's home.  here is
>>>>> what i see in the ldap server's access log:
>>>>> ===
>>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
>>>>> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>>>>> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
>>>>> attrs="automountKey automountInformation"
>>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
>>>>> etime=0
>>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
>>>>> ===

OK, now I'd like to get the ldap server messages that preceded this.
Specifically, I'd like to see the query done for
(&(objectclass=automountMap)(ou=auto.home)).  I think that's the
schema you're using.

-Jeff

Re: AutoFS5 Ldap base strangeness

[Ian Kent]

On Thu, 2007-08-02 at 16:31 -0500, Jim Summers wrote:
> Jeff Moyer wrote:
> > Jim Summers <jsummers@bachman.cs.ou.edu> writes:
> > 
> >> Jeff Moyer wrote:
> >>> Jim Summers <jsummers@bachman.cs.ou.edu> writes:
> >>>
> >>>> hello all,
> >>>>
> >>>> I am just about to get my automounting working with autofs5 and my ldap.  I am
> >>>> able to start the automount daemon and it loads and reads /home map, which
> >>>> points at ou=auto.home for the user's home directory location and options.
> >>>>
> >>>> but when i attempt to su - <user> it can not mount the user's home.  here is
> >>>> what i see in the ldap server's access log:
> >>>> ===
> >>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
> >>>> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> >>>> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
> >>>> attrs="automountKey automountInformation"
> >>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
> >>>> etime=0
> >>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
> >>>> ===
> >>>>
> >>>> the weird part of the above is, in the first line it says "cn=sfu" but then
> >>>> also says automountKey=tmac
> >>>>
> >>>> the su command is:  su - tmac
> >>>>
> >>>> so the correct username is tmac not sfu.
> >>>>
> >>>> any ideas where the sfu thing is coming from??
> >>>>
> >>>> is the info cached somewhere?  I ask because when I start the daemon, i can
> >>>> see in the logs where it does:
> >>>> ===
> >>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
> >>>> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> >>>> filter="(objectClass=automount)" attrs="1.1"
> >>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
> >>>> etime=0
> >>>> ===
> >>>> which is returning 617 entries.
> >>>>
> >>>> not sure what i have wroong here??
> >>> Please send a debug log:
> >>>   http://people.redhat.com/jmoyer
> >> Will do Jeff.  Just to cut some time out how can i generate the debug
> >> log?  In /etc/sysconfig/autofs, i have set:
> >>
> >> LOGGING="debug"
> >> and
> >> OPTIONS="-v"
> >>
> >> but that seems to only increase the noise in /var/log/messages a little.
> >>
> >> i do have the following installed:
> >>
> >> autofs-5.0.1-20
> >> autofs-debuginfo-5.0.1-20
> > 
> 
> >>From the web page to which I pointed you:
> > 
> > ---
> > debug output.
> > 
> >     * Add a line like the following to your /etc/syslog.conf:
> > 
> >       daemon.*			/var/log/debug
> > 
> > Restart syslogd (or send it a HUP signal).
> > ---
> > 
> > -Jeff
> 
> Sorry Jeff.  Got it done.  i have attached the debug file.  let me know if I 
> should inline it or what works best.
> 
> from what i can decipher it appears to be trying to pull the auto.home stuff 
> from under the cn=sfu.  but that doesn't make sense to me.

Indeed it is.

Snip ...

> Aug  2 16:21:44 leech automount[13929]: lookup_nss_read_map: reading
> map ldap //landin/ou=auto.home,dc=it,dc=ou,dc=edu
> Aug  2 16:21:44 leech automount[13929]: parse_server_string:
> lookup(ldap): Attempting to parse LDAP information from string
> "//landin/ou=auto.home,dc=it,dc=ou,dc=edu".
> Aug  2 16:21:44 leech automount[13929]: parse_server_string:
> lookup(ldap): server "landin", base dn
> "ou=auto.home,dc=it,dc=ou,dc=edu"

And we've been told what the base dn is here.

> Aug  2 16:21:44 leech automount[13929]: parse_ldap_config: ldap
> authentication configured with the following options: 
> Aug  2 16:21:44 leech automount[13929]: parse_ldap_config: use_tls: 0,
> tls_required: 0, auth_required: 1, sasl_mech: (null) 
> Aug  2 16:21:44 leech automount[13929]: parse_ldap_config: user:
> (null), secret: unspecified, client principal: (null) 
> Aug  2 16:21:44 leech automount[13929]: do_connect: auth_required: 1,
> sasl_mech (null)
> Aug  2 16:21:44 leech automount[13929]: do_connect: lookup(ldap): ldap
> anonymous bind returned 0
> Aug  2 16:21:44 leech automount[13929]: get_query_dn: lookup(ldap):
> query dn cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu

But then it seems that this dn has objectclass automountMap and is under
ou=auto.home,dc=it,dc=ou,dc=edu.

I suspect that making this case in get_query_dn a subtree search was a
mistake. There is also a question about whether we should connect to the
LDAP server at all at this point since we've been given the base dn. I'd
rather continue to connect in order to validate the base dn and server
availability.

Could you try this patch please.

Ian

---
diff --git a/modules/lookup_ldap.c b/modules/lookup_ldap.c
index de8d515..73d393f 100644
--- a/modules/lookup_ldap.c
+++ b/modules/lookup_ldap.c
@@ -859,7 +859,7 @@ static int get_query_dn(LDAP *ldap, struct lookup_context *ctxt)
 			      MODPREFIX "error forming query string");
 			return 0;
 		}
-		scope = LDAP_SCOPE_SUBTREE;
+		scope = LDAP_SCOPE_ONE;
 	}
 	query[l] = '\0';

Re: AutoFS5 Ldap base strangeness

[Ian Kent]

On Thu, 2007-08-02 at 16:08 -0500, Jim Summers wrote:
> Jeff Moyer wrote:
> > Jim Summers <jsummers@bachman.cs.ou.edu> writes:
> i do have the following installed:
> 
> autofs-5.0.1-20
> autofs-debuginfo-5.0.1-20
> 
> and by the way, i am building those from source rpms. before i actually do an 
> rpmbuild i run a patch that Ian had sent me.  it fixes a syntax issue when you 
> have a dc that is named ou.  after the last updates it quit working, so i 
> grabbed the src.rpm and rebuilt again.  i guess the patch hasn't made into the 
> repos yet.

That is in autofs-5.0.2-21 which should be on the mirrors.

Ian

Re: AutoFS5 Ldap base strangeness

[Ian Kent]

On Thu, 2007-08-02 at 15:26 -0500, Jim Summers wrote:
> hello all,
> 
> I am just about to get my automounting working with autofs5 and my ldap.  I am
> able to start the automount daemon and it loads and reads /home map, which
> points at ou=auto.home for the user's home directory location and options.
> 
> but when i attempt to su - <user> it can not mount the user's home.  here is
> what i see in the ldap server's access log:
> ===
> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
> attrs="automountKey automountInformation"
> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
> etime=0
> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
> ===
> 
> the weird part of the above is, in the first line it says "cn=sfu" but then
> also says automountKey=tmac
> 
> the su command is:  su - tmac
> 
> so the correct username is tmac not sfu.
> 
> any ideas where the sfu thing is coming from??
> 
> is the info cached somewhere?  I ask because when I start the daemon, i can
> see in the logs where it does:
> ===
> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> filter="(objectClass=automount)" attrs="1.1"
> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
> etime=0
> ===
> which is returning 617 entries.
> 
> not sure what i have wroong here??

Me neither.

How about posting an ldapsearch of the auto.home and what's used for the
master map.

Ian

Re: AutoFS5 Ldap base strangeness

[Jim Summers]

Ian Kent wrote:
> On Thu, 2007-08-02 at 15:26 -0500, Jim Summers wrote:
>> hello all,
>>
>> I am just about to get my automounting working with autofs5 and my ldap.  I am
>> able to start the automount daemon and it loads and reads /home map, which
>> points at ou=auto.home for the user's home directory location and options.
>>
>> but when i attempt to su - <user> it can not mount the user's home.  here is
>> what i see in the ldap server's access log:
>> ===
>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
>> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
>> attrs="automountKey automountInformation"
>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
>> etime=0
>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
>> ===
>>
>> the weird part of the above is, in the first line it says "cn=sfu" but then
>> also says automountKey=tmac
>>
>> the su command is:  su - tmac
>>
>> so the correct username is tmac not sfu.
>>
>> any ideas where the sfu thing is coming from??
>>
>> is the info cached somewhere?  I ask because when I start the daemon, i can
>> see in the logs where it does:
>> ===
>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
>> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>> filter="(objectClass=automount)" attrs="1.1"
>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
>> etime=0
>> ===
>> which is returning 617 entries.
>>
>> not sure what i have wroong here??
> 
> Me neither.
> 
> How about posting an ldapsearch of the auto.home and what's used for the
> master map.

I think you may be on to something.

Here is the auto.master

/home   ldap://landin/ou=auto.home,dc=it,dc=ou,dc=edu

and here is a snip from an ldapsearch of auto.home.

dn: ou=auto.home,dc=it,dc=ou,dc=edu
objectClass: top
objectClass: organizationalUnit
ou: auto.home

dn: cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu
objectClass: automount
objectClass: nisObject
objectClass: top
cn: sfu
automountKey: sfu
automountInformation: -rw,rsize=4096,wsize=4096 turing:/it/turing/home2/sfu
nisMapEntry: turing:/it/turing/home2/sfu
nisMapName: auto.home

dn: cn=cfranklin,ou=auto.home,dc=it,dc=ou,dc=edu
objectClass: automount
objectClass: nisObject
objectClass: top
cn: cfranklin
automountKey: cfranklin
automountInformation: -rw,rsize=8192,wsize=8192 rabin:/raid/facstaff/cfranklin
nisMapEntry: rabin:/raid/facstaff/cfranklin
nisMapName: auto.home

naturally there are several hundred more user entries.

what do you think?

tia


> 
> Ian
> 
> 
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs

-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------

Re: AutoFS5 Ldap base strangeness

[Ian Kent]

On Fri, 2007-08-03 at 13:18 -0500, Jim Summers wrote:
> Ian Kent wrote:
> > On Thu, 2007-08-02 at 15:26 -0500, Jim Summers wrote:
> >> hello all,
> >>
> >> I am just about to get my automounting working with autofs5 and my ldap.  I am
> >> able to start the automount daemon and it loads and reads /home map, which
> >> points at ou=auto.home for the user's home directory location and options.
> >>
> >> but when i attempt to su - <user> it can not mount the user's home.  here is
> >> what i see in the ldap server's access log:
> >> ===
> >> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
> >> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> >> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
> >> attrs="automountKey automountInformation"
> >> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
> >> etime=0
> >> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
> >> ===
> >>
> >> the weird part of the above is, in the first line it says "cn=sfu" but then
> >> also says automountKey=tmac
> >>
> >> the su command is:  su - tmac
> >>
> >> so the correct username is tmac not sfu.
> >>
> >> any ideas where the sfu thing is coming from??
> >>
> >> is the info cached somewhere?  I ask because when I start the daemon, i can
> >> see in the logs where it does:
> >> ===
> >> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
> >> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
> >> filter="(objectClass=automount)" attrs="1.1"
> >> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
> >> etime=0
> >> ===
> >> which is returning 617 entries.
> >>
> >> not sure what i have wroong here??
> > 
> > Me neither.
> > 
> > How about posting an ldapsearch of the auto.home and what's used for the
> > master map.
> 
> I think you may be on to something.
> 
> Here is the auto.master
> 
> /home   ldap://landin/ou=auto.home,dc=it,dc=ou,dc=edu
> 
> and here is a snip from an ldapsearch of auto.home.
> 
> dn: ou=auto.home,dc=it,dc=ou,dc=edu
> objectClass: top
> objectClass: organizationalUnit
> ou: auto.home

I don't think version 5 will let you get away with not adding
objectClass: automountMap
in this entry or maybe
objectClass: nisMap
at least I think those are the class names.

> 
> dn: cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu
> objectClass: automount
> objectClass: nisObject
> objectClass: top
> cn: sfu
> automountKey: sfu
> automountInformation: -rw,rsize=4096,wsize=4096 turing:/it/turing/home2/sfu
> nisMapEntry: turing:/it/turing/home2/sfu
> nisMapName: auto.home
> 
> dn: cn=cfranklin,ou=auto.home,dc=it,dc=ou,dc=edu
> objectClass: automount
> objectClass: nisObject
> objectClass: top
> cn: cfranklin
> automountKey: cfranklin
> automountInformation: -rw,rsize=8192,wsize=8192 rabin:/raid/facstaff/cfranklin
> nisMapEntry: rabin:/raid/facstaff/cfranklin
> nisMapName: auto.home
> 
> naturally there are several hundred more user entries.
> 
> what do you think?
> 
> tia
> 
> 
> > 
> > Ian
> > 
> > 
> > _______________________________________________
> > autofs mailing list
> > autofs@linux.kernel.org
> > http://linux.kernel.org/mailman/listinfo/autofs
> 

Re: AutoFS5 Ldap base strangeness

[Jim Summers]

Ian Kent wrote:
> On Fri, 2007-08-03 at 13:18 -0500, Jim Summers wrote:
>> Ian Kent wrote:
>>> On Thu, 2007-08-02 at 15:26 -0500, Jim Summers wrote:
>>>> hello all,
>>>>
>>>> I am just about to get my automounting working with autofs5 and my ldap.  I am
>>>> able to start the automount daemon and it loads and reads /home map, which
>>>> points at ou=auto.home for the user's home directory location and options.
>>>>
>>>> but when i attempt to su - <user> it can not mount the user's home.  here is
>>>> what i see in the ldap server's access log:
>>>> ===
>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 SRCH
>>>> base="cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>>>> filter="(&(objectClass=automount)(|(automountKey=tmac)(automountKey=/)))"
>>>> attrs="automountKey automountInformation"
>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=1 RESULT err=0 tag=101 nentries=0
>>>> etime=0
>>>> [31/Jul/2007:15:28:19 -0500] conn=8420 op=2 UNBIND
>>>> ===
>>>>
>>>> the weird part of the above is, in the first line it says "cn=sfu" but then
>>>> also says automountKey=tmac
>>>>
>>>> the su command is:  su - tmac
>>>>
>>>> so the correct username is tmac not sfu.
>>>>
>>>> any ideas where the sfu thing is coming from??
>>>>
>>>> is the info cached somewhere?  I ask because when I start the daemon, i can
>>>> see in the logs where it does:
>>>> ===
>>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 SRCH
>>>> base="ou=auto.home,dc=it,dc=ou,dc=edu" scope=2
>>>> filter="(objectClass=automount)" attrs="1.1"
>>>> [31/Jul/2007:15:35:40 -0500] conn=8536 op=1 RESULT err=0 tag=101 nentries=617
>>>> etime=0
>>>> ===
>>>> which is returning 617 entries.
>>>>
>>>> not sure what i have wroong here??
>>> Me neither.
>>>
>>> How about posting an ldapsearch of the auto.home and what's used for the
>>> master map.
>> I think you may be on to something.
>>
>> Here is the auto.master
>>
>> /home   ldap://landin/ou=auto.home,dc=it,dc=ou,dc=edu
>>
>> and here is a snip from an ldapsearch of auto.home.
>>
>> dn: ou=auto.home,dc=it,dc=ou,dc=edu
>> objectClass: top
>> objectClass: organizationalUnit
>> ou: auto.home
> 
> I don't think version 5 will let you get away with not adding
> objectClass: automountMap
> in this entry or maybe
> objectClass: nisMap
> at least I think those are the class names.

Excellent, that has fixed the problem. after adding:

objectClass: automountMap
automountMapName: auto.home

then the homes were mountable.

Many Thanks!


> 
>> dn: cn=sfu,ou=auto.home,dc=it,dc=ou,dc=edu
>> objectClass: automount
>> objectClass: nisObject
>> objectClass: top
>> cn: sfu
>> automountKey: sfu
>> automountInformation: -rw,rsize=4096,wsize=4096 turing:/it/turing/home2/sfu
>> nisMapEntry: turing:/it/turing/home2/sfu
>> nisMapName: auto.home
>>
>> dn: cn=cfranklin,ou=auto.home,dc=it,dc=ou,dc=edu
>> objectClass: automount
>> objectClass: nisObject
>> objectClass: top
>> cn: cfranklin
>> automountKey: cfranklin
>> automountInformation: -rw,rsize=8192,wsize=8192 rabin:/raid/facstaff/cfranklin
>> nisMapEntry: rabin:/raid/facstaff/cfranklin
>> nisMapName: auto.home
>>
>> naturally there are several hundred more user entries.
>>
>> what do you think?
>>
>> tia
>>
>>
>>> Ian
>>>
>>>
>>> _______________________________________________
>>> autofs mailing list
>>> autofs@linux.kernel.org
>>> http://linux.kernel.org/mailman/listinfo/autofs

-- 
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------