found drama

get oblique

bottom of it.

by Rob Friesel

So, ever since the OS X.3 “Panther” upgrade, I’ve been blaming myself for fxxxing up my hosts and/or Apache configuration. This one was just plain escaping me. I was using the same damn httpd.conf as I had been before… I’d gone into NetInfo Manager and removed my added “machines” and then re-added them. Based on my understanding, you set the test domains for the local environment in NetInfo and then you hack httpd.conf to set up the VirtualDomains or whatever to serve the right set of files when the browser requests them. I had this all going well under X.2. Everything was just fine and dandy.

So why wasn’t any of this working under X.3?

My guesses ran the gamut of “Something has been tweaked with Apache!” to “NetInfo Manager is different now!” to “They’re reverting to using a hosts file!” to “I’m just a complete idiot!” The latter was probably the closest to the truth. If only because I missed the memo:

APPARENTLY FileVault — all that lovely encryption — causes the Sites folder to be inaccessible. At least to Apache. Meaning that your user account’s site won’t show up in Rendezvous and any of those sites you’ve set up to have Apache serve locally for testing (etc) are bolloxxed as well. Meaning: you setup test.localhost in NetInfo Manager and add


    DocumentRoot /Users/youruser/Sites/testsite

    ServerName test.localhost

    ServerAlias testsite


…to httpd.conf and you would EXPECT Apache to serve the page right from that directory when you shove that into your browser. But when you activate FileVault, everything goes to shit and Apache refuses to serve these sites based on permissions-related line items.

The hack fix? set DocumentRoot to /Users/Shared/Sites/testsite and copy the /Users/... stuff into it … but then your site files aren’t encrypted. *le sigh!*

Still working this one out for the be[st|tter] fix.

About Rob Friesel

Software engineer by day, science fiction writer by night. Author of The PhantomJS Cookbook and a short story in Please Do Not Remove. View all posts by Rob Friesel →

Leave a Reply

Your email address will not be published. Required fields are marked *