subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Subversion Wiki] Trivial Update of "ServerDictatedConfiguration" by CMichaelPilato
Date Tue, 06 Dec 2011 15:18:23 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "ServerDictatedConfiguration" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/ServerDictatedConfiguration?action=diff&rev1=11&rev2=12

Comment:
Switch to a real wiki admonition.

  == Design: Server-Dictated Configuration ==
- 
  Many software development shops of non-trivial size desire to have an enforce a uniform
configuration environment among the various clients which commit to their repositories.  Although
these shops may have the ability to control the environment on the client machines (dictating
software versions, etc), relying upon the client for setting various configuration parameters
can be time-consuming and problematic.
  
  Subversion already provides the means of enforcing much (but not all) of this configuration
through the hook script mechanism.  What our users desire is some way of having the server
dictate a default or recommended configuration to clients.  The parameters of interest typically
come from the standard client-side config: things like global-excludes or auto-props.  Allowing
the administrator to store a default config on the server, which then gets pushed to the clients,
would save both time and frustration.
  
  === Behavioral specification ===
- 
  The high-level behavior for repository-dictated configuration is relatively simple: the
repository maintains a list of configuration parameters and values, and upon request, provides
these to the client who then applies them appropriately.
  
  There are a number of specific bits of configuration that existing Subversion users and
administrators wish to have propagated from the server to the client.  There are also different
scopes at which administrators might reasonably wish to apply differing defaults for these
things:  server-wide, repository-wide, or local to a particular directory hierarchy within
a specific repository.  The following is a listing of those that we know about, with some
notes about scope and desired degrees of control:
+ ||'''Configuration''' ||'''Scope''' ||'''Enforceability''' ||'''Notes''' ||
+ ||auto-props ||per-directory ||Enforceable via hook scripts ||Clients should be allowed
to override this ||
+ ||log message templates ||per-directory ||Enforceable via hook scripts ||Doesn't fit the
name=value configuration motif quite as readily as some of the others.  Would a client need
to override this? ||
+ ||myriad authn-related stuff ||per-server, per-repos ||Un-enforceable ||Lack of enforceability
plus relationship to security means that admins do not want the client to be able to trivially
override this setting.  Precise requirements TBD (is this a boolean "allow/disallow plaintext
password caching", or "require X, Y or Z encrypted password stores", or ...? ||
  
+ {{{#!wiki warning
+ The configuration the server dictates can at best be only a suggestion to the client, with
well-behaving clients honoring that suggestion.  As free software, though, most such clients
could be modified by a malicious user to ignore server-side suggestions.  Server-side enforcement
of desired behaviors (where possible, and often via hook scripts) is still recommended.
+ }}}
- || '''Configuration''' || '''Scope''' || '''Enforceability''' || '''Notes''' ||
- || auto-props || per-directory || Enforceable via hook scripts || Clients should be allowed
to override this ||
- || log message templates || per-directory || Enforceable via hook scripts ||  Doesn't fit
the name=value configuration motif quite as readily as some of the others.  Would a client
need to override this? ||
- || myriad authn-related stuff || per-server, per-repos || Un-enforceable || Lack of enforceability
plus relationship to security means that admins do not want the client to be able to trivially
override this setting.  Precise requirements TBD (is this a boolean "allow/disallow plaintext
password caching", or "require X, Y or Z encrypted password stores", or ...?  ||
  
- NOTE: The configuration the server dictates can at best be only a suggestion to the client,
with well-behaving clients honoring that suggestion.  As free software, though, most such
clients could be modified by a malicious user to ignore server-side suggestions.  Server-side
enforcement of desired behaviors (where possible, and often via hook scripts) is still recommended.
- 
- ANOTHER NOTE:  At least one user specifically called out the need for the server to enforce
adherence to the configured behaviors ''without'' requiring hook scripts to do so.  For example,
if the repository has a configured auto-props list, the Subversion C code is perfectly capable
of validating that incoming committed items obey those settings, failing the commit otherwise.
 This seems like a reasonable request so long as we permit admins to specify which of their
configuration settings are "suggested" versus "required" (again, taking into account that
anything unenforceable can't truly be "required").
+ At least one user specifically called out the need for the server to enforce adherence to
the configured behaviors ''without'' requiring hook scripts to do so.  For example, if the
repository has a configured auto-props list, the Subversion C code is perfectly capable of
validating that incoming committed items obey those settings, failing the commit otherwise.
 This seems like a reasonable request so long as we permit admins to specify which of their
configuration settings are "suggested" versus "required" (again, taking into account that
anything unenforceable can't truly be "required").
  
  === Server-client transmission mechanism ===
- 
  Over ra-neon/ra-serf, the client will send to the server the sha1 hash of the server-dictated
config that it current has cached as part of the OPTIONS request.  If the server has a different
version, it will send that to the client in the OPTIONS response.  For ra-svn, a similar thing
happens as part of the initial connection handshake/feature exchange.  This is an opportunistic
caching approach, keeping the client in sync with the repository configuration any time the
client contacts the repository.  This mechanism requires that there exist a predictable and
consistent manner in which to calculate the checksum of the configuration.
  
  === Server-side storage ===
- 
  ''[TODO]''
  
  === Client-side storage ===
- 
  The client current maintains a global configuration file in ~/.subversion/config  This feature
will introduce the ~/.subversion/repos/ directory, which will hold additional subdirectories
keyed on the UUID of the repository.  It is in this subdirectory that the cached version of
the repository configuration will be stored.
  
  === Configuration Hierarchy ===
- 
  ''[TODO]''
  
  === Related Issues ===
- 
   * http://subversion.tigris.org/issues/show_bug.cgi?id=1974
   * http://subversion.tigris.org/issues/show_bug.cgi?id=1002
   * http://subversion.tigris.org/issues/show_bug.cgi?id=1054
@@ -47, +41 @@

   * http://subversion.tigris.org/issues/show_bug.cgi?id=1813 (sorta)
  
  === Other Related Resources ===
- 
   * [[http://svn.haxx.se/dev/archive-2010-08/0166.shtml|"Bikeshed: configuration override
order"]] list discussion
   * [[http://svn.haxx.se/dev/archive-2005-05/1291.shtml|"Repository-defined autoprops"]]
list discussion
   * [[http://svn.haxx.se/dev/archive-2005-05/0889.shtml|"Inherited properties document]]
list discussion

Mime
View raw message