Version Control with Subversion - Login

Server Configurationcess Methods”.) It also shows how to anchor svnserve in a virtual root directory, just asone often does when running svnserve as a daemon process. This might be done either torestrict access to parts of the system, or simply to relieve the user of having to type an absolutepath in the svn+ssh:// URL.It's also possible to have multiple users share a single account. Instead of creating a separatesystem account for each user, generate a public/private key pair for each person. Thenplace each public key into the authorized_users file, one per line, and use the --tunnel-user option:command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.comcommand="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.comThis example allows both Harry and Sally to connect to the same account via public keyauthentication. Each of them has a custom command that will be executed; the --tunnel-user option tells svnserve to assume that the named argument is the authenticateduser. Without --tunnel-user, it would appear as though all commits were comingfrom the one shared system account.A final word of caution: giving a user access to the server via public-key in a shared accountmight still allow other forms of SSH access, even if you've set the command value inauthorized_keys. For example, the user may still get shell access through SSH or beable to perform X11 or general port forwarding through your server. To give the user aslittle permission as possible, you may want to specify a number of restrictive options immediatelyafter the command:command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty TYPE1 KEY1 harry@example.comNote that this all must be on one line—truly on one line—since SSH authorized_keysfiles do not even allow the conventional backslash character (\) for line continuation. Theonly reason we've shown it with a line break is to fit it on the physical page of a book.httpd, the Apache HTTP ServerThe Apache HTTP Server is a “heavy-duty” network server that Subversion can leverage.Via a custom module, httpd makes Subversion repositories available to clients via theWebDAV/DeltaV protocol, which is an extension to HTTP 1.1 (see http://www.webdav.org/for more information). This protocol takes the ubiquitous HTTP protocol that is the core ofthe World Wide Web, and adds writing—specifically, versioned writing—capabilities. Theresult is a standardized, robust system that is conveniently packaged as part of the Apache2.0 software, supported by numerous operating systems and third-party products, anddoesn't require network administrators to open up yet another custom port. 4 While anApache-Subversion server has more features than svnserve, it's also a bit more difficult toset up. With flexibility often comes more complexity.Much of the following discussion includes references to Apache configuration directives.While some examples are given of the use of these directives, describing them in full isoutside the scope of this chapter. The Apache team maintains excellent documentation,publicly available on their web site at http://httpd.apache.org. For example, a general referencefor the configuration directives is located at http://httpd.apache.org/docs-2.0/mod/directives.html.Also, as you make changes to your Apache setup, it is likely that somewhere along theway a mistake will be made. If you are not already familiar with Apache's logging subsystem,you should become aware of it. In your httpd.conf file are directives that specifythe on-disk locations of the access and error logs generated by Apache (the CustomLog4 They really hate doing that.169