On Tue, Jan 3, 2012 at 6:33 PM, Stefan Sperling <s...@elego.de> wrote:
> On Tue, Jan 03, 2012 at 05:58:16PM -0500, Paul Burba wrote:
>> Mike Pilato and I have been kicking around some ideas on server
>> dictated configuration recently and have put our thoughts into a wiki
>> (full disclosure: this wiki was initially based on Hyrum's thoughts on
>> the subject in
>> https://svn.apache.org/repos/asf/subversion/trunk/notes/repos-dictated-config)
>> :
>>
>> http://wiki.apache.org/subversion/ServerDictatedConfiguration
>>
>> We're at a point where it's time to solicit some wider feedback, so
>> please have a look at the wiki and follow-up here with any concerns,
>> thoughts, suggestions, etc..
>>
>> Paul
>
> I did read it today and I like it.
>
> One open question for me was how do we treat invalid configuration
> options in the server-side configuration file?
> This is one of the possible failure modes the design should address.
I see several options here:
1) The simple option: Allow admins to write a syntactically invalid
config on the server. If they neglect to test it, then the invalid
config gets sent to the client. Of course the client can't parse it,
but all that happens is that the client issues a warning and then
allows the operation to succeed. Why? I fall back on the same logic
I used in response to Daniel's question about what to do if we can't
create a config cache in the first place: "...we already accept that
fact that a malicious user can hack up a custom client to ignore the
server dictated config. We still expect the repository administrator
to enforce (where possible) their desired configuration via hook
scripts. All we are trying to do here is make it possible for
well-behaved clients to *easily* do the right thing." This isn't very
different from an repository admin creating a "bad" authz that grants
unintended access.
2) As per #1 but we also add a new svnadmin subcommand ('confcheck'?)
that parses the server side config and checks that only valid
server-side config options are set. This is simple and but can
obviously be skipped (then we fall back to #1?). Maybe we want to
make this test everything in ${REPOS_PATH}/conf/*.* by default when
given a repository path and text a particular ini file if given a file
path (which would be a nice-to-have for Apache authz files which don't
live in the repository tree.
3) A new svnadmin subcommand ('confset'?) that installs a
configuration file, parsing and testing it, and if everything is ok,
moving it into ${REPOS_PATH}/conf/repos.conf. This would ensure that
any changes to the server-side config are well-formed. But it is
ugly, because it breaks with our tradition of simply being to
hand-edit authz and config files in-place. Also I'm obviously doing a
lot of hand-waving regarding how we prevent/detect/recover from such
hand-edits!
4) Anytime a client requests a copy of the configuration from the
server, the server parses and tests the latest configuration. If any
errors are found then the server returns and error describing the
problem. This is harsh, in that it makes the repository essentially
unusable, but an admin who goes through the trouble of writing a
server dictated config probably wants to know the config is bogus and
doesn't mind(?) locking the repos until such time as it is fixed.
#2 and #4 can obviously coexist
> Say there is a syntax error in the configuration file which prevents
> us from parsing it. Do we alert the administrator? If so, how? Or will
> it fail silently?
I hadn't considered direct notification of the repos admin by the
client. Only #3 immediately confronts the repository admin with the
fact they have a bogus config. The other options require a purposeful
step on the part of the admin or for a user to complain (and in the
case of #1 this might not happen since the user can still do what they
want).
> If the option name is valid but the option value is not, will the server
> still send the configuration option to the client? Will it send some default
> value instead of the invalid value? Or will it omit the option from the list
> of configuration options sent to the client?
I'll defer on this until we come to some consensus on the above (but
with options #1 and #2 this is certainly an open question).
Paul
