Anthony Towns <aj@azure.humbug.org.au> writes: > OTOH, an /etc/share doesn't sound like a bad idea for normal Unix > programs, and seems much easier to run rdist on than selected > entries in /etc. I think the FHS (and thus policy) could reasonably > recommend the use /etc/share/* in this way. Unless there's some > prior art that suggests other locations, I guess.
Well, if you believe in the concept, then /etc/share wouldn't be the right name. "share" in a directory name unfortunately has the meaning "architecture-independent static data" somewhere else: /usr/share and /usr/local/share. Here, you are suggesting that "share" mean "shared among many machines" in the context of the configuration files of /etc. [Ignoring the issue of the name] Because /etc doesn't inherently have a hierarchical structure and *any* file in /etc can be shared (via rdist, NIS, NFS and symbolic links, etc.), I think you're better off trying to simplify site-wide configuration some other way. rdist is a good example. What might make sense is tools to make it easier to "rdist-ify" a set of configuration files in /etc. [Getting off topic] The real problem is the lack of a consistent and hierarchical configuration system in Linux (and other Unix systems). Every configuration file has a completely different format, it is difficult to organize (and then use) institution-wide, campus-wide, building-specific, machine-specific, etc. parts of the system configuration, and distribution of configuration information throughout your site is needlessly difficult. All of this should be easy. - Dan
