On Tue, 2008-06-24 at 08:27 +0100, Anton Altaparmakov wrote: > Hi, > > On 24 Jun 2008, at 02:08, Jim Carter wrote: > > On Mon, 23 Jun 2008, Anton Altaparmakov wrote: > >> On 23 Jun 2008, at 02:08, H. Peter Anvin wrote: > >>> This sounds like a perfect use of an executable map to me. > >> > >> Sounds like something that is certainly worth investigating. > >> ...... > >> 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): > > > > This problem is interesting: how would you do this while using the > > multi-thread capability of autofs version 5? Here's how far I got. > > First, > > we're not going to mount anything at login time; we're going to > > mount the > > homedir the first time it's referenced, which on my system would be > > slightly before logging in is finished (to check the ssh key in the > > homedir). > > Note this is not possible for us. You cannot use SSH-keys when the > home directory is on a Netware server because you need the user's > password to be able to mount the home directory, there is no way to > perform the mount before asking the user for their password. Once the > user is logged in, as long as they maintain that session open, they > can then use SSH key based authentication when logging in to the same > PWF Linux server as their home directory is already mounted so their > SSH keys are accessible before their subsequent logins. This is one > of the "features" our users complain about the most... > > > Similarly, we're going to rely on automount's normal expiration > > behavior to get rid of mounts after logout. > > > > /etc/auto.master would say: > > /server /etc/auto.per-user > > > > /etc/auto.per-user says: > > * -fstype=autofs,-DNCP_USER=& program:/etc/auto.userdirs > > (this is bogus, see below) > > > > /etc/auto.userdirs is executable and goes something like this: (I > > modified > > it so it reports something that can be mounted on my system, and it > > actually happens.) > > > > #!/bin/sh > > # $1 is the map key, i.e. on access to /server/$user/$share, $1 > > would be > > # $share. Translate the key into the server's IP address. Likely > > this > > # is waaaaay different on an authentic Novell network. > > ip=`dig +short +search $1 A` > > > > # Emit the map row (leaving off the key). Bogus \'s supplied for > > # readability. > > echo -fstype=ncp,ipserver=$ip,owner=$NCP_USER,uid=$NCP_USER,gid= > > $NCP_USER,\ > > hard,nodev,nosuid,nfsextras,strong,codepage=cp850,iocharset=utf8,\ > > filemode=640,dirmode=750,a=/authcon/$NCP_USER :$1/$NCP_USER.Aliases > > > > Now, what's the right way to get the NCP user available to the program > > map? In a file map -DNCP_USER (as shown, with the hyphen) will > > propagate > > this variable into the map rows, so the whole thing could have been > > handled in a file map... except for the IP address in the mount > > options. > > If ipserver could possibly be a FQDN rather than a numeric IP > > address, I > > would be very, very tempted to create a massive DNS map that has "A" > > records for PWF-HOME$N.$user.ncp-xlate.cam.ac.uk (to give an example > > domain > > structure). This would be updated, perhaps by dynamic DNS updates, > > whenever a user's server assignment changed. > > > > Returning to the question that most interests me, in the submount I > > tried > > these variants: > > > > * -fstype=autofs,-DNCP_USER=& program:/etc/auto.userdirs > > (NCP_USER was not defined as an environment variable; neither was > > USER) > > * -fstype=autofs program:/etc/auto.userdirs & > > (The extra arg to the program map was ignored with no error > > message) > > > > What do people think would be the best way to get the containing map > > key > > into the program map? Not the key to be translated by the map (in our > > case PWF-HOME1 etc.), but the key that caused the submount to be > > created, > > or any of the other environment variables of the submount, such as > > $USER, > > which is probably what you really want to use here. > > I would have expected the -DNCP_USER= to be created as an environment > variable for the program map to find or alternatively to be given on > the program map command line. Given a choice the environment variable > option would be much nicer and easier to use.
Setting them in the environment is the sensible and easiest thing for me to do. But setting the macros that are in the lookup table at the time of the mount it isn't done at the moment. I think we had a request for this some time ago and I made a patch for testing but didn't get any feedback so I let it slip. > > > Warning: before deploying a submount-based scheme in production, > > watch for > > a resolution of the internal locking (mutex) issue that's so > > bedeviling me. > > Could you elaborate on this? What issue are you seeing? Thanks a lot > in advance! Jim sees autofs hang. There is synchronization problem between submounts that are shutting down at the same time a mount request comes in. Of course we only see it on busy systems. Ian _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
