Version Control with Subversion - Login

Server ConfigurationRecommendationsIn general, the authors of this book recommend a vanilla svnserve installation for smallteams just trying to get started with a Subversion server; it's the simplest to set up and hasthe fewest maintenance issues. You can always switch to a more complex server deploymentas your needs change.Here are some general recommendations and tips, based on years of supporting users:• If you're trying to set up the simplest possible server for your group, a vanilla svnserveinstallation is the easiest, fastest route. Note, however, that your repository data will betransmitted in the clear over the network. If your deployment is entirely within your company'sLAN or VPN, this isn't an issue. If the repository is exposed to the wide-open Internet,you might want to make sure that either the repository's contents aren't sensitive(e.g., it contains only open source code), or that you go the extra mile in configuringSASL to encrypt network communications.• If you need to integrate with existing legacy identity systems (LDAP, Active Directory,NTLM, X.509, etc.), you must use either the Apache-based server or svnserve configuredwith SASL. If you absolutely need server-side logs of either server errors or clientactivities, an Apache-based server is your only option.• If you've decided to use either Apache or stock svnserve, create a single svn user onyour system and run the server process as that user. Be sure to make the repository directorywholly owned by the svn user as well. From a security point of view, this keepsthe repository data nicely siloed and protected by operating system filesystem permissions,changeable by only the Subversion server process itself.• If you have an existing infrastructure that is heavily based on SSH accounts, and if yourusers already have system accounts on your server machine, it makes sense to deployan svnserve-over-SSH solution. Otherwise, we don't widely recommend this option tothe public. It's generally considered safer to have your users access the repository via(imaginary) accounts managed by svnserve or Apache, rather than by full-blown systemaccounts. If your deep desire for encrypted communication still draws you to this option,we recommend using Apache with SSL or svnserve with SASL encryption instead.• Do not be seduced by the simple idea of having all of your users access a repository directlyvia file:// URLs. Even if the repository is readily available to everyone via a networkshare, this is a bad idea. It removes any layers of protection between the users andthe repository: users can accidentally (or intentionally) corrupt the repository database, itbecomes hard to take the repository offline for inspection or upgrade, and it can lead to amess of file permission problems (see the section called “Supporting Multiple RepositoryAccess Methods”). Note that this is also one of the reasons we warn against accessingrepositories via svn+ssh:// URLs—from a security standpoint, it's effectively the sameas local users accessing via file://, and it can entail all the same problems if the administratorisn't careful.svnserve, a Custom ServerThe svnserve program is a lightweight server, capable of speaking to clients over TCP/IPusing a custom, stateful protocol. Clients contact an svnserve server by using URLs thatbegin with the svn:// or svn+ssh:// scheme. This section will explain the differentways of running svnserve, how clients authenticate themselves to the server, and how toconfigure appropriate access control to your repositories.Invoking the ServerThere are a few different ways to run the svnserve program:159