-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Moyer wrote: >>==> Regarding Re: automount and nsswitch.conf; Michael Waychison adds: > > [snip] > > >>>>>What I would like to see (and what I have quasi-implemented with some >>>>>kludgey patches) is Linux behavior that matches (or at least is >>>>>capable of matching) the Solaris behavior. This has obvious benefits >>>>>in heterogeneous environments. >>> > raven> This is the patch I have, yes? > > raven> And you would be wanting me to merge it for 4.1.4 or produce a > raven> supported patch for 4.1.3, yes? > > raven> Have you done any additional work on it? > >>>The patch Ian M. came up with hard codes the lookup order to "files >>>nis". I've been trying to do additional work on it, but that requires >>>getting a few things straight in my head, and then writing gobs of code, >>>and then upgrading glibc, etc, etc. >>> >>>I think we can go with what Ian proposed for now, as it definitely >>>solved a problem for him. > > > Michael.Waychison> Ian M. is correct in that nsswitch.conf logic should be > Michael.Waychison> observed when looking up a map. I don't think it's > Michael.Waychison> worth the hassle and kludgyness of trying to bring any > Michael.Waychison> sort of API into glibc. For the majority of Solaris > Michael.Waychison> users, 'files nis' is 'good enough'. This is slowly > Michael.Waychison> changing to 'files ldap', so we do eventually need to > Michael.Waychison> have this be a configurable option for things to work > Michael.Waychison> properly.. > > Ok, my only beef here is that we are not at all honoring the semantics of > nsswitch.conf. I attest that this is a design flaw, but given the Sun > automounter legacy, I see now ay around it. We'll adhere to what is done > by all other automounters, even though it's wrong and poorly documented. > > So, can I make the assumption that Suns's automounter does not then honor > the "reaction on lookup result", ala [NOTFOUND=return]? If so, then our job > is a bit easier, though we are _still_ duplicating a parser, which I > despise. (I'll do it, I just won't like it ;) >
I don't know if Sun's automounter does, I'd have to do a bit of testing, although I don't see why it wouldn't support status -> action predicates. > > >>>>>>As well as the map order there is missing functionality in the >>>>>>current approach in that if a map key appears more than once, say in >>>>>>a global >>>>> >>>>>map > and in a local file map, the two maps are not merged. They >>>>>should be. This > needs to be catered for in handling nsswitch.conf >>>>>map sources and even > multiple entries in the same map (master map >>>>>that is). >>>>> >>>>>This does not match the Solaris behavior (at least, not based on tests >>>>>that I've done on the Solaris infra here). The only circumstance >>>>>where the Solaris automounter will combine maps is if a file map >>>>>contains "+" notation. In this case, it will merge the NIS map into >>>>>the file map. > > > Michael.Waychison> Side note: If the included 'mapname' starts with a '/', > Michael.Waychison> then only local databases in nsswitch.conf should be > Michael.Waychison> checked. If it doesn't, then only remote databases > Michael.Waychison> should be checked. This all happens in the order > Michael.Waychison> specified. > > Michael.Waychison> This differs from lookup of maps in auto.master however. > Michael.Waychison> In the master map, lookup is done (regardless of the > Michael.Waychison> first character) in the order specified by > Michael.Waychison> nsswitch.conf, prepending '/etc/' for 'files' if > Michael.Waychison> required. > > And we don't support the '+' notation, correct? Should we? Since we're in > the code, it may make sense. > Last I looked, '+' was only supported in the master map, handled by a clause in the init script. Ian K? >>>>>If nothing else, it would be nice to have a "SOLARIS_COMPAT" flag that >>>>>switches Linux autofs to the two behaviors described above. >>> > raven> I would rather move autofs toward the Solaris behaviour. > >>>Agreed. If there was a compat flag, it would default to on in my > > Michael.Waychison> packages. > > > Michael.Waychison> I don't know where the Linuxisms came from originally, > Michael.Waychison> but they really do smell of lazyness to not implement > Michael.Waychison> nsswitch.conf logic. All other Unix do the right thing > Michael.Waychison> in a not so incompatible way. > > ziiing! call us lazy, will ya. ;) Nah. I just have a beef against the file: / program: / yp: / ldap: / nisplus: / hesiod: prefixes. They make the map language context dependent. Consider these entries: mikew file:/some/path jeffm -fstype=autofs file:/some/path My homedir would be an nfs mount coming from server 'file', but yours would be an indirect mount defined by the map in flat file /some/path. It just makes writing a *comprehensive* parser more difficult :\. It's also completely incompatible with everything else out there, which is probably what prompted Ian M to write his patch in the first place. > > raven> So, appart from merging your work, and working out a way to cleanly > raven> get the map order, what else do we need to do. > > raven> Can you propose a simple work plan we can focus on. > >>>I exchanged emails with Ulrich Drepper on the feasibility of a >>>getautomountent (or similar) call in libc. He was not at all opposed to >>>the idea. My only concern is that if things work the way Mike W. says > > Michael.Waychison> they > >>>do, then it may not make sense to add such an interface to libc/libnss. >>>I'd have to think on this some more, though, as a standard interface >>>would make things a lot easier for us (and it may be feasible to >>>"stretch" the interface to look the way we want it to). >>> > > > Michael.Waychison> I'm just really against putting this in libc ;). With a > Michael.Waychison> single consumer and no defined interface to 'copy', > Michael.Waychison> what's the point? > > What's the point? The point is to leverage existing code. As it stands, > my feeling on the matter is that an entry should never have been added to > nsswitch.conf. It should have been in an automounter configuration file, > since the semantics are worse than completely different, they're slightly > different! I pondered this over coffee this morning, and thought to myself: "If we added this functionality to nss/, then we'd be abstracting out the nsswitch.conf parser. This is a benefit because we don't have to worry about the status->action semantics and would allow us to change the nsswitch.conf interface" I then took another sip of coffee and realized that switching the switch is a dumb idea ;) - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA8/qfdQs4kOxk3/MRAiOjAKCN3KCousS9RctMhXsGJq4Cxsx5zwCghMxT ClxeViTcbakJZdsA9t4aJN4= =+/XI -----END PGP SIGNATURE----- _______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
