[OpenAFS] Re: Thinking about a different way to distribute configuration.
Christopher D. Clausen
Sun, 17 May 2009 17:42:14 -0500
Russ Allbery <firstname.lastname@example.org> wrote:
> David Boyes <email@example.com> writes:
>> Why? If the data it serves is on a SAN or otherwise connectable
>> storage, why should the physical server handling the information be
>> somehow special if it gets the same address and configuration
> I want to use my configuration management system to do
> configuration management, not my distributed file system. If you
> want to do large-scale seamless configuration management, use Puppet,
> don't invent a half-assed version of Puppet and embed it in AFS.
*YOUR* configuration management system is Puppet. Great! Some of us
use other products, like say Windows Group Policy.
The OpenAFS for Windows client already does support registry settings
for nearly everything and I would like to eventually use OpenAFS servers
on Windows and as such I think that somehow supporting the Windows
registry should be a key feature of OpenAFS servers on Windows. This
allows for easy configuration using Group Policy. This same level of
control is simply not available when using a config file of any kind.
I realize few if any people are running servers on Windows today, but
please keep Windows in mind when developing a config file format. Using
a config file is NOT the usual Windows way to manage a service and in
the few instances where config files exist, there is usually some other
process that edits them such that the user nevers touches them directly.
>> Which IMHO would argue that there needs to be exactly ONE command
>> line argument -- the location of the config file.
> No. This is exactly the behavior that constantly annoys me with
> Kerberos where many things have to go into krb5.conf and you have to
> duplicate krb5.conf and set an environment variable to get different
> behavior. It's understandable for Kerberos where the configuration is
> for an underlying library and there's no clear way to tie into the
> command line, but that loss of convenience in AFS where we can easily
> do better would be a disservice to our users.
This problem already exists with CellServDB files on Windows (and of
course the same Krberos config file problems that you mention.) How do
I push a change to a specific cell's servers? Oh thats right, I have to
modify or replace the existing file, which is a terrible process and can
end badly. This would be much easier to deal with if this file format
was instead represented within the registry where atomic changes can be
made on a per-value basis and do not require replacing an entire file.
You could argue that simply having a way to include other config files
within a file (include=/path/to/file) would solve a lot of this and I
concur with that, although I suspect most people would hate to now
manage a CellServDB directory instead of a single file. (But it would
allow for a greater level of flexibility for those who wished to use
Here's an example (I realize that the CellServDB file was not the target
for this discussion, just using it as an example) that may not be easy
to represent in some of the simpler file formats. Consider the case of
linked cells within CellServDB. I do not think anyone has linked cells
in the public CellServDB file currently. Could these be represented in
all file formats suggested?