Christopher D. Clausen wrote: > 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 never touches them directly.
I actually hope that no one is running on OpenAFS Server on Windows
today. There really is no testing done with them and they should not
be trusted.
>>> 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 Kerberos 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 it.)
The big problem that I have with the CellServDB file is that there is
really a need to have more than one of them:
1. the public CellServDB that is refreshed by updates from
GrandCentral.org (perhaps via an OpenAFS update)
2. the local CellServDB that supplements and perhaps overrides
the data provided in the public CellServDB
Assuming that the CellServDB data could be stored entirely within
the registry given that AFS is deployed on heterogeneous systems we
still require a configuration format that can be used to not only
on non-Windows systems but to distribute the data so that Windows
administrators such as yourself could import them into the registry.
One of the nice features of the Kerberos profile library is that
it is designed to support exactly this kind of multi-file overlaying.
On Windows, it would also be possible to augment the CellServDB file
with the contents from the registry.
> 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?
Whatever the file format it would be possible to represent linked cells.
The question simply becomes "how easy is it for a human to understand
the data representation?"
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
