Xref: utzoo comp.unix.ultrix:3603 alt.sys.sun:890 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!strath-cs!cs.glasgow.ac.uk!icdoc!gould!dme From: dme@doc.ic.ac.uk (Dave Edmondson) Newsgroups: comp.unix.ultrix,alt.sys.sun Subject: Re: Amd & Ultrix Message-ID: Date: 25 May 90 12:42:40 GMT References: <21492@boulder.Colorado.EDU> <21542@boulder.Colorado.EDU> Sender: dme@doc.ic.ac.uk Distribution: comp Organization: Systems Support, Department of Computing, Imperial College Lines: 66 In-reply-to: grunwald@foobar.colorado.edu's message of 25 May 90 00:05:19 GMT 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.edu