Setting Up Subversion for One or Multiple Projects
Before installing Subversion, we need to install the Apache 2.0 Web Server. So, download and unpack the source tarball and start the configure script:
sackville httpd-2.0.49 # ./configure --enable-mods-shared=most
The command-line option enables most of the Apache modules, building them as shared modules. You may need to fine tune the command-line options to include (or exclude) more modules; for example, you may need LDAP modules to authenticate against an LDAP server. To install the Apache Web Server, issue a make && make install.
Next, grab the latest Subversion source tarball, unpack the sources and start the configure script:
sackville subversion-1.0.1 # ./configure --with-apxs=/path/to/apache2/bin/apxs \ --with-ssl
The option -with-apxs may not be required if you installed Apache2 in a default location. Likewise, the option -with-ssl is not needed if you plan to install a server-only Subversion, because SSL support is provided by Apache's built-in mod_ssl.so module. In addition you may need to specify locations for your shared libraries. In particular, many users seem to have trouble with the Berkeley DB libraries. Carefully read the Subversion users' mailing list if you encounter problems.
Issue make && make install to build and install mod_dav_svn.so modules. If everything went well, you'll find mod_dav_svn.so among your modules.
The Subversion installation process should have created the proper entries in your Apache configuration file to activate the mod_dav_svn.so module. In addition, you should see entries for a mod_authz_svn.so module; it's part of the access control machinery of Subversion and we'll take a look at it later.
In our setup, Apache2 must reside side by side with Apache1, so we need to tell Apache2 to listen to a port other than 80--assume it's the 8080 port. Because Apache2 is accessed through Apache1, you should block that port in your firewall configuration or make Apache2 bind to the loopback interface. The latter solution is better than the former, because we don't need to rely on a firewall to drop incoming connections from external hosts. You also should apply common security tips to enhance Apache2 security, which I won't describe here. For example, Apache with Subversion modules tends to be a little too verbose in its error messages, showing version numbers for most activated modules (SSL, DAV, Subversion and so on). Security purists call this behaviour information leakage; to minimize it act on the ServerTokens directive.
Now it's time to decide where the repository will live. We must answer the following questions:
Where in the Apache2 URL's space will our repository be accessible? Because Apache2 is being used as a Subversion-only server, we decide to have the server root be the root of our repository.
Where in the server's filesystem is the repository physically located? We have no constraints here, so we choose /svn to contain all the Subversion-related files.
Where in the external Apache1 URL's space will our repository live? A common strategy is to put Subversion repositories in the /svn directory.
The layout of the /svn directory thus is:
/svn/conf: contains all the files needed for Apache2 and Subversion to work, such as user authentication information, access control policies and so on.
/svn/repository: contains two subdirectories for public and private projects. Inside each subdirectory we create a project using svnadmin's create command.
In the Apache2 httpd.conf file we add the following lines:
<IfModule mod_dav_svn.c> Include /svn/conf/mod_dav_svn.conf </IfModule>
Including the file /svn/conf/mod_dav_svn.conf, we centralize any Subversion-related information in the same place, that is, the directory /svn.
To proxy all the HTTP requests from Apache1 to Apache2, add the following entry to your Apache1 configuration file:
Proxy /svn/ http://localhost:8080/
When defining the access control policy, we must distinguish plain HTTP connections from HTTPS connections, because passwords are not protected over a plain HTTP connection. In the following lines, we define the default policy for HTTP connections. We add the following entries to the /svn/conf/mod_dav_svn.conf file:
Include /svn/conf/public_default_policy.conf Include /svn/conf/private_default_policy.conf
Each *_default_policy.conf contains the default access control policy for the corresponding project group. We want read-only HTTP public access for public projects, so add the following lines to your /svn/conf/public_default_policy.conf file:
<Location /public> Dav svn # Tell Apache to use Subversion's own module # for HTTP's Dav extensions. SVNParentPath /svn/repository/public <LimitExcept GET PROPFIND OPTIONS REPORT> Order deny,allow Deny from all </LimitExcept> </Location>
This configuration denies access to any HTTP method except GET, PROPFIND, OPTIONS and REPORT, which are used during a read-only session. If you have a trusted subnet (assume 192.168.0.0/24) you want to allow write access from, you may change the above configuration snippet to:
<Location /public> Dav svn SVNParentPath /svn/repository/public <LimitExcept GET PROPFIND OPTIONS REPORT> Order deny,allow Deny from all Allow from 192.168.0.0/24 </LimitExcept> </Location>
Notice, however, that if you don't add more access control rules to restrict access, anyone connecting from the subnet 192.168.0.0/24 can write to the repository. If you need strict user-based access control, then I advise you not to use this default policy.
The access control policy for the private project group denies access to anyone over an HTTP connection. The corresponding configuration snippet you must put in your /svn/conf/private_default_policy.conf is:
<Location /private> Dav svn SVNParentPath /svn/repository/private Order deny,allow Deny from all </Location>
If you wish to allow access from the trusted subnet, use the following:
<Location /private> Dav svn SVNParentPath /svn/repository/private Order deny,allow Deny from all Allow from 192.168.0.0/24 </Location>
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide