(note: I've segmented the mail to make it more readable, since I'm jumping between many ideas... sorry, I'm messy) > De: Jon Connell [mailto:[EMAIL PROTECTED]] > Rainer Clasen's patch for mount_autofs.c didn't get me any > mileage on my autofs (3.1.3). The mapfiles: > /etc/auto.master: > /nfs --timeout 60 > /etc/autofs/nfs : > * -fstype=autofs,-Dhost=&,-Dprefix=/& file:/etc/autofs/nfs.sub > /etc/autofs/nfs.sub > * ${host}:${prefix}/& this solution, as far as I've undestood, only support 2 level NFS automounting (or 1 or 3 or 4, but a fixed depth) ... ** making -Dvar=val works ? trying to implement /net like you do, I've been unable to use the -D option with autofs-3.1.3-54, neither with files nor with program maps ... in fact the automount processes were hanging while forking... are there some "secrets", hints ... to use the -D variables ? the only solution I've found is to use the current working directory and the key name as the context. how are those wariables passed to program maps (environment?). if not already done a good idea would be to export such variables to program maps, as environnement variable. ** /net implemented with program map anyway I've a working solution to support arbitrary NFS mount like /net -hosts : I use a program map, that call showmount -e and allow arbitrary depth, eventually creating autofs submounts... this is a quick "/bin/sh" program map, that would need much reengineering to be bullet-proof, but at least it works on my beowulf. if you're interested, paralline.net kindly host my (embryonic) package at: http://www.paralline.net/projets/autofs_slashnet/index.en.html (it also support samba automount like /net does on NFS, and I'm working on a samba with username automount ...) ** integrating /net in standard release anyway, it may be a good place to say that full solaris-like /net -hosts implementation is really a must... I've also read here about a patch that allow variable depth key lookup so that it should be much easier to program a NFS program map using showmount. offering this patch, with a /net program map as a standard functionality may be a good idea. at least offering a solid /net program map (like mine, but bullet-proof, maybe programmed in perl or C/C++) ** samba automount it is also true for Samba automount, but I think that it is much more easy (fixed depth), and concerns mainly samba team (mount.smb and options support). **Autofs Keys Listing another deep design change, that may already have been discussed here (and probably refused 8( ) would be to support a variant of autofs directory listing that shows potential keys when an enumeration is possible. I agree that generaly enumeration is not always possible, but sometime it is meaningful. for example when listing an automount directory, one should get: - the list of non wildcarded keys from "file:" maps - the list of keys from "yp:" maps - the answer of the "program:" map with a magic parameter (why not no key parameter !) for program: maps... otherwise call another script (eg: program_map_name.ls )it it exists, or create a new program-with-ls: map type... I suppose that this is much more difficult that it looks there, since autofs may have to create INODES for such potential mounts, list them, and then mount other wolumes on them... and this may be difficult or impossible... caching and performance of the listing ay be also an issue... should the listring scripts be called everytime, or should there be an "expiry time" configured in autofs, to avoid performance problems, or both cached and direct listing modes depending on configuration flags.... -- Alain Coetmeur, Informatique-CDC DTA mailto:[EMAIL PROTECTED]
