Today's MySQL Drama

Here's the situation homies. I had recently reinstalled OS 10.4 due to the problems I had with Tiger on my G4 Powerbook. I had a MySQL server running and needed to get it back online to get some work done. So I pulled down the latest binary release for Mac (5.0.27 as of the time of this writing). Installation went nary a hitch and after getting the datadir correct, I was able to make a client connection to the server. Enter the problem - I could show databases/tables but any query would return:

ERROR 1017 (HY000): Can't find file: './db/table.frm' (errno: 13)

Thankfully this post lead me to the solution, permissions d'oh!

computer$ perror 13
OS error code 13: Permission denied

Sure enought, the MYD, MYI and frm files of the database were owned by root with permission 640. Changing ownership to the mysql user brought the warm fuzzy. perror is your friend in the mix.

Compiling Apache on Mac OS X 10.4

Compiling apache 2.2.4 on Mac OS X 10.4 (Tiger) caused some complaints. I used all the default configure options, so:

computer# cd /usr/local/src/httpd-2.2.4
computer# ./configure
... bunch of output...
checking for chosen layout... apr checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. configure failed for srclib/apr
computer#

Of course config.log did not have any specific information about the C compiler and why the build failed. Several people have posted this same problem on various apache forums. The definitive answer for Mac users is to install the Xcode tools from the OS X installer DVD (they aren't installed with the OS. You have to open the Xcode Tools folder on the DVD and run XcodeTools.mpkg). Yes, it was that easy. Now apache got through configure, make and make install. The only other thing I did was to make a backup of the apache that comes with OS X (version 1.3.41) in case I ever need to use that version for some reason, and to make a link to my fresh install:

computer# mv /usr/sbin/httpd /usr/sbin/httpd_1.3
computer# ln -s /usr/local/apache2/bin/httpd /usr/sbin/httpd
computer# httpd -v
Server version: Apache/2.2.4 (Unix)
Server built: Jun 17 2008 14:43:30
computer #

Enable root on Mac

Update Enabling the root user in Snow Leopard (OS X 10.6) has changed some what. See http://snowleopardtips.net/tips/enable-root-account-in-snow-leopard.html for how to do it.

I can understand why Apple probably intentionally put this feature in a pretty obscure place. But after having to repeat every command and prepending it with sudo while getting a MySQL server instance up and running I had had enough. To enable you to su in the terminal:

Launch the NetInfo Manager utility found in /Applications/Utilities

Security > Enable Root User

You will get a warning the root password is blank, followed by a new password dialog box. After you setup a password you're good to go.

Browser Frustration of the Day

Page up/page down keys don't scroll the page up/down when the focus is in a text input.

Fun with pound and HTTPS

Recently it came to our attention a page loaded using HTTPS was being declared as a security risk due to included images, css and javascript files being loaded via HTTP. A developer had recently made some user interface improvements on the page, so naturally I thought he had coded the new images to load with HTTP, causing the SSL warning. After much grepping through includes and header files the cause turned out to be an incorrectly set base href tag in the header. We were using PHP's getenv command to check for the existence of the ssl variable being set - and thus setting the base href appropriately. Upon examination of the output of phpinfo() for a page loaded with HTTPS - the ssl environmental variable was not present. The lack of the variable seemed odd, so I checked the output of phpinfo() on our QA machine - it appeared here - and production and QA share the same code base. Hmmmmm.

Now what I haven't told you is our production web servers are load balanced by pound. Some googling revealed the pound decrypts HTTPS requests before dispatching them to a backend www server (so that's why you define the SSL certificate in pound.cfg. BTW - the .pem file pound wants to see is the concatenation of the site key + the site certificate + the intermidiate certificate. I lost a day trying to find this info.). Ok, mystery solved. Now then how to detect on the www servers the original request was via HTTPS and not HTTP? More googling... turns out you can insert a HTTP header into the request pound sends to a backend server. Add this line in pound.cfg:

AddHeader "X-Forwarded-Proto: https"
HeadRemove "X-Forwarded-Proto"

Now we can check for X-Forwarded-Proto in the $_SERVER scope. Wait there's more - it's called HTTP_X_FORWARDED_FOR now, so:

$request_type = if ($_SERVER['HTTP_X_FORWARDED_FOR']) ? 'HTTPS' : 'HTTP';

And that's it, problem solved.