On Mon, 2008-06-23 at 09:06 +0100, Anton Altaparmakov wrote:
> Hi,
>
> On 23 Jun 2008, at 02:08, H. Peter Anvin wrote:
> > J.P. King wrote:
> >> As I said previously, because this is quite hard. The maps need to
> >> be changed by the login process. We currently do this in the PAM
> >> configuration. Given that we can have multiple log in at the same
> >> time this means we need to do a lot of careful locking.
> >> Ideally we would do something like include all the files from a
> >> configuration directory and have a HUP get it to re-read all these
> >> configuration snippets. This would be a relatively involved change
> >> however.
> >
> > This sounds like a perfect use of an executable map to me.
>
> Sounds like something that is certainly worth investigating.
I suspect that you'll find that some existing bugs will prevent you from
moving to a single master map with 5.0.2 (and 5.0.3 as I'm currently
working on problems submount handling). I also think there is more than
one way to do this as well but there is no way to do a forced expire on
a specific mount point at the moment.
I'll just walk through the email and try to describe an alternate
approach in spite of the caveats above. I'm not sure that my suggestions
will be quite what you need, specifically wrt. the need for a forced
expire on a specific automount.
>
> > I don't know exactly what your maps look like, but it seems to me
> > that since you have an unusual local requirement it would make sense
> > to deal with it in a manner external to autofs itself.
>
>
> This is what ours look like at present. When a user logs in we
> generate two files (below $user is the user name of the user logging
> in):
>
> /var/run/pwfautomount/master.$user
> /var/run/pwfautomount/auto.$user
>
> I.e. for me with user name aia21 the files are:
>
> /var/run/pwfautomount/master.aia21
> /var/run/pwfautomount/auto.aia21
>
> Where the first file is the master map for that user and it contains a
> single line like this (in this example the user logging in is me, i.e.
> aia21, hence the two "aia21" strings, those would be set to the
> currently logging in user):
>
> /servers/aia21 file:/var/run/pwfautomount/auto.aia21
Here we might use:
/servers file:/<any dir you want>/auto.user
For the map entries below this might be something like:
* -fstype=autofs file:/var/run/pwfautomount/auto.&
The point of using a submount is that autofs will mount /servers/<user>
(for issuing control commands) and get it's map entries from the
map /var/run/pwfautomount/auto.<user> and when it expires away the mount
itself will also go away. Quite similar to what you have now and should
actually work with both v4 and v5 (or would if I didn't have bugs with
submounts in v5 at the moment and if v4 had a forced expire).
The problem for your setup is be not being able to send a forced expire
(USR2) to a specific mount which will of course cause mounts you don't
want umounted to be umounted. This is an example of the type of control
function we want to provide either by using the daemon or another
control program. The way this would work is similar to the way in which
we dynamically change the log level now (sorry, added in 5.0.3),
optionally specifying an autofs mount point.
But, yes, it ain't there now.
>
> And the second file contains at present for my user "aia21":
>
> PWF-HOME1 -
> fstype
> =
> ncp
> ,ipserver
> =
> 172.16.3.42
> ,owner
> =
> aia21
> ,uid
> =
> aia21
> ,gid
> =
> aia21
> ,hard
> ,nodev
> ,nosuid
> ,nfsextras
> ,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
> authcon/aia21 :PWF-HOME1/aia21.Aliases
> PWF-HOME2 -
> fstype
> =
> ncp
> ,ipserver
> =
> 172.16.3.43
> ,owner
> =
> aia21
> ,uid
> =
> aia21
> ,gid
> =
> aia21
> ,hard
> ,nodev
> ,nosuid
> ,nfsextras
> ,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
> authcon/aia21 :PWF-HOME2/aia21.Aliases
> PWF-HOME3 -
> fstype
> =
> ncp
> ,ipserver
> =
> 172.16.3.44
> ,owner
> =
> aia21
> ,uid
> =
> aia21
> ,gid
> =
> aia21
> ,hard
> ,nodev
> ,nosuid
> ,nfsextras
> ,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
> authcon/aia21 :PWF-HOME3/aia21.Aliases
> PWF-HOME4 -
> fstype
> =
> ncp
> ,ipserver
> =
> 172.16.3.45
> ,owner
> =
> aia21
> ,uid
> =
> aia21
> ,gid
> =
> aia21
> ,hard
> ,nodev
> ,nosuid
> ,nfsextras
> ,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
> authcon/aia21 :PWF-HOME4/aia21.Aliases
> PWF-SHARED -
> fstype
> =
> ncp
> ,ipserver
> =
> 172.16.3.8
> ,owner
> =
> aia21
> ,uid
> =
> aia21
> ,gid
> =
> aia21
> ,hard
> ,nodev
> ,nosuid
> ,nfsextras
> ,strong,codepage=cp850,iocharset=utf8,filemode=640,dirmode=750,a=/
> authcon/aia21 :PWF-SHARED/aia21.Aliases
>
> Note that these lines are generated by querying the Netware e-
> Directory and have to be regenerated each time a user logs in as the
> list can have changed between logins and in particular the list can be
> different between different people logging in.
>
> We then launch the automount process like so:
>
> perl -e 'exec {"automount"} @ARGV' pwf-amnt \
> -p "/var/run/pwfautomount/pid.$user" "/var/run/pwfautomount/
> master.$user"
>
> Note the perl exec magic is only needed with the new automount from
> autofs 5. With autofs 4 we simply ran automount with appropriate
> options...
>
>
> Further, when a user logs out, we ask the automount process for that
> user to shut down, thus causing all those mounts to disappear like so:
>
> # Tidy up the user's automounter(s)
> ampid=$(cat "/var/run/pwfautomount/pid.$user")
>
> # Kill user's processes politely at first, then less so.
> su -c "kill -TERM -1" $user
> sleep 1
> su -c "kill -KILL -1" $user
> sleep 1
>
> rm -f /var/run/pwfautomount/auto.$user /var/run/pwfautomount/pw.$user \
> /var/run/pwfautomount/master.$user
>
> # Repeatedly ask the automounter to shut down until it succeeds (and
> hence the
> # "kill" fails).
> (
> while kill -USR2 $ampid 2>/dev/null; do
> sleep 1
> done
> ) >/dev/null 2>&1
We would probably take this logic into the forced-expire control
function, but for the general case, where forced umounting might not be
enabled, there's also the question of how long we try to get rid of the
mounts and the form of the communication of the result to the requester
(possibly a numeric return code?).
>
> So we have a direct benefit of having multiple automount instances
> because it makes it very easy to cause all the user's automounts to be
> unmounted on logout.
And probably will need continue this way for a while yet I think due to
the USR2 issue.
>
> We do not want them to remain as the number of connections to the
> Novell e-Directory is limited per user thus if the automount mounts
> were to remain for some reason each of them would count as a
> "connection" and a user could easily get into a situation where they
> can't log in at all any more because of old automount mounts sitting
> around on various other servers/workstations.
>
> How would we be able to perform such cleanup if using one automount
> instance with an executable map?
Perhaps someone else could post an approach using an executable map but
I'm not sure we can get around the forced-expire difficulty though.
Ian
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
