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
<VirtualHost 127.0.0.1>
DocumentRoot /Users/youruser/Sites/testsite
ServerName test.localhost
ServerAlias testsite
</VirtualHost>
…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.
Leave a Reply