direct map shut down?

direct map shut down?

[Brian Long]

Hello,

I'm just starting to mess around with autofs4 on RHEL 3.  I've installed
the autofs4.o module from kernel-unsupported and added the appropriate
modules.conf entry.  When autofs starts, it reads my auto.master
properly, but immediately shuts down the /- entry.  Why?

/etc/auto.master:
/misc  /etc/auto.misc  --timeout 60
/tools nisplus:auto_tools rw,hard,intr,noquota,timeo=15
/auto /etc/auto.indirect rsize=32768,wsize=32768,tcp
/users nisplus:auto_home rw,hard,intr,rsize=32768,wsize=32768,tcp
/- /etc/auto.direct rsize=32768,wsize=32768,tcp

/etc/auto.direct
/netapp/rtp-filer01a    rtp-filer01a:/vol/vol0

Also, is there a version of the kernel module or user utils that would
support multiple direct mounts under the same mount point?  For example,
I want to mount rtp-filer01a:/vol/local1 under
/netapp/rtp-filer01a/vol/local1  :)

Thanks!

/Brian/
-- 
       Brian Long                      |         |           |
       Americas IT Hosting Sys Admin   |       .|||.       .|||.
       Cisco Linux Developer           |   ..:|||||||:...:|||||||:..
       Phone: (919) 392-7363           |   C i s c o   S y s t e m s

Re: direct map shut down?

[Brian Long]

As a follow-up, /var/log/messages lists the following:

Feb 19 12:07:03 machello automount[1600]: starting automounter version 4.1.0, path = /misc, maptype = file, mapname = /etc/auto.misc
Feb 19 12:07:03 machello automount[1620]: starting automounter version 4.1.0, path = /tools, maptype = nisplus, mapname = auto_tools
Feb 19 12:07:03 machello automount[1646]: starting automounter version 4.1.0, path = /auto, maptype = file, mapname = /etc/auto.indirect
Feb 19 12:07:03 machello automount[1678]: starting automounter version 4.1.0, path = /users, maptype = nisplus, mapname = auto_home
Feb 19 12:07:03 machello automount[1620]: using kernel protocol version 4.03
Feb 19 12:07:03 machello automount[1620]: using timeout 300 seconds; freq 75 secs
Feb 19 12:07:03 machello automount[1646]: using kernel protocol version 4.03
Feb 19 12:07:03 machello automount[1646]: using timeout 300 seconds; freq 75 secs
Feb 19 12:07:03 machello automount[1600]: using kernel protocol version 4.03
Feb 19 12:07:03 machello automount[1600]: using timeout 60 seconds; freq 15 secs
Feb 19 12:07:03 machello automount[1678]: using kernel protocol version 4.03
Feb 19 12:07:03 machello automount[1678]: using timeout 300 seconds; freq 75 secs
Feb 19 12:07:03 machello automount[1708]: starting automounter version 4.1.0, path = /-, maptype = file, mapname = /etc/auto.direct
Feb 19 12:07:03 machello autofs: automount startup succeeded
Feb 19 12:07:03 machello automount[1708]: shut down, path = /-

Thanks for any help you can provide.

/Brian/
-- 
       Brian Long                      |         |           |
       Americas IT Hosting Sys Admin   |       .|||.       .|||.
       Cisco Linux Developer           |   ..:|||||||:...:|||||||:..
       Phone: (919) 392-7363           |   C i s c o   S y s t e m s

Re: direct map shut down?

[Ian Kent]

On Thu, 19 Feb 2004, Brian Long wrote:

> As a follow-up, /var/log/messages lists the following:
> 
> Feb 19 12:07:03 machello automount[1600]: starting automounter version 4.1.0, path = /misc, maptype = file, mapname = /etc/auto.misc
> Feb 19 12:07:03 machello automount[1620]: starting automounter version 4.1.0, path = /tools, maptype = nisplus, mapname = auto_tools
> Feb 19 12:07:03 machello automount[1646]: starting automounter version 4.1.0, path = /auto, maptype = file, mapname = /etc/auto.indirect
> Feb 19 12:07:03 machello automount[1678]: starting automounter version 4.1.0, path = /users, maptype = nisplus, mapname = auto_home
> Feb 19 12:07:03 machello automount[1620]: using kernel protocol version 4.03
> Feb 19 12:07:03 machello automount[1620]: using timeout 300 seconds; freq 75 secs
> Feb 19 12:07:03 machello automount[1646]: using kernel protocol version 4.03
> Feb 19 12:07:03 machello automount[1646]: using timeout 300 seconds; freq 75 secs
> Feb 19 12:07:03 machello automount[1600]: using kernel protocol version 4.03
> Feb 19 12:07:03 machello automount[1600]: using timeout 60 seconds; freq 15 secs
> Feb 19 12:07:03 machello automount[1678]: using kernel protocol version 4.03
> Feb 19 12:07:03 machello automount[1678]: using timeout 300 seconds; freq 75 secs
> Feb 19 12:07:03 machello automount[1708]: starting automounter version 4.1.0, path = /-, maptype = file, mapname = /etc/auto.direct
> Feb 19 12:07:03 machello autofs: automount startup succeeded
> Feb 19 12:07:03 machello automount[1708]: shut down, path = /-
> 

4.03 is an old version of autofs4. Current is 4.04.
Strange to see it in RHEL. I thought they didn't want to include it.

What is in your auto.direct map?

Ian

Re: direct map shut down?

[Brian Long]

> 4.03 is an old version of autofs4. Current is 4.04.
> Strange to see it in RHEL. I thought they didn't want to include it.

The didn't include it in their stock kernel.  They put all their
"unsupported" stuff into an RPM called kernel-unsupported.  I ripped
autofs4.o out of it and loaded it on my system for testing.  I was
hoping direct maps in your later versions might support the multiple
mounts I need.  I'll look into using the multimount functionality.

Do you have plans to get multiple mounts working with direct maps in the
near future?  Will this involve kernel-module changes or just user-land
tool changes?

Thanks.

/Brian/
-- 
       Brian Long                      |         |           |
       Americas IT Hosting Sys Admin   |       .|||.       .|||.
       Cisco Linux Developer           |   ..:|||||||:...:|||||||:..
       Phone: (919) 392-7363           |   C i s c o   S y s t e m s

Re: direct map shut down?

[Ian Kent]

On Fri, 20 Feb 2004, Brian Long wrote:

> 
> > 4.03 is an old version of autofs4. Current is 4.04.
> > Strange to see it in RHEL. I thought they didn't want to include it.
> 
> The didn't include it in their stock kernel.  They put all their
> "unsupported" stuff into an RPM called kernel-unsupported.  I ripped
> autofs4.o out of it and loaded it on my system for testing.  I was
> hoping direct maps in your later versions might support the multiple
> mounts I need.  I'll look into using the multimount functionality.

Thinking about it, you could use submounts if you are willing to local 
file maps (or you use linux only global maps). This is likely how I'll 
implement it in the daemon (internally that is).

I'll put an example map together and send it of to you when I get a bit of 
time.

> 
> Do you have plans to get multiple mounts working with direct maps in the
> near future?  Will this involve kernel-module changes or just user-land
> tool changes?

I've been aware of this limitation for a long time and have put much 
thought into how I can do it. It's quite hard but I do have an idea of 
how I will do it. But near future is always a big question mark as I work 
on autofs in my spare time.

Ian

newly added heirarchical mount points not found

[Tom Georgoulias]

Hi:

I'd like to know if the heirarchical mount point behavior I've been 
seeing lately with autofs4 is what I should expect.  When I add an 
additional submount point to an existing set of heirarchical mounts, I 
cannot access the file system referenced by the new mount point.

The systems I am seeing this behavior on are Red Hat 8.0 and 7.3 systems 
with the 2.4.20-28.8bigmem and 2.4.20-28.7bigmem kernels (and the 
autofs4 module it contains) and autofs-4.1.0-2.

I have a set of entries in one of my NIS automount maps very similar to 
these:  (names changed to protect the innocent. ;)

in automount map auto.stuff
--
top \
/key2 bender:/vol_A/key2 \
/key3 fry:/vol_B/key3 \
/key4 fry:/vol_B/key4
--
Using "cd /stuff/top/key3" works just fine from both my linux and 
solaris systems.

However, if I add an entry for key9:
--
top \
/key2 bender:/vol_A/key2 \
/key3 fry:/vol_B/key3 \
/key9 mom:/vol_B/key9 \
/key4 fry:/vol_B/key4
--
and push out the updated map, a "cd /stuff/top/key9" only works on 
Solaris.  The linux systems see the new entry via "ypmatch -k top 
auto.stuff", but I get a "No such file or directory" error when I try to 
cd into it.  Today I tried testing this with the 
autofs4-2.4-module-20031201, just to see if it helped, but the problem 
still remains.  According to the README file the new module only 
provides ghosting, but I figured I didn't have a lot to lose by testing 
it anyway.

The only way I've found to safely and reliably can access the new mounts 
is to reboot the system, since restarting the autofs service screws up 
the active mounts on the apps still running and reload only checks the 
auto.master file for updates.

Any suggestions on whether or not this is expected behavior, or if I 
have something set up wrong?

Many thanks,

Tom
-- 
Tom Georgoulias
POPI Classification
[x] General Business Information
[] Motorola Internal Use
[] Motorola Confidential Proprietary

Re: newly added heirarchical mount points not found

[Ian Kent]

On Mon, 23 Feb 2004, Tom Georgoulias wrote:

> Hi:
> 
> I'd like to know if the heirarchical mount point behavior I've been 
> seeing lately with autofs4 is what I should expect.  When I add an 
> additional submount point to an existing set of heirarchical mounts, I 
> cannot access the file system referenced by the new mount point.
> 
> The systems I am seeing this behavior on are Red Hat 8.0 and 7.3 systems 
> with the 2.4.20-28.8bigmem and 2.4.20-28.7bigmem kernels (and the 
> autofs4 module it contains) and autofs-4.1.0-2.
> 
> I have a set of entries in one of my NIS automount maps very similar to 
> these:  (names changed to protect the innocent. ;)
> 
> in automount map auto.stuff
> --
> top \
> /key2 bender:/vol_A/key2 \
> /key3 fry:/vol_B/key3 \
> /key4 fry:/vol_B/key4
> --
> Using "cd /stuff/top/key3" works just fine from both my linux and 
> solaris systems.
> 
> However, if I add an entry for key9:
> --
> top \
> /key2 bender:/vol_A/key2 \
> /key3 fry:/vol_B/key3 \
> /key9 mom:/vol_B/key9 \
> /key4 fry:/vol_B/key4
> --
> and push out the updated map, a "cd /stuff/top/key9" only works on 
> Solaris.  The linux systems see the new entry via "ypmatch -k top 

Strange. I thought you would at least have to run 'automount' to refresh 
the maps on Solaris.

> auto.stuff", but I get a "No such file or directory" error when I try to 
> cd into it.  Today I tried testing this with the 

That's right because, for file, NIS and LDAP maps, the daemon uses a cache 
that is not aware of updates.

In 4.1.0 you can send a HUP signal to the daemon process controling the 
map to ask it to update the map in similar fashion to running automount on 
Solaris.

> autofs4-2.4-module-20031201, just to see if it helped, but the problem 
> still remains.  According to the README file the new module only 
> provides ghosting, but I figured I didn't have a lot to lose by testing 
> it anyway.

Browsable mount points are a must. 

Anyway try the HUP signal.

Ian

Re: newly added heirarchical mount points not found

[Tom Georgoulias]

Thank you for your help on this.

Ian Kent wrote:

> Browsable mount points are a must. 

For this to work?  Or just to get all the benefits of autofs4?

> Anyway try the HUP signal.

I wasn't successful.  On a Red Hat Linux 8.0 system using autofs-4.1.0-2 
and the autofs4-20031201 kernel module:

1. Made a test mount entry and pushed out the change

hatfield3:tomg$ ypmatch -k sync_caches auto.design
sync_caches <snip>
/tomg_test -suid bender:/export/bender/tomg/tmp/tomg_test
<snip>

2. Tried to access it on Linux
hatfield3:tomg$ cd /design/sync_caches/tomg_test
-bash: cd: /design/sync_caches/tomg_test: No such file or directory

3. Tried to access it on Solaris
fry:tomg$ cd /design/sync_caches/tomg_test
fry:tomg_test$

4. Sent HUP signal to automount daemon on Linux
[root@hatfield3 root]# psg design
root      1274     1  0 08:00 ?        00:00:00 /usr/sbin/automount 
/design yp a
[root@hatfield3 root]# kill -1 1274

5. Try again on Linux:
hatfield3:tomg$ cd /design/sync_caches/tomg_test
-bash: cd: /design/sync_caches/tomg_test: No such file or directory

Did I overlook something, or do it incorrectly?
-- 
Tom Georgoulias
POPI Classification
[x] General Business Information
[] Motorola Internal Use
[] Motorola Confidential Proprietary

Re: newly added heirarchical mount points not found

[Ian Kent]

On Wed, 25 Feb 2004, Tom Georgoulias wrote:

> Thank you for your help on this.
> 
> Ian Kent wrote:
> 
> > Browsable mount points are a must. 
> 
> For this to work?  Or just to get all the benefits of autofs4?

Just for your sanity.

> 
> > Anyway try the HUP signal.
> 
> I wasn't successful.  On a Red Hat Linux 8.0 system using autofs-4.1.0-2 
> and the autofs4-20031201 kernel module:
> 
> 1. Made a test mount entry and pushed out the change
> 
> hatfield3:tomg$ ypmatch -k sync_caches auto.design
> sync_caches <snip>
> /tomg_test -suid bender:/export/bender/tomg/tmp/tomg_test
> <snip>

What is that "/" doing here?

I thought an indirect map did not have slashes in the key.


What does the master map say?

Ian

Re: Re: newly added heirarchical mount points not found

[Ian Kent]

On Wed, 25 Feb 2004, Ian Kent wrote:

> On Mon, 23 Feb 2004, Tom Georgoulias wrote:
> 
> > Hi:
> > 
> > I'd like to know if the heirarchical mount point behavior I've been 
> > seeing lately with autofs4 is what I should expect.  When I add an 
> > additional submount point to an existing set of heirarchical mounts, I 
> > cannot access the file system referenced by the new mount point.

Unfortunately it is. After checking the code I see that autofs v4 does 
not look inside the multi-mount map. It just mounts the whole thing and 
umounts it after a timeout (you already know this anyway). Consequently 
changes to the map are not seen until it is umounted and then remounted. 
To change this is quite a bit of work because of the tight coupling 
between the mount lookup and the action of the mount itself in the 
current design.

This design has caused me pain before and I have been planning to rework 
it for ages. I've been trying to complete as many bug fixes and requested 
features (that are fairly straight forward) before starting this as it's 
likely to take quite a while (and will probably be the start of 4.2.x).

So the news is not good I'm afraid. As I said I'll try and implement a 
work around in the 4.1.x release but I can't work out a way to do it yet
without a fair bit of change to the code.

Ian

Re: direct map shut down?

[Ian Kent]

On Thu, 19 Feb 2004, Brian Long wrote:

> /tools nisplus:auto_tools rw,hard,intr,noquota,timeo=15
> /auto /etc/auto.indirect rsize=32768,wsize=32768,tcp
> /users nisplus:auto_home rw,hard,intr,rsize=32768,wsize=32768,tcp
> /- /etc/auto.direct rsize=32768,wsize=32768,tcp

I thought that should be proto=tcp?

> 
> /etc/auto.direct
> /netapp/rtp-filer01a    rtp-filer01a:/vol/vol0

Looks OK?

> 
> Also, is there a version of the kernel module or user utils that would
> support multiple direct mounts under the same mount point?  For example,
> I want to mount rtp-filer01a:/vol/local1 under
> /netapp/rtp-filer01a/vol/local1  :)

Not for direct mount maps.
It should work OK for multi-mount maps. Unfortuneately, there is no lazy 
mounting for them yet.

Ian

Re: direct map shut down?

[mmarion]

On 20 Feb, Ian Kent wrote:

> I thought that should be proto=tcp?

No, it's not required.  It'll support proto=, but tcp is the default.  In the
moutn man page it shows it as a boolean value/argument that can be proceeded
by no, as can udp.

-- 
Mike Marion-Unix SysAdmin/Staff Engineer-http://www.qualcomm.com
"But these are not inherent flaws in the operating system - they don't
happen by accident." - Mike Nash, "Director of Microsoft's Infrastructure
Systems" explaining why NT has so many patches to fix crashes caused by
malicious net users.