>>>>> "mef" == Mary Ellen Fitzpatrick <mfitz...@bu.edu> writes:
mef> Is there a way to set permissions so that the /etc/auto.home mef> file on the clients does not list every exported dir/mount mef> point? If I understand the question right, then, no. These maps are very traditional from the earliest days of NIS and need to be managed centrally, and they should match the structure of filesystems exported from servers exactly. The new scheme of ``mirror mounts'' and ``referrals'' which does away with the global automount map and sprinkles bits of the map onto individual servers, is oft-discussed but seldom implemented, and it's not at all traditional so it's unclear to me that it's ever going to become The Way even though everyone talks about it like it's _fait accompli_. I only mention it to poison the well: if someone tries to discuss this with you, you should immediately close your ears because they are only dreaming for now, and none of it works yet. Unfortunately, autofs implementations' quality varies widely. I think Linux is on their...fourth? rewrite of the whole automount framework, and Mac OS X on at least their second if not third. I found Mac OS X's one is poor at handling nested mounts like what you're doing compared to the solaris one. The apple people sneakily altered the automounter documentation to remove all examples showing nested mounts, without actually documenting frankly the limitation which surely prompted them to alter the examples. slimey fucks. You can work around their fail using the 'net' option but this prevents assembling subtrees from several different servers. Each of your nested subtrees must be from the same server when using the 'net' option workaround because you lose the right to choose where they're mounted: http://web.ivy.net/~carton/rant/macos-automounter.html#9050149 The linux one will do nested subtrees, but I think you need to express the entire subtree as a single automount record, with a single trigger. This is different from Mac OS X with-workaround which will (provided you use 'net') miraculously assemble a view of the entire subtree from several dscl records which in theory could even be on LDAP. so, Linux will automount and unmount everything together, while Mac OS X will not. You might reasonably wish to have the mountpoints within the automounted filesystem turn into triggers themselves so that parts of the subtree are only mounted just as deeply as and only along the branch needed to satisfy the trigger---that way a subtree could be assembled from many servers, and if the map for a deep corner of the subtree were changed and pushed, clients could start obeying the changes sooner. but I think on Linux this won't work. not sure it works anywhere though. I guess it sort of works on Mac OS X with heavy caveat, but not sure about Solaris. carton -hard,intr,noacl / cash:/export/home/& \ /VDI cash:/export/home/&/VDI but although Linux beats the Mac here, the linux one is shit at handling direct mounts: if you give it a subdirectory in which it owns all of the fake files, like /home, it works ok. but if you want it to for example automount /arrchive (just the one filesystem onto /arrchive from one share on one server) I found it hardly works at all. so I have /arrchive automounted on my Solaris boxes, and /remedial-automount/arrchive with symlink /archive -> remedial-automount/arrchive on Linux boxes. so much for one traditional centrally-managed map.
pgppJ7OZtGw8p.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
