Check it out.

Okay, I’ve had my share of troubles with that set-up — it is behind an Apache Reverse Proxy, with a bit of perl hacking to support move operations accross SSL tunnels. (I’ll post about this soon, I’m sure it will interest someone).

So, I was trying to import my new project and BANG, it dies.

Ajout          public/javascripts/application.js
Ajout          public/javascripts/controls.js
Ajout          public/404.html
Ajout          public/index.html
Ajout          public/.htaccess
svn: PUT of '/svn/repos/!svn/xx/.htaccess': 
302 Found (https://www.underwares.org)
svn: Le message de propagation a été laissé dans un fichier temporaire :
svn:    'svn-commit.4.tmp'

I first wonder the meaning of such foolery (foolery that has nothing to do with Tom, whatsoever) and then slap my forehead loudly.

I use shitty redirects for HTTP errors to display lovely custom error messages. SVN probably dislikes the redirect and displays it as the problem, hence, 302 found.

I comment that stuff out of httpd.conf, restart apache, and bam. There is the real error.

svn: PUT of '/svn/repos/!svn/wrk/xx/.htaccess': 
403 Forbidden (https://www.underwares.org)

Well, shit. It seems to be explicitely rejecting files named “.htaccess”. I thought it might have been mod_security being too anal once again, but that would have returned a 406 (content unacceptable). I still disable mod_security, to no avail.

I run a simple test to confirm. I create a folder with four files:

• .htaccess
• .htpasswd
• .htpouet
• .pouet

So, we’ll see what happen. I try to import them into svn. I first start with “.pouet”, for kicks.

$ svn import . https://www.underwares.org/svn/repos/private/test
Ajout          .pouet

Révision 275 propagée.

Well, that worked. So it’s not the dot. Next, “.htaccess”.

 phobos$ svn import . https://www.underwares.org/svn/repos/private/test
svn: PROPFIND request failed on '/svn/repos/private/test/.htaccess'
svn: PROPFIND of '/svn/repos/private/test/.htaccess': 
403 Forbidden (https://www.underwares.org)
svn: Le message de propagation a été laissé dans un fichier temporaire :
svn:    'svn-commit.2.tmp'
phobos$

Well, that failed. “.htpasswd” fails as well, and to much of my surprise, “.htpouet” fails as well.

Then it hit me. The following regular expression flashed through my mind: ^.ht Damn it! The default httpd.conf has a directive that denies access to such files on a global level. A quick look at the file confirms:

<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>

So here we go. I comment out that obnoxious directive, and move it inside the “Directory” directive of my vhost. I also add it to every single vhost on my server.

Some clever people are probably thinking, why didn’t you do something like this?

<Location /svn>
  <Files ~ "^\.ht">
        Order allow,deny
        Allow from all
        Satisfy All
  </Files>
</Location>

Well, you can’t have a Files directive nested inside a Location directive. You can, however, have one inside a Directory directive. So, now users can’t access .ht files through the web, which is good, and SVN can, which is good as well.

All of this was probably related to my sinister Reverse Proxy buisness. Don’t attempt such a set-up unless you like pain, kids.

What drove me insane was that, while you can publish your calendars to a WebDAV server for others to see and subscribe to, you cannot edit the calendars that are published — unless you have a .mac account. While I sincerly hope this will be in Leopard, I’m not holding my breath.

You see, I run Linux on my desktop at home, and Mac OS X on my laptop, for work. I just wanted to find a simple way to share my calendar between the two machines, and to be able to edit them on any machine.

And it just so happens I just have the solution.

Configuring the WebDAV server

Now, vast amounts of documentation can be found on the subject of setting up the WebDAV server. I’m not going to insult those who already worked on the problem by needlessly rewriting the instructions here. However, I will give you pointers.

• Enabling WebDAV on Apache [serverwatch.com]
• WebDAV on OS X With iCal [gregwestin.com]
• iCal Exchange (Free ics hosting)
• Free WebDAV Hosting [box.net]

So you could go ahead and setup your WebDAV server on *nix or OS X using the two first links, or you could just get free WebDAV hosting using the two others. Any will do.

For the sake of completeness, I will add my own WebDAV configuration below, on Gentoo Linux with Apache 2. I just installed mod_dav on apache2, and added the following configuration to /etc/apache/modules.d/10_mod_dav.conf:

<IfModule mod_dav.c>
  DAVLockDB /var/lock/mod_dav/Dav_Lock
  Alias /ical /var/dav/davroot
  DavMinTimeout 600
        <Directory /var/dav/davroot>
                Dav On
                Options +Indexes
                AllowOverride None
                AuthType Digest
                AuthName "ical-webdav"
                AuthDigestFile /var/dav/htpasswd.digest
                Require valid-user
                Order allow,deny
                Allow from All
        </Directory>
</IfModule>

Of course, I just then added a user using htdigest. You could use “AuthType Basic” if you don’t use mod_digest.

I tested the WebDAV functionality using the OS X “Connect to server” Function. Just enter the path to your webdav location.

I was prompted for authentication. Upon submitting my credentials, the drive was mounted on the desktop.

You should test to see if you can write files to the WebDAV folder. Once that’s done, we can move on the beef of this article.

Setting up iCal

You should take care of iCal first. First thing first, go ahead and share your calendar via iCal, as usual. Enter your WebDAV server information.

Once all is published and well, according to the little icon next to your calendar (), you have successfully published your calendar in a perfect read only fashion.

Making iCal Sync from the server

This is the sweet part, the core of this article. Now, we want iCal to also download the changes from the server. For this purpose, you must find out the Path of your corestorage.ics file for that calendar. Go have a look in ~/Libary/Application Support/iCal/Sources/, right now. (That being the “Library” folder from your Home Directory).

You should see some folder(s) with ugly names, one per Calendar you have. There’s no easy step to this, but you have to find out which is which. You can judge either by creation dates, or by opening the .ics file in your favorite text editor to see if you recognize some of the contents. Of course, if you only have one calendar, things are simplified, you will just have one folder, and one file.

In any case, write down the absolute path to the folder containing the ics file, it’s important. For instance, in my case, it turns out to be:

/Users/supernaut/Library/Application Support/iCal/Sources/2FBCA21F-80E0-44FD-B47A-ED34AE652010.calendar

ical_sync.sh

I have then written two scripts that take care of downloading, comparing and synchronizing your calendars from the WebDAV server. You will need the following utilities installed, most are available from Fink.

• wget
• md5sum

Download and place the following script somewhere on your system. I created a folder named “bin” in my home directory and placed it there.

Next, edit the script and change the variables to match your situation, eg:

ICALPATH="/you/core/ics/folder"
WEBDAV="http://www.yourserver.com/path/to/dav/folder/calendar.ics"
LOGIN="yourlogin"
PASSWORD="yourpassword"

WGET="/sw/bin/wget"
MD5SUM="/sw/bin/md5sum"

Remember! The value for $ICALPATH is actually the one you wrote down earlier. Don’t worry if you mess it up, the script will warn you.

Once that’s done, run it in terminal. It should tell you if ANYTHING goes wrong and back off. I made it extra careful, it would suck to wreck your calendar because the server is down or answers strange things.

This will indeed download and update your calendar on your Mac from the WebDAV server. But how will you make this happen automagically? Well, I have taken care of that too.

Working the Applescript magic

Turns out I have written a second script, this time, an applescript one. You can download the source over there.

Open it or paste it in Script Editor. You should then change the line

do shell script "bash /Users/supernaut/bin/ical_sync.sh"

to match the location of the ical_sync.sh script and then hit “compile”.

Once that’s done, just save it somewhere, but make sure you save it:

• As an Application
• Make sure the startup screen is unchecked

Once that’s done, simply replace the iCal icon in your dock by this script. You can add a pretty icon to it to make it more bearable.

Everytime you click on iCal then, it will sync up the calendar from the server, and tell if you if anything goes wrong. It will then proceed to launch the real iCal for you.

The AppleScript will show a dialog box if, say, the network is down, or something went wrong. For example:

You can then take action. As a precaution, in the event that it wasn’t what you wanted to do, the script will ask you if you still want to launch iCal.

I made it that way because, sometimes, you might want to look at your calendar without being connected to the internet. Makes sense, right?

Now, onwards to other Calendaring software.

Configuring Other Calendars

Nearly any other Calendaring software will not only fetch the lastest ics file from a webdav server, but will also write it back on change, or upon instruction to do so. This means, no problems whatsoever.

I use Korganizer in conjunction with Kontact on my KDE based desktop. Evolution and Sunbird could most likely do this as well.

I just added a calendar for a web source, and configured it with my WebDAV information:

Please excuse the craptacular quality of the screenshot. It was taken while forwarding X11 to my Mac over an SSH tunnel, and as such, fonts are screwy.

Then, it just worked out of the box. No problem whatsoever.

In conclusion

This is somewhat of a cheap and dirty hack, but it works fairly well. I’ve been using it for three weeks and it’s a dream. I sincerely hope that this has been somewhat useful to at least someone

Drop me a comment if you liked it, or if you have problems. Feel free to ask, really.

I decided it was a crime to shitcan such beautiful machines, so with the help of my friend Mike “I mangle french words” Le Blanc, we drove there, armed with a large truck and patience. Carrying them down the three stories with no elevator was an interesting experience. I scavenged lots and lots of interesting hardware there.

But i’m getting ahead of myself here. The point is, lots of screwy things start occuring when you have a Quad SMP machine, such a timers and clock drift. I started having a lot of problems with Apache recently… once in a blue moon, on restart, it would spawn a single process with no PID file, and hang there. Checking out error_log pointed out that apache would apparently hang while generating the Secret seed for Digest authentication (mod_digest). Disabling mod_digest would have worked, but sadly, I use it. This could be found in error_log:

[notice] Digest: generating secret for digest authentication ...
[notice] Digest: done
[notice] Apache configured -- resuming normal operations
[notice] caught SIGTERM, shutting down
[notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec2)
[notice] Digest: generating secret for digest authentication ...

Fortunately, I cobbled up a fix. Updated! Read on for a more elegant fix.

So it hangs while generating the secret for digest authentication. My gut feeling was that it had to do with the system running out of entropy (random data, that is). Probably waits for apr_generate_random_bytes() to complete but that never happens. I immediatly checked out the kernel for available entropy from /dev/random and friends.

# cat /proc/sys/kernel/random/entropy_avail
16

Now, I have no clue why, but entropy ran out (not quite, but close). Probably another whacky quad SMP issue. I’m starting to drive the Gentoo devs and maintainers crazy with my strange hardware.

Note: Before proceeding, please read the updated section below.

So, to remedy it, I fetched and installed rngd from the rng-tools package in Gentoo Portage. Check out your distro’s package repository for it or something similar. This tool allegedy gathers random data from I/O transactions and hardware stuff around. I compiled it, installed it and launched it. The Gentoo way:

# emerge -va rng-tools
# rc-update add rngd default && /etc/init.d/rngd start

Once that was taken care of, I checked the available entropy by querying the kernel once again.

# cat /proc/sys/kernel/random/entropy_avail
6854

That’s much better. To my surpise, Apache finished loading instantly the split second rngd started up. Schweet. Sounds like that fixes the problem. I have no idea why it occurs right now, but this works around it elegantly.

UPDATE! I figured out what the greasy poop was going on. Installing rngd will gather entropy using /dev/urandom if no hardware RNG is found by default. I didn’t pay much attention to that detail at the time. However, you will notice that when installing the Apache Portable Runtime on Gentoo (dev-libs/apr) the use flag urandom is available. Using euse (from gentoolkit) to get info about it returns the following:

valkyrie ~ # euse -i urandom
global use flags (searching: urandom)
************************************************************
no matching entries found

local use flags (searching: urandom)
************************************************************
[-    ] urandom (dev-libs/apr):
Use /dev/urandom instead of /dev/random

This will make apache fetch randomness from /dev/urandom directly, therefore giving the same result as rng-tools. The proper solution would be to just re-emerge dev-libs/apr with the urandom use flag enabled.

I tried it and it works beautifully, and looks a lot more elegant to me.