Posted by Doug
Tue, 05 Sep 2006 14:46:00 GMT
It’s clear mongrel is hot. There seems to be a million “tutorials” out there for setting up Apache to proxy to mongrel servers. When I wasn’t ready to set it up, it seemed like every couple blog posts was about how to do it. Once I got ready, I couldn’t find one that fit my situation. So, I thought I’d write up my experiences in the hope that someone doesn’t have to repeat my mistakes.
First, I’m running on Debian sarge. I like to stick with Debian’s package management when I can. Right now my one exception is that if it’s available as a gem, then I use that instead of the .deb. The biggest problem sarge presents to mongrel is that it ships with ruby 1.8.2 and mongrel requires 1.8.4. I followed these instructions on the Bytemark Hosting for building my own .debs for 1.8.4. This let me stay with debian’s package management, but still get a good version of ruby. I also built libdbi-ruby1.8 from source using basically the same steps.
Second, mongrel is pretty easy to install: sudo gem install mongrel. Then from your application’s root, just run mongrel_rails start. Unfortunately, installing from gem like this means you don’t get any fancy /etc/init.d/ scripts to start and stop the mongrel servers at boot time. I did see a nice post on Jens Kraemer’s blog that mentioned a mongrel package in experimental that does manage the start and stop of in a pretty elegant way. I’ll look forward to seeing that come to fruition.
Finally, the kicker: setting up apache to proxy to mongrel. Call me whatever you will, but I’ve still got apache 1.3 running as my primary web server. There’s not a lot of docs out there that say you can proxy from apache 1.3 to mongrel. As it turns out you can. I fought for a long time though getting it to work and eventually gave up. I ended up grabbing a “extra” IP address and running apache 2.0 out of debian sarge on that address. Horror of horrors, once I set all this up I still had the exact same issue trying to proxy 2.0 to mongrel as I did proxying 1.3 to mongrel.
Mongrel was running fine. I could connect a browser directly to the mongrel server and run the app all day long. The problem was definitely apache. I tried running mongrel in debug mode to see detailed logs. I tried using tcpdump to view the traffic between apache and mongrel. To no avail. When I loaded the first page of my app, it redirected me to the login. All my clients would get this far. When they tried to follow the redirect, it failed like this:
HTTP/1.1 400 Bad Request
Date: Tue, 05 Sep 2006 03:29:14 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>400 Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
<HR>
<ADDRESS>Apache/1.3.33 Server at lawnbutlers.lathi.net Port 80</ADDRESS>
</BODY></HTML>
After much weeping and wailing, it turns out the the trailing slash in your apache config is important:
<VirtualHost shaggy.sus4.net>
ServerName foo.bar.dom
ServerSignature On
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:4141/
ProxyPassReverse / http://localhost:4141/
ProxyPreserveHost On
</VirtualHost>
Without that trailing slash on the ProxyPass and ProxyPassReverse, apache tries to forward the requests to addresses like http://localhost:4141user/login, which clearly won’t work. Of course, I feel silly it took me so long to realize this was my mistake. I’ve seen plenty of other places where trailing slashes are important.
I guess what frustrated me the most was the lack of transparency in debugging the problem. I finally figured it out because apache 2.0 actually listed the bad uri in it’s error message. The error wasn’t the request the browser was sending to apache. It wasn’t the request the mongrel server was getting. In fact, the mongrel server never got the bad request. It was the request apache was generating on behalf of the browser. But that request wasn’t hitting “the wire” to be sniffed by tcpdump because it was bad. The only solution here was to improve the logging within apache itself.
Posted in System Administration, Software, Ruby on Rails, Typo, Linux | Tags apache, debian, mod_proxy, mongrel | 3 comments
Posted by Doug
Mon, 28 Aug 2006 13:24:17 GMT
I’ve got three Macs and one Linux fileserver. Why can’t we all share the same iPhoto library? I think we can. If you google ‘iphoto acl’ there are lots of tutorials on how to share iPhoto libraries on the same computer between different users. There’s not much that talks about doing it across different computers. Here’s what I did.
I setup a volume on my Linux box with the permissions such that all the files are group read/write and the directories have the group sticky bit set. With all the users that need access to the photos in the same group, this setup allows anyone to both read and create photos on the shared partition. Here’s a couple commands I use to set this up:
$ find /photos -type d -exec chmod 2775 {} \;
$ find /photos -type f -exec chmod 664 {} \;
So now the question of how to share the files. There are three options: NFS, Samba/smb, and Netatalk/AFP. As to the later, note that AFP is not necessarily Appletalk. AFP is a file sharing protocol; Appletalk is a communication protocol. Netatalk easily allows AFP over TCP/IP.
I’ve managed NFS before. Supposedly it’s the most mature and efficient of the three file sharing protocols. My main beef with NFS is managing user ids and group ids across all the NFS clients and server. I know you can use NIS, but that seems like more systems administration than I want to deal with.
So really it comes down to AFP and SMB. Which one is better? I’m not a very good judge of that, so what I did was setup both and measure the performance difference. I have a directory tree that’s several layers deep and has about 450 images; both Adobe DNG raw and processed JPEGs. The average DNG is about 5MB and the average JPEG is about 2 – 3 MB. I used rsync -av to copy the folder from my Macbook Pro (with a 7200rpm drive) across a 100Mb/s wired network to the server using both an AFP mount and a SMB mount.
With SMB using Samba 3.0.14a-3sarge1:
sent 2532341005 bytes received 8800 bytes 8657606.17 bytes/sec
With AFP using Netatalk 2.0.3-2.0.jones.2:
sent 2527694620 bytes received 8760 bytes 6591143.10 bytes/sec
It would appear SMB is faster. I’m not sure if this is a proper test or not. I don’t know if doing large file transfers like that is how iPhoto typically does it’s I/O. It seems convincing to me. Also, is AFP a better “experience” on my Mac because it’s Apple’s protocol? Honestly, I don’t know why it would be. The only difference I can perceive is typing ‘smb://tigermp/photos’ versus ‘afp://tigermp/Photos’.
Speaking of which, this brings up an interesting aside. I had setup netatalk quite a while back and had it working fine when both my Macs were running Panther. I upgraded my wife to Tiger first and her AFP mount wouldn’t work. I struggled and couldn’t figure it out, so I switched to Samba. This weekend it was recommended I switch back to AFP and I quickly ran into the same issue.
I would try to mount the volume and my Mac would tersely say “Couldn’t mount the volume, ‘photos’”. My Linux server’s logs were of no help. They simply showed a login and an immediate logout. So, I tried connecting via the command line:
$ sudo mkdir /Volumes/photos
$ sudo mount -t afp afp://dalcorn:_my password_@tigermp/photos /Volumes/photos
mount_afp: the mount flags are 0000 the altflags are 0020
mount_afp: AFPMountURL returned error -5019, errno is 32
I couldn’t find what error -5019 meant anywhere. Eventually I noticed that in my AppleVolumes.default I had specified:
/photos "Photos" veto:/lost+found/
So, when I tried to mount the AFP volume using “Photos” instead of “photos” it worked like a champ. Apparently, error -5019 means “no such volume”. Also, since this used to work on Panther, but broke on Tiger I’m assuming that means Tiger somehow became case sensitive on AFP URIs when Panther wasn’t.
One last thing. Since this post was originally about sharing iPhoto libraries I should mention that if you hold option down while launching iPhoto it will prompt you for which Library to open. Simply choose one on the shared volume and you’re good to go.
Posted in System Administration, Storycards, Photography, Mac OS X, Linux | Tags Apple, debian, iPhoto, MacbookPro, Netatalk, Samba, Tiger | 1 comment
Posted by Doug
Sat, 18 Jun 2005 21:46:00 GMT
I’ve finally got my HomeFileServer setup to use AfpAndRendezvousOnLinux. This allows me to use redundant hard disks in my file server and still mount them easily from either my or my wife’s PowerBook. Follow the links above for details. All in all, it wasn’t too bad to setup. It’s taken me forever to do though mainly due to time and having all the hardware pieces in place at once.
Posted in Linux | no comments
