dme@doc.ic.ac.uk (Dave Edmondson) (05/25/90)
In article <21542@boulder.Colorado.EDU> grunwald@foobar.colorado.edu (Dirk Grunwald) writes:
grunwald> The original problem was that I'd like to mimic Sun
grunwald> automount, i.e. be
grunwald> able to automount things into an existing directory (like /) and not
grunwald> have existing files be hidden.
this is correct.
grunwald> The suggestions I've gotten were to use an /amd mount point and
grunwald> symlinks. E.g.
grunwald> /eclipse/staff -> /amd/eclipse/staff
grunwald> now, looking in /eclipse/staff will cause /amd/eclipse/staff to be
grunwald> mounted. and everything is hunky.
this could be implemented using:
amd /eclipse amd.eclipse
with amd.eclipse::
staff type=nfs;rhost=eclipse;rfs=/eclipse/staff
if /eclipse/staff is a partition on eclipse. if /eclipse is the
partition on eclipse and staff is a subdir then::
staff type=nfs;rhost=eclipse;rfs=/eclipse;sublink=staff
In either case you would get what you want without the extra symlink
(imho its a bit cleaner as well).
grunwald> Likewise, I can do:
grunwald> /soma -> /amd/soma
this is different, and i don't think that it can currently be done.
how would you feel about doing something like:
amd /soma amd.soma
and the map saying::
/ opts=rw,nosuid,grpid;type=nfs;rhost=soma;rfs=/soma
? this would mean that the map would (could ?) only have one entry,
the `direct' mount. maybe then it could be extended to allow:
amd /soma opts=rw,nosuid,grpid;type=nfs;rhost=soma;rfs=/soma
and then the list of automout points would _need_ to be specified in a
file (see the bit about am.master below) or it would quickly get out
of hand. maybe the / could be a dot (.).
grunwald> and ``have something automounted'' at the root partition. This solves
grunwald> the problem, and I think this is how you have to do it with Sun
grunwald> 'automount' as well.
after all, it really isn't anything to do with the automounter - you
just mounted something here, and it happened to be a program. it
_will_ block out anything previously there.
grunwald> It should be pointed out in the amd manual that you can specify more
grunwald> than one map & mount point -- it wasn't terribly clear. Actually, it
grunwald> would be nice to have all that information in a single configuration
grunwald> file.
i'll get it added to the manual. as for storing all of the info in
one file, there was originally some code to read am.master (which is
used by the sun automount program), which specified a list of mount
points and maps, but this got removed (i forget why). if you have an
am.master lying around that specifies what you need, then you can do:
amd `ypcat -k am.master`
and get the same effect.
there is (in the works) a configuration file compiler that would
remove all of this boring work, but it is not yet fit for release.
dave.
--
Dave Edmondson
Department of Computing, Imperial College, 180 Queen's Gate, London SW7 1BZ UK
phone: 071-589-5111 x5085 fax: 071-581-8024
dme@doc.ic.ac.uk, ..!ukc!icdoc!dme, dme@athena.mit.eduandrew@dgbt.uucp (Andrew Patrick DGBT/DBR) (05/29/90)
In article <21492@boulder.Colorado.EDU> grunwald@foobar.colorado.edu writes: > >I'm hoping that someone else has used the AMD automount deamon; I've >been using it under Ultrix/RISC using the program mount type. > >Our local file system hierarchy is very host-specific. I.e. people use >/eclipse/users, /piper/users, etc etc for user directories rather than >mapping everything to /home/<user>. ... How about doing something like: amd /am amd.everyone and then create symbolic links in / to the correct area in /am e.g., ln -s /am/eclipse eclipse -- Andrew Patrick, Ph.D. | Old Address: andrew@dgbt.crc.dnd.CA andrew@dgbt.doc.CA | Alternate Address: andrew@doccrc.BITNET Department of Communications | Slow Address: andrew@dgbt.UUCP Ottawa, CANADA |