On Wed, 14 Jul 2004, Mike Waychison wrote: > > As per earlier discussions, I've confirmed that Solaris has no public > interface for grabbing map information from name services. Infact, all > logic is done in the application layer. > > > > >>SUMMARY > >> > >>The current Linux automounter does not properly handle nsswitch.conf. It > >>is desirable to leverage the nss library within libc to implement this > >>functionality, though it is infeasible to do so in the near future. Thus, > >>we need to implement our own nsswitch.conf parser within the automount > >>code. I believe future implementations should move toward the libc > >>approach. > > > > > > To early to really discuss whether it would actually be benifical to > > leverage the libc code. Developing with a eye to this end should show us > > what oppertunities or shortcommings exist with this approach. > > > > > >>In either approach, we need to move parsing logic out of the init script. > >>We can do this by making the new parsing code into a sort of library which > >>can be accessed by a helper program that the init script can run. It is > >>insane to try to write this code in two languages, especially when one of > >>them is shell. > > > > > > My thoughts were a seperate module but maybe not a seperate utility. I > > haven't done any experimentation with this specifically yet. > > > > One thing to keep in mind is that we already have a fair bit of useful > > code in the lookup modules to talk to different map sources. Perhaps the > > lookup module interface should be extended to read master maps a well as > > entries. This is consistent with the current design. Comments? > > > > > >>The current parsing of auto.master is flawed, but can be fixed with the > >>approach described in the immediately preceeding paragraph. We definitely > >>do not want to source _all_ potential auto.master maps. > >> > >>[NOTE] Ian Kent has, "making the automounter a threaded app," on his todo > >>list. I believe this is partly motivated by the need to move logic out of > >>the init script and into the c code. Thus, you would start one > automounter > >>process, and it would spawn threads for each mount. As such, the helper > >>program approach may only be an interim solution. > > > > > > If we are writting a parser then to turn it into a "supervisor" thread > may > > not be that difficult. My experiments with future developments move the > > code to this type of module seperation because of the way I think things > > should go. > > > > > >>We need to think about the impact of removing the maptype:mapname grammar > >>from the map file formats, per example provided by Mike W. A phasing out > >>of this seems like a reasonable approach, perhaps starting out with simple > >>warning messages early on and good documentation on how to get the proper > >>semantics with the tools available. Of course, this requires that we > >>implement the nsswitch.conf parsing logic, first. > > > > > > It shouldn't be to hard to support the existing syntax as an override. > > While my goal has been to move autofs toward coexistence within Solaris > > style sites (I haven't been to successful but still want to) I think it > > would be a shame to discard the individuality and character of the > > original autofs, created by Peter Anvin for Linux, not for coexistence in > > Solaris environments. The original autofs had (has) a face of it's own > and > > those creative ideas shouldn't be discarded out of hand. > > > > I agree that supporting the nameservice prefixes as an override is > possible, but don't believe keeping it as a reminder of 'individuality' > has any merit. When nss support comes in, I'd suggest we start > complaining loud and clear in the logs that nameservice prefixes are a) > deprecated, b) is completely incompatible with every other autofs system > out in the wild. > > Prefixes are a hack. Warts like this should only be supported for a > short term. Let's cut our losses and move on.
OK. But it was worth noting the heritage here. > > > > >>Handling of the '+' inclusion directive should also be implemented. > >> > > > > > > Part and parcel of the master map parsing. > And a hack in itself! > This is not master map specific. It applies to all flat files. But you > knew that right ;) > The recursive definition here makes this implementation annoyingly difficult. Ian _______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
