Login | Register
My pages Projects Community openCollabNet

svncontrol
Wiki: Documentation

Edit this page | Links to this page | Page information | Attachments | Refresh page

 

SVNControl Documentation

SVNControl - a remote administration program for Subversion-Servers.
This program is primarily intended for Servers running SVN with Apache. Currently, it is not tested with alternatives like snvnserve.

Please note that text in bold font indicates changes in the current version.

Installation (version 1.62)

Prerequisites

  • Subversion 1.4.x , 1.5.x or 1.6.x is installed, configured and in operation on the target server.

  • A JRE 1.6.x is installed on the target server as well on the client machines intended for the installation of the administration program.
    JRE 1.5.x is required as minimum version. The binary distributions are built for JRE 1.6.0_03. If you intend to run SVNControl with JRE 1.5.x please follow the source distribution install on a computer having installed a compliant JDK to your server, let the build script compile the sources and build the binary packages.

    Note: Please note the hints on upgrading the server to 1.50 below!

Files

Download the following files from SVNControl website.

  • svnControl-server-1.x.zip all files needed for an installation on a server

  • svnControl-server-1.x.jar to be deployed while updates to the target SVN server(s)

  • svnControl-client-1.x.jar to be installed on the admin client computer(s)

The following files are optional.

  • svnControl-applet-1.x.jar if password changes by individual users should be provided by an applet.

  • svnControl-jsp-1.x.war if password changes by individual users should be provided by a JSP.

  • svnControl-doc-1.x.jar the Javadoc generated HTML documentation of the SVNControl sources.

  • svnControl-src-1.x.jar the whole sources if you intend to build SVNControl on your own or if you like to read or modify the code.

  • svnControl-support-1.x.jar additional support files like starting SVNControl as a Windows service or deploying SVNControl to several Windows server.

Source distribution

Please ensure that you have installed a recent JDK 1.6.x and Apache ANT 1.7.

  1. Create a new directory (wherever you like and wherever you have write access).</li>

  2. Extract the svnControl-src-1.x.jar to an empty directory.</li>

  3. Run the default ANT target to build the binary distribution. If ANT is installed properly, this can be done by executing ant in the directory created in step 1. The archive files mentioned above (server, client, applet, doc) will be created in the bin directory (which also will be created if it was not present before executing ANT).

  4. Continue with the installation steps for the binary distribution of the individual parts of SVNControl as described below.

Please note that for Eclipse builds and development the eclipse-cs plugin is recommended (since SVNControl version 1.43). Furthermore, it might be necessary to add the default JSSE libraries to your Eclipse JDK configuration!

Installation of the server

Binary distribution

  1. Create a new directory to install SVNControl on the target server(s).</li>

  2. Extract svnControl-server-1.x.zip to the directory created in step 1 (of this section).

  3. You will find the following files in the directory (we assume that a repository has been set up for the use with Apache, i.e. a htpassword file (auth) and a permissions file are assumed to be present in an appropriate directory we will call svnHome in the following):

  4. the executable server jar
  5. config a file containing the dedicated administrator users in apache .htpasswd style

  6. hooklist a binary file containing the hooks installed by this program on the server

  7. properties the server configuration properties as shown below

    • timer a binary file containing the schedules

    • server.keystore the keys for SSL encryption

    • startServer.bat or startServer.sh might be helpful.

    • the files in lib, in particular lib/svnkit/svnkit.jar as well as lib/ganymede/ganymedeServer.jar</li>

    • the directory authentication needed by the authentication mechanisms to store imported user names (one name per line in ASCII format, optional information like name separated by tab).

    • the directory schemas containing the available repository schemas given in XML format (you may add your own schemas)

  8. Configure SVNControl for correct operations:
    • Modify the properties file extracted in the last step. The following lines show a typical configuration file.

      • ###############################################
        ###    Properties of SVNControl server      ###
        ###############################################
        
        # optional name of this repository, to be displayed on the GUI
        repositoryName=default
        
        # default server communication port for the administration protocol
        defaultPort=1080
        
        # optional password port for handling password change requests only
        passwordPort=1081
        
        # path to the repository home directory (also path to auth, the password file, and 
        # access, the user permissions file)
        svnHome=C\:/repository/
        authFile = auth
        accessFile = access
        
        # path to svnadmin.exe (may be empty to indicate that svnkit should be used instead 
        # of native process calls to svnadmin - required if SVNControl should run as Windows service)
        svnadminPath=C\:/Program Files/Subversion/bin/
        
        # mapping of administrator users from auth, otherwise taken from config
        admins=admin, eichelberger
        
        # disallowed user names, arbitrary number of names or Java regular expressions
        disallowedUserName.0 = Administrator
        
        In this file the following settings are specified.
      • repositoryName defines the name of the repository to be displayed in the title line of the client. Since 1.60 this name is used internally to distinguish among user names of different repositories for authentication, in particular to store all htpasswd users in one place.

      • defaultPort configures the TCP port for admin clients to communicate with the server.

      • passwordPort configures the TCP port for password changing clients to communicate with the server. This value is optional (if not specified the default communication port is assumed and communication for both parts of SVNControl will work on the same port).

      • svnHome the home directory of the repositories to be managed by this instance. You may use Windows UNC paths as follows: \\\\server\\share\\directory\\, e.g. if the user running the server has restricted permissions (non-admin user). Additional information on specifying Windows paths are given below when describing svnadminPath.

      • authFile the name of the apache style authentication file in svnHome; Present if SVNControl is installed after the first repository has been prepared to work with Apache. Otherwise it has to be created using htpasswd in MD5 mode, i.e. using htpasswd -m.

      • accessFile the name of the SVN style permissions file in svnHome. Present if SVNControl is installed after the first repository has been prepared to work with Apache or snvserve to determine the repository permissions. Otherwise, an empty text file is ok.

      • svnadminPath where the subversion binaries are located. If not given, SVNControl will fully rely on the svnkit library and will not require a binary install of subversion.
        Instead of svnadminPath=C\:/Program Files/Subversion/bin/ you may also write svnadminPath=C:/Program Files/Subversion/bin/ which caused some problems on some computers and thus required a strange configuration requiring a line break like

          svnadminPath=
          "C:/Program Files/Subversion/bin/"
        
      • Thus, we recommend the form svnadminPath=C\:/Program Files/Subversion/bin/.

      • admins is an optional line if users from auth should act as administrators, otherwise the users in the config file are considered. In the case shown in the example above, the administrator may change his/her own password using SVNControl.

      • disallowedUserName.''Nr'' an optional list of concrete user names or Java regular expressions to be not allowed to be created as users from the GUI

      • authentication.refreshPeriod an optional value defining the authentication refresh period in seconds. May be 0 or negative to disable the refresh at all. By default, this value is 1 hour.

      • baseURL an optional string denoting the base URL (per SVNControl server instance). This value is displayed on client side and does not influence the operation of the server.

      • disableApacheServerWarning an optional boolean value (true or false) to enable/disable warning messages considering the Apache server configuration when changing repository names. (default is false)

      • server.nossl is an optional value, which enables the client communication without SSL (default is false). For the client this can be specified with a checkbox in the login dialog.

      • client.hiddentabs is an optional parameter, which can be used to hide tabs in the main window. Multiple tab names can be separated with comma.
        ┬┤Possible tab names are: RepositoryTab, BenutzerTab, BenutzerrechteTab, GroupTab, HooksTab, ScheduleTab. The parameter is case insensitive, hookstab and HooksTab have the same effect. A hint for plugins: This mechanism considers the simple names of the classes realizing the tab to be hidden and, thus, can be applied to plugins, too.

        • authentication.htpasswd.policy an optional value defining the password policy of the default htpasswd authentication mechanism. Currently, the following policies are available:

        • server.NoPasswordPolicy

        • server.authentication.Default8SpecialCharPasswordPolicy

        Since version 1.50 also LDAP is supported as pluggable authentication mechanism. Therefore, the default htpasswd mechanism might be superfluous and one might want to disable it: authentication.htpasswd.enabled=false. Note that the admin passwords stored in the config file are still enabled and that at least one authentication module must be configured properly to run a server instance.
        Since version 1.60 another pluggable authentication mechanism for Atlassian Crowd was added. As the crowd connector maps users to groups internally, a GUI option in the Groups tab was added, to create a user as a group (without any sub-groups or users attached to it.) More detailed information about using the Crowd authentication mechanism can be found in the javadoc of the CrowdAuthentication class. For more information on the pluggable authentication mechanisms see one of the following paragraphs.

      • hooks.considerSvnTemplates an optional boolean value (true/false) determining, if the contents of a SVN hook template should be considered when creating a new SVN hook (true, default) or if the contents should be ignored (false)</li>

      • svn.pre14compatible=true determines if repositories in pre SVN 1.4 format should be created. svn.pre15compatible=true determines if repositories in pre SVN 1.5 format should be created. svn.pre16compatible=true determines if repositories in pre SVN 1.5 format should be created.

      • ui.repository.rename=false disables the rename button in the repository tab for all users (quick fix since 1.63, may change in future).

      • ui.repository.delete=false disables the delete button in the repository tab for all users (quick fix since 1.63, may change in future).

    If multiple repository directories should be served by the same server instance, create a properties file for each server instance (combination of admin server and password server thread as configured above) and append the number of the configuration starting with no number, than 1, 2, i.e. the default configuration is properties, the next properties1, properties2 etc. all with the same structure as shown above. Note, that each server instance should have its own and unique repositoryName and svnHome, in particular, if these instances should be added to the password change JSP as described below. Considering the configuration files "hooklist", "timer", and "config", similar individual files like properties must be provided accordingly, e.g. by copying the initial files shipped with SVNControl.

    In particular, in a multi-threaded multi-SVN environment the boolean property serverThreadEnabled (values true or false) allows to switch a thread on and off without the need of renaming the related configuration and data files. By default serverThreadEnabled=true is valid.

    • However, you need to specify how administrators may authenticate themselves with SVNControl. There are currently two mechanisms, and therefore two configuration options. Both mechanisms can be applied at the same time for the same SVNControl server.
    • You may specify all administrator users in the config file in Apache MD5 style using the htpasswd -m command.

    • You may want to map existing users given in the htpasswd file of your repository/repositories as shown in the example above for the user Administrator.

    • Furthermore, the JVM property svncontrol.dir may specify the main directory (installation directory) of the application where the location of the data files like config is assumed. If svncontrol.dir is not specified via -Dsvncontrol.dir=&lt;path&gt;, user.dir will be considered instead.

    • If for some reason, e.g. testing the server, the plugin directory must be located in another directory than the installation directory (see bullet above), the plugin directory can be given as JVM property svncontrol.pluginDir, i.e. as -Dsvncontrol.pluginDir=&lt;path&gt;. Similarly, the directory containing the application class files can be specified as svncontrol.classesDir.

    • The ANT build skript provides a target for regenerating the keystores of server, client and applet. If the passphrases should also be changed, the client class for the applet must be modified directly. The client passphrase can be specified in the file .SVNControl in the user home as client.passphrase, the server passphrase can be specified in the properties file as server.passphrase. After all modifications are done, the jar files should be recreated and deployed by executing the ANT targets jar (default target) or dist (complete distribution including Javadoc).

Logging configuration

Dependent on your installation, several logging configurations may be interesting:

  • Java logging - to be explicitly activated, see comm.Logging

  • Custom logging

In the case that the server runs as windows service, we disliked the standard Java logging. Therefore, we provided some optional switches for the properties file in order to configure custom logging:

  • If logDate=true is specified, the server will prepend the current date/time before log messages. Default: false because this is done by the supported service wrapper.

  • If emitExceptions=true is specified, the server will emit all exceptions regardless of any Java logging configuration. Default: true (since 1.41)

  • If emitInfoMessages=true is specified, the server will emit all exceptions regardless of any Java logging configuration. Default: true

Synchronization configuration

For multiple repositories (for instance for a master/slave environment) it is possible to synchronize the accessfiles to multiple servers. At the moment only rsync is supported. To use rsync one needs to be sure to have publickey authentication enabled and rsync can access from the server to the slaves without raising a password prompt.

  • synccommand the full path to the rsync command (i.e. /usr/bin/rsync).

  • synchost.Nr the hostname to sync to, without additional paths (i.e. myserver.tigris.org)

  • syncpath.Nr the path to where the accessfile will be synced on the slave.

  • syncuser.Nr the username that is used for the remote connection (i.e. svn-user).

  • Multiple destinations can be set up with increasing the Nr in the configuration.
    • A full sample configuration might be:

      synccommand=/usr/bin/rsync
      synchost.0=mysvn.test.org
      syncpath.0=/home/svn-user/accessfiles
      syncuser.0=svn-user

Update installation

Please replace the svnControl-server-1.x.jar on your servers. Depending on the update instructions, it might be necessary to modify the properties file or to delete the contents of hooklist or timer.

When migrating to 1.5x, please note that the packaging of the server distribution has changed so that the server.keystore must be located in a directory, that is part of the classpath of the server! Furthermore, you need a directory named "authentication" being writable for the server and the "schemas" subdirectory for read access for the server. If SVNControl is installed as a Windows service, please check the wrapper configuration for proper classpaths.

When migrating to 1.6x, please ensure that in partiular in multiple server instances installations the property repositoryName is set properly for all repositories. Also the svnkit libraries should be replaced, because in SVNControl 1.6 was built against svnkit 1.20 (stable).

Schemas

Since version 1.5 SVNControl provides initial repository schemas to be selected when creating a new repository. Two default schemas are shipped with SVNControl, the empty schema and the default Subversion schema consisting of trunk, tags and branches. You may add arbitrary schemas to the schema directory in the server installation as needed for your purpose.
Schema files are XML files following the example below:

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<repositorySchema name="SourceCode" description="Create a default source code repository." default="false">
  <path value="trunk">
    <path value="documentation"/>
        <path value="source"/>
  </path>
  <path value="branches"/>
  <path value="tags"/>
</repositorySchema>

The repository schema will be displayed in the client as SourceCode with the given description. A schema can be marked as default schema so that it will be displayed at the beginning of the list of available schemas in the client (it makes sense to have only one default schema). Three top-level paths will be created: trunk, branches, tags. Within trunk two further subdirectories will be created, documentation and source.

Installation of the client

Binary distribution

  1. Create a new directory to install svnControl on the administration client(s).
  2. Put the svnControl-client-1.x.jar into the directory created in step 1 (of this section).

  3. The startClient.bat file in the archive might be helpful for starting the client. Therefore, extract startClient.bat file into the directory created in step 1 (of this section).

  4. Optional: To use the client without SSL communication, in the startClient.bat or startClient.sh file the NOSSL parameter can be set to true. The selection can be changed later in the login dialog. The initial setting will be stored in the clients configuration and restored on the next start.</li>

Login problems

You can only log in to SVNControl if you have been marked as SVNControl administrators. To do so, you have (currently) two alternatives.

  1. Mention an existing SVN user in the properties file, i.e. the user must have been created with SVNControl or imported by an external authentication mechanism e.g. LDAP before.
  2. Use the htpasswd command for non-repository administrators, i.e. add the administrator user to the config file, e.g. htpasswd config ''username'' ''password''.

  3. Check, if the communication with SSL or without is the same both on client and server. For the client this can be changed via the Connect without SSL checkbox. In case the wrong connection mode is selected, the connection will be timed out after a few seconds.

Note that currently SVNcontrol must be able to assign the authentication mechanism to the user and therefore the user must have been created/imported in SVNControl before.

Display problems

On Windows Vista or Windows 7 comboboxes may flicker and may not enable selecting items. As this works under Windows XP, we currently assume a problem in the JDK (native look and feel). Thus, we added a workaround to the client (1.62, repository revision 220). Add

client.metalLuF=true

to the .SVNControl file in your profile directory. This forces the client to switch back to Metal look and feel and combo boxes should work properly.

Update installation

Please replace the svnControl-client-1.x.jar on your administration clients.

Installation of the password applet

Note, that this applet is intended for internal use only due to a required open (password) port (through a firewall) to the SVNControl server.
To use the applet to allow users to change their own passwords,

  1. Copy svnControl-applet-1.x.jar to an appropriate directory of your web server.</li>

  2. Extract applet.html from the archive into the same webserver directory.</li>

  3. Change the properties in applet.html, i.e. the host name/IP and the port.

    •      <param name="host" value="147.172.177.207" />
           <param name="port" value="11111" />
           <param name="nossl" value="false" />
         

      host must point to the SVNControl server, port to the port the SVNControl server is running on (the password change port if the server runs on two ports, otherwise the only port provided by the server instance). Adjust nossl if your server is running without SSL support.

Depending on your webserver it might be helpful to rename applet.html e.g. to applet.htm. The functionality of the applet does not depend on the name of the file.

Installation of the password servlet (JSP)

Since version 1.30, SVNControl also ships with a JSP page to allow user password changes without the need to open a firewall to computers outside your local network. The servlet also supports as frontend multiple SVNControl servers (currently hosted on the same computer).

Prerequisite: At least a current version of Apache Tomcat is installed on your server. The JSP is tested against Tomcat 6 and requires at least JDK 1.5.x. If the host for password changes should not be identical with the SVNControl host, it might be necessary to adapt firewall settings so that the password JSP can connect to the appropriate SVNControl server.

  1. Copy svnControl-jsp-1.x.war to the webapps directory of your Tomcat server and restart the tomcat server. It deploys itself. Alternatively extract manually all files in the archive using an unzipper or the jar command into a new directory in the webapps directory of your tomcat server and restart Tomcat.</li>

  2. Configure your JSP by modifying the config.jsp file. Here is an example:

    • <%@ page language="java" import="changePasswordJSP.*" %>
      <jsp:useBean id="changeBean" scope="session" class="changePasswordJSP.PasswordChangeBean" />
      
      <%
        changeBean.addServer("192.168.99.201", 1081);
        // if the server has SSL disabled, the addServer call has to be
        // done with the nonSSL option
        // changeBean.addServer("192.168.99.201", 1081, true);
              
        // changeBean.addPort("default", 1081, "192.168.99.201");
        // the same for nonSSL communication
        // changeBean.addPort("default", 1081, "192.168.99.201", true);
        changeBean.setPassphrase("applet");
      %>
      
    • This configuration does the following:
      • All instances of a multi-instance SVNControl server are added automatically by the first line. The server is 192.168.99.201, the publicly visible repository names from the configuration will be displayed. One of the password change ports is required to make a public query. This line (with appropriate data) may appear multiple times. If more than one repository is registered in the servlet, a selection opportunity will be displayed before showing the password change form.
        The addServer command is also available with only the port parameter in order to simplify the localhost configuration, with a port and nonSSL option, to switch off the SSL communication to the server. Also a version of addServer with server name, port and non SSL option exists. If the non SSL option is omitted, communication is established over SSL. (the commented addServer line shows the call for SSL switched off.)

      • The next commented line adds manually the specified port with a given name. Usually, this is line is appropriate, if not all ports of a server should be made public. This line (with appropriate data) may appear multiple times. If more than one repository is registered in the servlet, a selection opportunity will be displayed before showing the password change form.
        The addPort command is also available with only the first two parameters shown here in order to simplify the localhost configuration. Also variations for switching off the SSL communication exist in the same way as addServer.

      • Depending on your settings for generating SSL keys, the last line specifies the passphrase for the server-JSP communication. See the appropriate section above. This line is not required if you use default passphrases. Usually, the servlet/JSP will not be installed in combination with the applet. Therefore, the communication will be encrypted using the applet key. As mentioned above, SSL communication can be switched off by setting the boolean parameter of the methods to true.

Deployment

If you consider the deployment and installation to multiple servers, have a look into support/deploy/win32 of the source code or the support archive where a simple set of batch scripts allows to keep your installation up-to-date using a server-push mechanism.

Hooks

SVNControl is capable of setting hooks in a target repository. Therefore, the following conventions must be considered:

  • The executable of a hook can either be installed on the server before setting the hook-registration in the repository using SVNControl or the hook binaries can be installed by SVNControl. In the latter case, SVNControl the binaries must be configured and packed into a zip or jar archive for running in a subdirectory of the target repository hooks directory.
  • In each of the aforementioned cases of installing hooks, a special shell script (as long as one can call the Windows batch command line a shell) must be provided to describe how the hook will be called by SVN. Depending on the operating system of the server, this script must be called "hook.sh" (Linux/Unix/Mac Os X) or "hook.bat". This script must be prepared to receive exactly the parameters of the intended target SVN hook script (for details please refer to the documentation of SVN).
  • When installing a hook by SVNControl, the hook script described in the previous item will be inserted textually into the appropriate hook script of the selected SVN repository. If the SVN hook script does not exist, the appropriate template script will be considered. A new hook (and the shell code from the hook specific script) will be added to the beginning of the SVN hook script. Thereby, special shell comments will be used to signal the part that belongs to a certain hook.
  • To distinguish individual hooks, for each hook the name of the zip or jar file supplied while installing the hook with SVNControl will be taken as the name of the subdirectory in the SVN repository hooks directory.
  • Be sure that the executing process on your webserver has write access to the hooklist file. Otherwise the information on the hooked-in hooks will be lost when the SVNControl server (process) is restarted.

Plugins

SVNControl supports plugins since version 1.20. Plugins may be given as class files or in jar archives in the plugins directory of the program installation directory. A plugin must be split up into a server and a client part, i.e. implement the appropriate  gui.Plugin client/server.Plugin server plugin interfaces which must be directly located in a package named "server" or "client", whereby that package can be located in an arbitrary path. It is assumed that a plugin registers itself statically using the register methods in the abstract plugin classes. When the client GUI starts, the server is asked for each client if there is an appropriate server part. Only if this is true, also the client part will be activated. Client and server part may share common classes and relate to the libraries shipped with the SVNControl server.

Pluggable authentication mechanisms

Due to discussions at SubConf 2007, we decided to refactor the entire password mechanism in SVNControl version 1.4. There was a priority request to also support LDAP (supported since version 1.5). Therefore, a client now knows an comm.AuthenticationDescriptor, describing the capabilities and the name of a concrete authentication mechanism. Since the authentication is part of the server functionality and a client should not refer to a concrete implementation in the server, the server now contains server.AuthenticationMechanism classes, which themselves link to the appropriate describing descriptors in the common code part. Currently, as default implementation, the initial htpasswd mechanism was refactored to match this mechanism. Further mechanism may be added as default mechanisms or as plugins. The LDAP mechanism is dynamically loaded and instantiated according to the SVNControl configuration settings of the individual repository. See server.authentication for more information on how to configure the LDAP support. To support dynamic loading with the current class loader problems, the descriptor is realized as a final class that simply must be instantiated in a client side class to be loaded automatically.
To fulfill the request for other authentication mechanisms, the initial default implementation of password checks was refactored into password policy classes. A server.AuthenticationMechanism now refers to its concrete policy class that does the checking (now on server side). Policies can be configured to individual authentication mechanisms as described above. In a multi-repository environment, only the password policies given in the default configuration (no numerical postfix in the file name) are considered.
Hence, the client does not need to receive the concrete passwords in the user instances anymore. Therefore, that attribute was marked as transient.

Configuration of the LDAP-Authentication (taken from the email by Randal Cobb)

For sake of those who may need assistance (like I did but couldn't find any), here are the steps I had to complete to get it to work:

  1. First off, ignore the binary distribution. Check out at least version 1.62 or the HEAD revision from SVN.
  2. Build using typical ANT process.
  3. Create a local SVN user (to seed htpasswd) and add that user to the admins line in the SVNControl "properties" file. (You may also use an user in a passwd file used for the authentication of local users to one of the repositories you are administrating)
  4. Add to the SVNControl "properties" file the appropriate "authentication.ldapNr.*" or "authentication.ad0.*" attributes
  5. Start server
  6. Start client
  7. log in to client using the admin user created in step 3.
  8. proceed to the "Users" tab and "Search" to add users from LDAP/AD.
  9. edit SVNControl properties file to add appropriate LDAP/AD users as admins
  10. restart the SVNControl server.
  11. Log in to SVNControl client using new domain credentials.

Check the configuration of your web server if LDAP authentication for the repository is properly configurated.

LDAP configuration

Add appropriate configuration settings to your properties file. An example configuration may look like:

authentication.ldap0.port=1090
authentication.ldap0.serverName=localhost
authentication.ldap0.displayName=MyTestLdap
authentication.ldap0.attributeUserId=uid
authentication.ldap0.attributeRealUserName=givenname
authentication.ldap0.topDirectory=dc=sse,dc=de 
authentication.ldap0.fixedFilter=(objectClass=person)

The following settings are supported (Nr must be replaced by nonnegative numbers denoting the configuration whereby configuration numbers must be chosen in sequence):

  • <code>authentication.ldapNr.policy=className (optional)

  • authentication.ldapNrport=integer (default 398)

  • authentication.ldapNr.serverName=String (mandatory)

  • authentication.ldapNr.displayName=String (optional, combination of serverName and port will be taken if not present)

  • authentication.ldapNr.serverUser=String (optional, no value as default)

  • authentication.ldapNr.serverPassword=String (optional, no value as default)

  • authentication.ldapNr.useSSL=Boolean (optional, default: false)

  • authentication.ldapNr.userAuthPrefix=String (optional, specifies a prefix e.g. a domain name to be prefixed before an user name to do authentication)

  • authentication.ldapNr.attributeUserId=String (mandatory, denotes the name of the unique system account user name)

  • authentication.ldapNr.attributeRealUserName=String (mandatory, denotes the name of the real user attribute name [currently only one])

  • authentication.ldapNr.attributeUserEmail=String (optional, denotes the name of the user email attribute)

  • authentication.ldapNr.attributeUserEmailRegEx=String (optional, substitution regular expressions in the form /javaRegEx/replaceMatch/ to adapt the email if needed, e.g. /@sub\\./@/ to remove the first subdomain after the at)

  • authentication.ldapNr.topDirectory=String (mandatory, denotes the base directory for all queries)

  • authentication.ldapNr.fixedFilter=String (optional, default: "", a filter to be added to each query)

  • authentication.ldapNr.keyStore=String (optional, default: JAVAHOME\\lib\\security\\cacerts)

  • authentication.ldapNr.trustStore=String (optional, default: JAVAHOME\\lib\\security\\cacerts)

  • authentication.ldapNr.reloadUserData=Boolean(optional, default: false, if all user information should be reloaded and updated at the first)

As a convenient shortcut, configurations must not be repeated in multi-server installations. You may reference an existing configuration instead of specifying all configuration values again as follows: authentication.ldapNr.configRef=configFileNr.ldapNr whereby configFileNr is to be replaced by the configuration file number of the referred configuration in the same SVNControl server and ldapNr is the configuration you are referring to, e.g. "2.ldap3".

Active Directory configuration

Add appropriate configuration settings to your properties file. An example configuration may look like:

 authentication.ad0.serverName=localhost
 authentication.ad0.serverUser=domain\\user
 authentication.ad0.userAuthPrefix=domain\\
 authentication.ad0.serverPassword=veryVerySecret
 authentication.ad0.displayName=MyTestAD
 authentication.ad0.attributeRealUserName=givenname
 authentication.ad0.topDirectory=dc=sse,dc=de 
 authentication.ad0.fixedFilter=(objectClass=person)

The following settings are supported (Nr must be replaced by nonnegative numbers denoting the configuration whereby configuration numbers must be chosen in sequence):

  • <code>authentication.adNr.policy=className (optional)

  • authentication.adNrport=integer (default 398)

  • authentication.adNr.serverName=String (mandatory)

  • authentication.adNr.displayName=String (optional, combination of serverName and port will be taken if not present)

  • authentication.adNr.serverUser=String (optional, no value as default)

  • authentication.adNr.serverPassword=String (optional, no value as default)

  • authentication.adNr.useSSL=Boolean (optional, default: false)

  • authentication.adNr.userAuthPrefix=String (optional, specifies a prefix e.g. a domain name to be prefixed before an user name to do authentication)

  • authentication.adNr.attributeUserId=String (mandatory, denotes the name of the unique system account user name)

  • authentication.adNr.attributeRealUserName=String (mandatory, denotes the name of the real user attribute name [currently only one])

  • authentication.adNr.attributeUserEmail=String (optional, denotes the name of the user email attribute)

  • authentication.adNr.attributeUserEmailRegEx=String (optional, substitution regular expressions in the form /javaRegEx/replaceMatch/ to adapt the email if needed, e.g. /@sub\\./@/ to remove the first subdomain after the at)

  • authentication.adNr.topDirectory=String (mandatory, denotes the top-level directory)

  • authentication.ldapNr.fixedFilter=String (optional, default: "", a filter to be added to each query)

  • authentication.ldapNr.keyStore=String (optional, default: JAVAHOME\\lib\\security\\cacerts)

  • authentication.ldapNr.trustStore=String (optional, default: JAVAHOME\\lib\\security\\cacerts)

  • authentication.ldapNr.reloadUserData=Boolean(optional, default: false, if all user information should be reloaded and updated at the first)

  • authentication.ldapNr.useSID=Boolean(optional, default: false, consider the SIDs instead of user names, e.g. in the permissions file)

As a convenient shortcut, configurations must not be repeated in multi-server installations. You may reference an existing configuration instead of specifying all configuration values again as follows: authentication.adNr.configRef=configFileNr.ad whereby configFileNr is to be replaced by the configuration file number of the referred configuration in the same SVNControl server and adNr is the configuration you are referring to, e.g. "2.ad3".

Crowd Authentication

Crowd is a User/role/permission solution by Atlassian and provides also an Apache / Subversion connector. The main thing to use crow is, that the connector is directly able to map groups to logins without resolving the group membership in the authz file. As of this, the groups section is ignored in crowd. However, crowd has a problem with the leading repo name in the permission path ([svnrepo:/...]) so this should be removed afterwards or the crowd atlassian perl script needs to be patched with a simple regular expression to ignore the repository name. Crowd is at the moment not able to handle the SVNParentPath directive.

The properties for using crowd are:

  • crowdName: the name of the application set

  • crowdPassword: the password to authorize the crowd application set

  • crowdUrl: the SOAP URL string without the ?SecurityServer suffix

  • crowdQueryType: a string to specify, what will be queried, to reduce query time. Possible values are users|groups|both. Default is both to retrieve users and groups as list.

The configuration can also be numbered (starting with 0), as known from LDAP authentication source. A sample configuration could be:

 authentication.crowd0.crowdName=svn
 authentication.crowd0.crowdPassword=svn
 authentication.crowd0.crowdUrl=http://localhost:8095/crowd/services/
 authentication.crowd0.crowdQueryType=both

Credits and Contributions

Many thanks to all contributors:

  • Matthias Hoertzsch for implementing several issues, contributing new ideas and patches.
  • Christian Gewalt for implementing some issues and change requests.
  • Detlef Reichelt for the SUSE packaging specification, the packages on links2linux.de and several issues to improve SVNControl for Linux.

  • Frederico Senno for the Linux jar execution defect issue.
  • Bostjan Pirih for the relocate auth/access request, issue #51.
  • Martin Lehofer for the server startup defect issue (#52).
  • Karl-Heinz Marbaise for issues (#53-#57).
  • Robin Gawenda for the JAR packaging issue (#59).
  • Markus Mehlan for some patches
  • Carsten Sahling for improving qualified user name check for LDAP
  • The anonymous participants in our web survey.

Copyright notice

This software uses or relies on

Documentation (last edited 2010-10-29 08:21:20 -0700 by ?eichelbe)