LAMP

I like to wait quite a while before upgrading Mac OS X to the newest release because, for me, it often requires quite a bit of work. I had hopes that Snow Leopard would be different because Apple finally installed current versions of the whole LAMP stack, but I wanted to wait regardless… just in case.

Why the wait?

I do dev work that require custom libraries in my PHP installation – vanilla PHP from Apple doesn’t have what I need. To do that I’ve relied pretty heavily on the Fink package manager. Too many times I’ve upgraded to the new OS and some of the libraries haven’t yet been updated to work properly on the new system. Usually after a couple months either the libraries get fixed or Google will give me enough results and clues that I can fix the issue myself.

First things first

I went ahead and compiled Apache from scratch. It’s easy enough and you’ll need the 64bit support for PHP. MySQL was much easier – download the intel x86_64 installer for Mac OS X 10.5 (yes, even for Snow Leopard). Side note – MySQL finally got around to recompiling the System Prefs Pane to 64bit.

Installing Fink

I’ll save you some time. First, compile fink from source. When you set up the app, do the 64bit-only packages (you’ll know – it’ll prompt you to pick 32bit or 64bit). I tried the 64bit and PHP wouldn’t install. You can always do a separate mixed architecture install later (see here for details on mixed fink arch installs).

Compiling PHP (with GD)

I need GD. This tutorial did the trick – once I had figured out the 64bit fink issue(s). Follow it and the companion standard PHP / Snow Leopard compile tutorial, linked in that article. Take a look at my compile flags, if you’re interested:export MACOSX_DEPLOYMENT_TARGET=10.6
CFLAGS="-arch x86_64"
CXXFLAGS="-arch x86_64"

Two things: First, my PHP is installed into /Library/PHP5/. Second, my Apache is located at /Library/Apache2/. Nothin to it. Too bad it took me all day to figure this out. At least now I can move on with my life!

I was looking for a simple solution to backup my newly constructed server to an off-site location in case something were to happen. I don’t mean I lost a file… more like catastrophic hardware failure, fire, water damage, physical damage, and even theft!. Local backups really are best, and I don’t plan on abandoning them any time soon, but in the case of the one in a million chance where something like this occurs, there’s a high likelihood that everything might be lost.

Here’s a fun little thing you can do for your next site goodie: display your users’ “fortunes” from the command-line interface, CLI, application Fortune.

On Fedora, install:% sudo yum install fortune-mod

from PHP (fortune.php)<pre>
<? passthru('fortune'); ?>
</pre>

I pre-formatted the text because it comes out looking as it does in the CLI. In its simplest form you can simply include this into a nice little div tag somewhere on your site (little side box above/below the nav?). If you don’t have privileges to install apps on your machine, this probably won’t work for you.

While you’re at it, take a look at simply parsing RSS feeds for your site. I found a good source over at BrainyQuote.com. Give it a shot!

If you’re looking for some help on learning mod_rewrite, this post isn’t for you. sorry. Instead, I’m going to show you a neat little trick that will make sure you always have one the www in front of your domain name. Why is it important? Potentially for your stats package, definitely for search engine ranking (no duplicated content), and even for uniformity across brand(?). Though it’s not necessarily part of your “brand” it is important to be consistent with the URLs you send people or have others link to.

For the purposes of this example, we want our URLs to always have the www in front: www.digitalfishlibrary.org

Step 1:
Open (or create) your .htaccess file and add RewriteEngine On if it isn’t already in there.

We use the http 301 response code to tell browsers and search engines that this is a permanent redirect, thus updating their records. Little-known fact: web browsers are supposed to automatically update bookmarks to the new URL from a 301 code. Search engines probably do the same with their indices.

Here’s a quick post for those having difficulties installing Fedora Core 5 (FC5) on systems with ATI cards.

Our new 80 node cluster install at the DFL is just about finished. I get two Dell PowerEdge 1425s all to myself for web stuffs. First order of business: ditch RedHat Enterprise Linux. I need cutting-edge software.

The install process goes fine in graphical mode until it’s time to restart. Reboot. After loading the system the screen goes black and doesn’t seem to respond to keyboard input. I could, however, log-in to the system via SSH and do some minor investigation, though it was painfully slow. Uptime showed a heavy processor load, and top showed that Xorg was taking up around 100% processor time. Hmm… Clearly a video card/driver-related issue.

I did some searching and found probably the easiest video card fix I’ve ever come across. (And remember – these instructions are ONLY for ATI cards). At the install boot prompt [boot: ] simply enter linux vesa. The install process went smoothly and the server is now usable in graphical mode.

It was bound to happen – I finally got a Mac at work for most of the web/media authoring I do. It’s important for me to at least be able to send email (i.e. attachments) without having to go an extra step by copying things like PSD and movie files over to linux just so I can send an email from there…

* Open the Evolution Email app and go to your contacts card
* Select all the contacts
* Right-click one of them and select “Save as VCard…”
* Save the file as list.vcf
* Open in Apple mail (you’ll need to email for FTP the file over to your mac)

You’re done.

The one thing I was surprised (and a bit annoyed at) was that is a lot of Evolution metadata that’s been stored in the Apple address book: Things like “X-EVOLUTION-FILE-AS: Last, First”, X-EVOLUTION-LAST-USE, and X-EVOLUTION-USE-SCORE. Otherwise, it’s alright and definitely a lot better than having to retype all your contacts manually.

Note that this post is oriented toward those with macs, but the same should work on other *nix systems with a few minor modifications.

Why do I need this? Well, I’m still on the campus network, but currently in another building, which precludes me from being able to mount the SMB share from the file server… something about the network that neither do I care to understand at this point, nor do I need to. There’s an easy work-around:

You need to forward ports to another server/workstation that has access to the samba share. Once you have the tunneling up and running you can act as if you were sitting at that other computer.

From the terminal: sudo ssh -L 139:host-ip:139 uname@server.ext

From the “Connect to server” dialog in the finder: smb://localhost/name-of-your-share

Put it to use: an example
Say you have ssh access to a computer, mydomain.com, which also happens to host the Samba share.

Open the terminal and type: sudo ssh -L 139:mydomain.com:139 username@mydomain.comenter your password on the computer you’re sitting at nowenter the password for the server you’re tunneling to
…ok Now you should be properly tunneled to mydomain.com

Open the “Connect to Server” dialog (Apple-K, or from the Finder: Go->Connect to Server…). Since the samba share is hosted on mydomain.com, you don’t need to do too much from here. For the sake of this example, we’ll call the mount “files.”
Enter smb://localhost/files
You’ll be asked for your username and password on the server mydomain.com

There you go… the samba share will mount on your desktop and you’re done!

I’ve begun using the Smarty template engine for my projects requiring dynamic content – you know, the good ol’ MVC (model-view-controller) approach to (web) applications. Because the sites I work on aren’t particularly high-traffic, I never really thought too hard about caching… until I actually began thinking about caching. The question is “why not?”.

With servers as quick as they are these days, even highly dynamic pages can be processed rather quickly. On one of my development machines, I’m getting between 65 and 70 fulfilled requests per second on a page with little in the way of optimization and no caching. By adding a simple caching scheme to this page via some built-in Smarty functions, that number jumps to about 105-110 fulfilled requests per second. Super!

Honestly, it’s so simple I might as well just point you to the appropriate documentation that tells you how to do it: HERE. The most important thing to notice is that you at least need $smarty->caching=TRUE;, and for goodness sakes, make sure your cache directory is writable by Apache (I would also make sure to either have your Smarty directory outside the site root or disallow access via a .htaccess file).

Time came to add a second hard disk to my workstation. I didn’t need a whole lot – just another 250GB for backup and extra storage space until the new workstation arrives later this summer. Here’s a quick tutorial on how to get the new disk in and running on you linux box.

Once the hardware is properly installed, open up a terminal and log-in as root.

/sbin/fdisk /dev/hdb(assuming this is your second drive and your primary is /dev/hda). /sbin/fdisk /dev/hdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.

The number of cylinders for this disk is set to 30401.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

While the exact distribution probably doesn’t matter too much, some steps are pertinent only to Fedora (i.e. the Yum install). Honestly, follow the instructions in the awstats documentation closely and you should be fine. My point here is to point-out some of the finer details.

When it asks for the location of the server configuration file:/etc/httpd/conf/httpd.conf (your apache conf file)
follow the remaining direction until you exit the configuration script. For the sake of this tutorial I’ll call the site “mysite.”

NOTE: Apache logs are typically in the common log file format. AWStats works to its fullest potential if you change the log file format to combined in your httpd file. If you choose to keep the common file format, you’ll have to make the appropriate changes in awstats.

Now configure the awstats config file you just created with the above script:% sudo emacs /etc/awstats/awstats.mysite.conf

You’ll need to edit a few lines to get everything working:(line 51) LogFile="/var/path/to/my/file_access.log"

(line 153) SiteDomain="subdomain.domain.ext"

#and any others you might be using
(line 168) HostAliases="subdomain.domain.ext 127.0.0.1 localhost"

One thing I was unable to get working correctly with HTTP authentication was:(line 328) AllowAccessFromWebToAuthenticatedUsersOnly=1
and(line 339) AllowAccessFromWebToFollowingAuthenticatedUsers = "__REMOTE_USER__"

If all goes well, you should see something along the lines of:Found 0 dropped records
Found 0 corrupted records,
Found 150 old records,
Fount 50 new qualified records.
…at the end of the update script output.

So, to do this with multiple domains, just repeat the steps above, making sure to make the appropriate changes to each domain…

You should now be able to visit http://www.yoursite.ext/awstats/awstats.pl?config=mysite and you’ll see the fruits of your labor. I chose not to allow web users to do automatic updates. Rather, I have a cronjob set to run the awstats.pl -update script a once per day
(I don’t administer any high-traffic sites, so it’s not critical to have the most up-to-date records). You can see near the end of my Incremental backups with rsync post for more information on that, if you’re interested.

A word of caution: AWStats is often the target of worm attacks through XSS (cross-site scripting). One reason to use Yum to install/manage awstats is that you don’t have to do any of the work to keep it updated (make sure you enable automatic yum updates in your systems services config (menu: Desktop->System Settings -> Server Settings -> Services; check the “yum” option is checked and you click the “Start” button while it’s highlighted). Also make sure to limit who can see the awstats reports.