Automating fixDAVsvn ¬

2009-11-17

I published my fixDAVsvn script seven months (and one day) ago to automate the process of fixing apache configuration files that have been manually modified to serve up Subversion repositories (per Nayan Hajratwala’s instructions) when they’re overwritten by Server Admin. This has made managing my apache install considerably easier, but upon rolling it out on a colleague’s server this afternoon I realized it was only ever a half solution. Sure, I had saved myself considerable time just by running fixDAVsvn, but others aren’t necessarily going to want to and there’s really no need. Time to add the second half.

So, how does one automate the process of running a command on a particular file whenever it’s modified? With launchd, of course! launchd drives some admins nuts, but I find it to be quite a boon and this happens to be exactly one of the cases it was designed for. So, I whipped up /Library/LaunchDaemons/com.makkintosshu.fixDAVsvn.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>com.makkintosshu.fixDAVsvn</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/bin/fixDAVsvn</string>
		<string>/etc/apache2/sites/0001_any_80_svn.domain.tld.conf</string>
	</array>
	<key>WatchPaths</key>
	<array>
		<string>/etc/apache2/sites/0001_any_80_svn.domain.tld.conf</string>
	</array>
</dict>
</plist>

The full path to the config file to run fixDAVsvn on needs to exist in both the ProgramArguments & WatchPaths arrays in com.makkintosshu.fixDAVsvn.plist. That said, you can add as many config files to watch and fix as you like.

So, the complete solution1 is to install fixDAVsvn and com.makkintosshu.fixDAVsvn.plist, then edit the latter to watch & fix your modified apache configuration files. I’ll likely package this all up with a script to build com.makkintosshu.fixDAVsvn.plist’s list of files automatically, but it may be another seven months.

1 This solution has been tested on both Mac OS X 10.5 (Leopard) Server and Mac OS X 10.6 (Snow Leopard) Server.

Tagged: , , , , , , , , ,

  1. i tried this and it doesn’t work. what steps can i take to debug why this would not work? do launch daemons run as root?

    David M. Cotter

    5333 days ago

  2. Which OS and version are you attempting this under?

    Yes, this particular launchd job needs to be run as root and should if installed in /Library/LaunchDaemons/. You’ll want to double check that the permissions on the .plist file are r/w/x by root, r/x by wheel, and none for everyone (run a quick `sudo chmod 750 /Library/LaunchDaemons/com.makkintosshu.fixDAVsvn.plist` if they’re not).

    Also, looking back at my post, I failed to note that one would need to run the following to actually load the launchd job (otherwise it’d only load after a reboot): `sudo launchctl load /Library/LaunchDaemons/com.makkintosshu.fixDAVsvn.plist`

    Morgan Aldridge

    5303 days ago

  3. Thanks for sharing your solution. I have a related question that you’ve maybe encountered. I’m running my svn auth over kerberos, using the server admin interface to add users from our university ldap. This authorization process is extremely slow, or something else in my implementation is slow. It takes 15-30 seconds to do an ‘svn update’ before any reading and writing begins. Have you experienced a slow svn transaction in such a setup?

    Phil Stephens

    5259 days ago

  4. Unfortunately, I’m using a fairly vanilla Open Directory setup (an OD Master w/all my users & groups defined, and web server bound to OD Master) and I have not run into any authentication performance issues. You might want to search and ask on Apple’s Macos-x-server or Macosx-interop mailing lists regarding this as many of the users there are in large education environments and will likely have further troubleshooting tips.

    Morgan Aldridge

    5259 days ago

  5. Hey, I just finished setting up Subversion on OS X Server 10.6.4, and I found this page while searching for possible problems. I also found a much easier way to handle the DAV svn -> DAV Off problem from commenter Micah on this page:

    http://web.mac.com/williamvanetten/Leopard/Leopard_Blog/Entries/2007/11/8_Configuring_a_Secure_Subversion_Server.html

    Basically, you can sneak by Server Admin’s re-writing by putting the DAV svn line into an external file, and including it from your site configuration file. In two steps:

    1. Create a file in /etc/apache2/extras/DAV_svn.conf, and put only “DAV svn” in it.
    2. Replace “DAV svn” in your site config file with “Include /etc/apache2/extras/DAV_svn.conf”

    Restart your server and you should be immune to Server Admin changes.

    Daniel Brauer

    5202 days ago

  Textile help