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] Update of "ServerDictatedConfiguration" by CMichaelPilato
Date Wed, 14 Dec 2011 20:03:56 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=16&rev2=17

Comment:
Try to morph this plan per my conversation with pburba earlier.

  === Behavioral specification ===
  The high-level behavior for server-dictated configuration is relatively simple:  the repository
maintains a list of configuration parameters and values which, as necessary, the server provides
to the client.  The client, then, behaves in accordance with the server-dictated configuration.
  
- 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:
+ 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, 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 ||
+ ||auto-props ||per-directory ||Enforceable via hook scripts || ||
- ||ignores ||per-directory ||Enforceable via hook scripts ||Client should be allowed to override
this ||
+ ||ignores ||per-directory ||Enforceable via hook scripts || ||
- ||use-commit-times ||per-directory ||Unenforceable ||Client should be allowed to override
this ||
+ ||use-commit-times ||per-directory ||Unenforceable || ||
  ||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 ||Unenforceable ||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 ...?) ||
+ ||store-plaintext-passwords ||per-server ||Unenforceable ||Should it be possible to override
this without hacking the client? ||
  
  
  
@@ -22, +22 @@

  {{{#!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.
  }}}
- 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").
- 
  Subversion could recognize multiple levels of possible hierarchy in the server-side configuration:
  
-  1. server - Settings apply for all repositories and paths therein on the server
-  1. subtree within repository - Settings apply for paths at or under a given path in the
repository
+  1. subtree within repository - Settings apply for paths at or under a given path in the
repository.  This is a reasonable "phase 1" target for this feature.
+  1. server - Settings apply for all repositories and paths therein on the server.  We'll
probably defer this to "phase 2".  Admins are already used to having configuration duplicated
across many repositories (hook scripts, authz files, etc.), so we suspect it's no showstopper
if "server" configuration is done by ensuring that every repository is properly configured.
- 
- And at each level, multiple degrees of insistence in the actual configuration items:
- 
-  1. weak - The configuration value is proposed to the client, but will be overridden by
any client configuration
-  1. strong - The configuration value is strongly suggested by the client, and may not be
overridden by well-behaved client configuration
-  1. enforced - The configuration value is required and adherence to it is verified by the
server logic
  
  === 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 currently 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.
  
+ We plan to introduce a new capability string ("server-config") which clients should use
to announce to the server that they will honor the server's dictated configuration.  Administrators
may choose to use that string presence/absence in the list of capabilities passed to the start-commit
hook to determine whether to allow commits from certain clients.
+ 
  === Server-side storage ===
- ''[TODO]''
+ The most logical format for server-side configuration is to again use the INI file format
which is already employed for several other purposes across Subversion.  And the most logical
location to put those INI files is in ''${REPOS_PATH}/conf/'' somewhere.
  
  === 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.
+ The client current maintains a configuration in two files, ''${HOME}/.subversion/confi''g
and ''${HOME}/.subversion/servers''.  This feature will introduce the ''${HOME}/.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.  To facilitate path-specific configuration within a repository, the typical section
names of the configuration bits will be combined with the subtree path to which the options
therein apply.  For example:
  
+ {{{
+ $ cat ${HOME}/13f79535-47bb-0310-9956-ffa450edef68/config
+ [miscellany:/]
+ enable-auto-props = no
+ 
+ [miscellany:/subversion]
+ enable-auto-props = yes
+ 
+ [auto-props:/subversion]
+ *.c = svn:mime-type=text/x-csrc;svn:eol-style=native;svn:keywords=Author Date Id Rev URL
+ *.html = svn:mime-type=text/html;; charset=UTF-8;svn:eol-style=native
+ 
+ ...
+ $
+ }}}
  === Configuration Hierarchy ===
- ''[TODO]''
+ Server-dictated configuration will be the highest priority configuration recognized by well-behaved
Subversion clients, exception per-use overrides (ala --config-option).  Only specific options
will be made available for server-dictated configuration though.  Also, only certain of the
server-dictated configuration options will be overridable at all.  These details will be governed
by hardcoded whitelists.
+ 
+ So, the order in which specific configuration options will be honored where found is:
+ 
+  1. Per-use overrides (--config-option)
+  1. Server-dictated configuration
+  1. Per-user runtime configuration (''${HOME}/.subversion''/*)
+  1. Per-machine runtime configuration (''/etc/subversion/*'')
  
  === Related Issues ===
   * http://subversion.tigris.org/issues/show_bug.cgi?id=1974

Mime
View raw message