Integrating OSX Clients with an OpenLDAP Directory

This is an article by Adam Shand  you can view the original article at http://www.spack.org/wiki/AppleOsxIntegrationWithOpenLdap.

Where I work is primarily a RedhatLinux shop, with a smattering of MicrosoftWindows, SgiIrix and Apple Osx. While we will remain primarily a Linux house for cost reasons, Apple Osx is becoming an increasingly important part of our corporate workflow due to our dependence on quicktime, the increasing number of applications available and the increasing preference of both our artists and IT staff.

Because we already had a huge Linux infrastructure built I didn’t want to mess about with Netinfo or using an OSX Server as a bridge between our Macs and our LdapAuthentication infrastructure. I wanted our Mac’s to play nicely in our existing world, this meant that authentication, naming (users, groups etc) and automount all had to work with as little fuss or differences as possible.

Assumptions

To keep this howto as simple as possible I had to make some assumptions:

  • That you are moderately familiar with LDAP or willing to struggle through the relatively steep learning curve before tackling this.
  • That you have admin/root privileges on at least one Mac and one Linux server.
  • You are capable of installing and configuring complex packages.
  • That you are using AppleOsx 10.3/Panther as your client (I’m using 10.3.4).

  • That you are using running OpenLdap 2.0 on a Linux server (I’m using OpenLdap 2.0.21 on a RedhatLinux 7.3 box).

You may or may not have good luck following these directions with older or newer versions.

 

Setting Up the OpenLDAP Server

There are plenty of articles out there on setting up an OpenLdap server, so I won’t go into that here. If you haven’t done this before the best article I’ve found is the Mandrake Secure article (a slightly more evolved version is available on the authors wiki). If you are unfamiliar with LDAP and still want to tackle this probably the single most useful thing you can do is install a good LdapClient and start browsing around to get a feel of how it works. I recommend PHP LDAP Admin as by far the best client I’ve used.

OSX can access normal user and group data so long as you configure it correctly. The hard part, and the almost completely undocumented part, is getting OSX automount to work. OSX comes with two options for automounting directories, AMD and the Apple proprietary automount. I only discuss the automount option because all our attempts at configuring AMD resulted in a horrible unstable mess. 1

  1. Setup and configure an OpenLdap server.

  2. If possible make sure that you can authenticate to it from a Linux box and that everything works as expected before you continue any further.
  3. Add the apple.schema2 to you LDAP directory:

    1. Download the apple.schema file.

    2. Copy it into your schema directory (normally /etc/openldap/schema).

    3. Because of the way that Apple wrote their automount schema definition, adding it requires that you disable schema checking in your OpenLdap configuration. To turn off schema checking you must add this line to your slapd.conf:

      schemacheck off
      

  4. Restart OpenLdap for the configuration changes to take effect, watch the logs carefully to make sure that the new schema file was not rejected.

  5. If you have already populated your LDAP directory make sure you have top level containers called “ou=people”, “ou=group” and “ou=mounts”. If you haven’t populated it I’ve included a sample LDIF file which you can use to get started.

  6. Using the sample LDIF as an example, add enough valid user, group and mount entries for you test your configuration.

Note: I have not yet followed the above steps to make sure they are correct and that I haven’t left anything out. If you encounter problems please let me know.

 

Configuring the Apple OSX Client

These instructions were written for OSX 10.3 (Panther) however they are still approximately correct for anything from 10.2 to 10.4. Once you understand how it works just follow your nose and it should be fairly straight forward.

  1. Open Directory Access (/Applications/Utilities)
  2. Enable the LDAPv3 Plugin

  3. Select the LDAPv3 Plugin and click “Configure”

  4. Click “New”
    1. Enable: tick
    2. Server: ldap01.spack.org

    3. LDAP Mappings: RFC 2307 (Unix)

    4. Search Base Suffix: dc=spack,dc=org

    5. SSL: unticked
  5. Click “Edit”

    1. [optional] Open/Close times out in: 10

    2. [optional] Connection times out in: 10

    3. Use authentication while connecting: unticked
    4. Encrypt using SSL: unticked
    5. Use custom port: unticked
  6. Now Click on “Search & Mappings” 3

    1. [optional] Click on “Users”

      1. In the “Search base” box enter ou=people,dc=spack,dc=org

      2. Tick “first level only”

    2. [optional] Click on “Groups”

      1. In the “Search base” box enter ou=group,dc=spack,dc=org

      2. Tick “first level only”

    3. [optional] Click on “Mounts”

      1. In the “Search base” box enter ou=mounts,dc=spack,dc=org

      2. Tick “first level only”

  7. Save back out to the main “Directory Access” screen.

  8. If you’ve made any mistakes now is the time to catch them, use the techniques in the below testing section to verify that you can see users, groups and mounts. If you find any problems you should fix them before you continue or risk an unusable system.
  9. Click on the “Authentication” tab.

    1. Select “Custom” from the “Search:” drop down menu.

    2. Click “Add” at the bottom of the screen.

    3. Select the “LDAPv3 …” option from the “Available Directories” screen.

  10. Exit “Directory Access” and save all changes.

Depending on the exact order you exit “Directory Access”, you may need to reboot for the changes to become live. It can be a bit quirky and I haven’t figured out exactly which things make a difference yet.

 

Testing

The best program to test your new directory service with is an AppleOsx tool called dscl for “Domain Service command line utility”.4

You can use dscl to either search all of the available sources for information (via the /Search/Users path) or you can manually specify which particular directory you wish to query (eg./LDAPv3/ldap.spack.org/Users. The difference between Users and People seems to be based on whether the data is keyed on username (uid) or full name (cn/gecos).

Hopefully some examples will make it clear:

## to list only LDAP users
# dscl localhost list /LDAPv3/ldap.spack.org/Users
adam
ben
bill
paul
...<snip>...

## to list all available users (local, LDAP, NIS, whatever)
# dscl localhost list /Search/Users
adam
ben
bill
paul
...<snip>...

# dscl localhost list /LDAPv3/ldap.spack.org/People
Adam Shand
Ben Foo
Bill Bar
Paul Gaz
...<snip>...

# dscl localhost read /LDAPv3/ldap.spack.org/Groups/staff
cn: staff
gidNumber: 10
memberUid: adam ben bill paul
objectClass: posixGroup top
AppleMetaNodeLocation: /LDAPv3/ldap.spack.org
GroupMembership: adam ben bill paul
Member: adam ben bill paul
PasswordPlus: ********
PrimaryGroupID: 10
RecordName: staff

# dscl localhost read /Search/Users/adam
cn: Adam Shand
gecos: Adam Shand
gidNumber: 105
givenName: Adam
homeDirectory: /home/adam
loginShell: /bin/bash
objectClass: top person organizationalPerson inetOrgPerson account posixAccount shadowAccount inetLocalMailRecipient kerberosSecurityObject
sn: Shand
uid: adam
uidNumber: 364
AppleMetaNodeLocation: /LDAPv3/ldap.spack.org
NFSHomeDirectory: /home/adam
PasswordPlus: ********
PrimaryGroupID: 101
RealName: Adam Shand
RecordName: adam
UniqueID: 364
UserShell: /bin/bash

# dscl localhost read /LDAPv3/ldap.spack.org/Mounts/netapp\\:\\/vol\\/vol0\\/home
cn: rhun:/vol/vol0/home
mountDirectory: /home
mountOption: nodev intr hard nfsv3 resvport wsize=8192 rsize=8192
mountType: nfs
objectClass: mount
AppleMetaNodeLocation: /LDAPv3/ldap.spack.org
PasswordPlus: ********
RecordName: rhun:/vol/vol0/home
VFSLinkDir: /home
VFSOpts: nodev intr hard nfsv3 resvport wsize=8192 rsize=8192
VFSType: nfs

If the above works as expected then you should be able to:

  • Log into your OSX box with a username and password that only exists in LDAP.
  • Finger users that only exist in LDAP (e.g. finger -m <username>).

  • Change directories into a network mount location and have it automatically mounted (e.g.. cd /home/adam). This works for home directories as well.

  • Do an ls -l on a file owned by an LDAP user and group and have the uid/gid resolve into proper names.

 

Trouble Shooting

Debugging OSX

I heartily recommend that you turn the debugging up as high as possible. The best way to do this on the client side is to add a line like this to your /etc/syslog.conf and then restart syslog 5:

*.*                                /var/log/debug.log

Debugging LDAP

If you are having trouble understanding why OpenLdap is behaving the way it is, or why client queries don’t seem to be work as you expect, it’s very useful to fire it up in debug mode where it prints everything it’s doing to the screen. To do this stop your LDAP service and run slapd -d 255.

LDAP ACLs
Access control lists in LDAP are powerful, complicated and confusing. I recommend you don’t configure any ACL’s until after you have everything tested and working. After that enabled them one at a time and test copiously to make sure you haven’t introduced unexpected problems.
NFS Locks

If you NFS mount your users home directories you may find that your users experience random application hangs, especially applications which use the Addressbook.app. The way to resolve this is disable NFS locking. You can do this either by downloading Marcel Bresink’s [NFS Manager] or by editing /etc/hostconfig and changing the NFS locking line to look like NFSLOCKS=-NO- (you have to reboot for the change to take effect).

 

Further Thoughts

Automount Quirks
The Apple automount doesn’t support a few standard automount features, we’ve worked around them in various ways:

  • The special directory /net (or /hosts in SgiIrix land) allows you to mount any available share by simply changing into a /net/<hostname>/<share> style directory. While not ideal the best solution I’ve found is to reshare /net from an Linux server via Samba. OSX clients can then get similar functionality by manually mounting the Samba share (eg. Command-K and mount smb://samba.spack.org/net).

  • Actually, you can mkdir /net and add “-m /net -host” to the second automount line in /System/Library/StartupItems/NFS to get the /net behavior, or better yet, copy that item to /Library/StartupItems before modifying it so your changes don’t get overwritten. — Anonymous Comment — I will test this and update — AdamShand

    • * The above doesn’t seem to work on Intel Macs, anyone got any ideas?
      • Colin Aspin (caspin at mac.com)
  • Wildcard mapping using the * and & characters is typically used by autofs for home directories. The work around is to simply mount all of your home directories rather then rely on the wildcard mapping to mount just the required user home directories. This works fine, but it means that an accidental ls /home can be quite slow.

  • When getting automount maps from LDAP, automount doesn’t seem to be able to create required parent directories (so if you are automounting /foo/bar, you must make sure that the/foo directory exists when automount starts).

  • Automount keys mounts off of the source name instead of the destination name. This is silly since you sometimes have legitimate reasons for having the same share mounted at different points in your filesystem (but by definition can’t mount two shares at the same point in your filesystem).
Optimizing Searches

You can make the searches for user, group and mount data a bit more efficient by telling “Directory Access” exactly where it can find the information it’s looking for (as opposed to the default of it searching from the top of the tree down for matching entries):

Updating Automount

Sadly automount isn’t capable of automatically rescanning the LDAP server for changes, if you make changes to the automount data in LDAP you must either reboot (ick!) or kill -HUP the automount process (there are two automount processes, you want the one with all the “-m” options and the one without the “-nsl”6).

NFS Mount Options

OSX supports the usual NFS mount options but has two unusual ones. The first is “resvport”, this option is required for OSX to be able to mount shares from many NFS servers, as a general rule I recommend you always use it. The second is the “net” option, for the purposes of making an OSX box behave like a normal Unix box I recommend that you stay far away from it. If you want to learn more then Marcel Bresink’s excellent article is the best place to learn more.

Configure Slaves
Before you bring your new system into production I strongly recommend that you configure at least one LDAP slave. Because your new LDAP infrastructure will be responsible for all your authentication, naming and automounting needs, you really want the redundancy provided by a slave server.
Providing Redundancy with DNS
I name my master server ldap0.spack.org and my slaves ldap1.spack.org and ldap2.spack.org. I then create a DNS round robin called ldap.spack.org which points at all three addresses. Once you have this setup you should point your clients at the round robin alias ldap.spack.org. Now if one of your LDAP servers fails you can stop clients from talking to it by simply removing the failed server from the DNS round robin.
Better Redundancy

Better then a DNS round robin would be to provide redundancy with some sort of layer 7 aware proxy. I don’t know if any of the commercial switch providers offer LDAP aware load balancing switches. There may also be OpenSource alternatives that I’m not aware of.

Linux AutoFS

The Linux AutoMount daemon can also store it’s entries in the “ou=mounts” container of your LDAP directory. There does not seem to be any problem with the Linux mount entries coexisting with the OSX mount entries in the same ou.

Automation

I have some PerlLanguage scripts which will mirror the contents of the Linux “auto.master” and ‘””auto_*” files into OSX automount format on an LDAP directory. If get permission, I will post them here.

SSL
Before deploying this you should make sure that all of your clients and servers are configured to talk to LDAP over SSL encrypted links. Eamon Caddigan has kindly written in with what he did to make it work:

  • Once unencrypted authentication was working, I followed these instructions for configuring the server to use SSL (part of the expanded Mandrake Secure guide already linked to your site). After restarting slapd, simply tick the “Encrypt using SSL” checkbox (“Use custom port” is left unticked because TLS uses the standard port) in the Directory Access app on the OS X client. Unless I’m missing something (very possible), that’s all there is to it.

 

Missing Pieces

Remove Mapping for Password
In the attribute mapping part, if you remove the password map then OSX will authenticate the user by binding to the LDAP server rather then doing a password comparision. This means your encryption method becomes transparent to your clients and you can get away from crypt. Untested.
Use DHCP Supplied LDAP Server

OSX supports getting it’s LDAP information from DNS, I have not successfully made this work yet and am a little confused about how you are supposed to configure it this way since “Directory Access” does it’s pathing seems to require that you know the name of the LDAP server the client will use. Here’s a snippet from a /etc/dhcpd.conf, though I still wonder how to specify two LDAP servers:

option ldap-server code 95 = text;

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.200 192.168.1.250;
  option routers 192.168.1.1;
  option domain-name "spack.org";
  option domain-name-servers 192.168.1.2,192.168.1.3;
  option ldap-server "ldap://192.168.1.2/dc=spack,dc=org";
}

Write Mappings to Server

You can write your custom mappings to the server so that you don’t have to manually configure each client. I have managed to write the mappings to my server but have been unable to make the client pay any attention to them. There is some more information in this security advisory.

Need for a personal server? iServe?

Consumers are increasingly investing in three forms of digital content (content that lives primarily on hard drives):1) commercial content, such as music, TV shows, and now movies; 2) personal content, such as photos and home video; and 3) hybrid content, commercial or public content that consumers have recorded or downloaded, such as TV shows saved on personal video recording (PVR) devices like Tivo and content downloaded from Internet sites like Google Video.

For consumers embracing commercial, personal, and hybrid content, two challenges are rapidly emerging:

  • Massive storage needs. For some content, such as music, each song file is relatively small (perhaps 3 or 4 megabtes (MBs)), but a collection can take up many gigabytes (GBs) of storage. For other content, such as movies, files can each be multiple gigabytes (e.g., the file for the movie Pirates of the Caribbean from Apple Computer’s iTunes Store (iTS) is 1.6 GB; a recent episode of the TV show Battlestar Galactica from iTS is over 480 MBs; the movie Superman Returns from Amazon.com’s Unbox download store in “DVD quality” is 2.9 GBs). And as high-definition content becomes the norm, the file sizes will only increase.
  • The use, management, and distribution of content. Many households have multiples PCs (we use the term PC to mean a computer running Windows, Mac OS, Linux, or any other user operating system), and many consumers also bring home notebooks and other portable computers supplied by their employer. Each of these devices may be purchasing and storing digital content, and many of the downloaded files are locked down by various digital rights management (DRM) technologies, such as Apple’s FairPlay, that set the rules for how the content can be used and distributed. Added to the mix is the the growing personal content, such as multi-gigabyte photo databases and video repositories. In households with adults and kids, these issues will become critical very quickly.

Media center PCs and external hard drives won’t cut it; a home server is needed

The storage issue is the first challenge most consumers face as they embrace digital content. Even those with modest music and photo collections can quickly find their primary PC unable to cope with the gigabytes of content. Unfortunately, many consumers may also experience the downside of unprotected digital content if that central PC has a hard drive failure or files are corrupted. And as consumers experience the ease of buying and using digital downloads (e.g., quick delivery and instant access without fumbling with physical media), they will also face the issues around DRM and device authorization limitations.

These experiences have or will lead consumers to look at two potential solutions:

  • Media management and distribution on media-centric PCs. Both Microsoft and Apple market products aimed at the consumer interested in a media-centric PC. Microsoft currently sells Widows XP Media Center Edition 2005 software (soon to be upstaged by various flavors of its next-generation operating systems, Vista) that includes technology for recording TV shows, displaying photos and videos on TVs, and linking with other devices, such as the company’s Xbox 360 game console, using Media Center Extender technology. All of Apple’s consumer-oriented products, such as the iMac, Mac mini, and MacBook offer somewhat similar technology for remote display of content (notably, Apple does not offer its own PVR software). In addition, Apple recently announced plans to deliver “ITV” (a code name), a set-top box that connects to TVs and plays digital content wirelessly streamed from Apple software. ITV is expected sometime in Q1 of 2007 (see this Engadget article).

  • More storage by buying high-capacity hard drives as part of new PCs or in external packages. Hard drives are relatively cheap these days. It is not uncommon to see home PCs with 250 GB drives, and external hard drives that rely on USB or FireWire connections are also relatively inexpensive (a 500 GB external hard drive may cost anywhere from $200-300). They are also simple to use — just plug them into most PCs and the storage is available.

The problem is that neither one of these solutions address the storage and media management challenges effectively. Media-centric PCs are about making one PC the center of the household media experience. They don’t provide a way to easily distribute and manage content, playlists, and related databases among consumer devices. And larger, single hard drives most likely won’t provide enough storage for the household, they are tied to a PC, and they don’t have any “brains” — i.e., they lack software and tools for managing content. They are just big, dumb filing cabinets. And as many home PC users know, relying on a single drive with no backup plan — which is the case for most consumers — is a disaster waiting to happen.
Some technophiles have invested in network attached storage (NAS) devices, essentially high-capacity, multiple drive appliances that adds storage to any network. Others have bought multi-hard drive disk arrays that plug into a single PC. Again, while these solutions offer plenty of storage, they aren’t designed to overcome the challenges of consumer content management.
Instead of media center PCs or larger hard drives, we think the most sensible solution is a dedicated home media server that combines lots of storage with the required software brains to intelligently and seamlessly manage consumer content of all types.

What a home media server needs to do

A home media server is a lightweight server designed to store, stream, sync, and manage a household’s complex portfolio of digital assets. It is not meant to be used as a computer. It will be tucked away in a utility closet or hidden behind closed cabinet doors in the living room media center. Ripping CDs, buying TV shows online, and editing photos will be handled by other household devices. The home server will:

  • Store content by auto-syncing with and backing up other devices. On the surface, the primary job of the home media server is to simply store files. But manual storage or rudimentary backup plans are not enough. The server’s software needs to be tied into the media applications on other household devices. When a PC in a kid’s room buys a show, a copy of the file will be copied to the server’s hard drives. Periodically, the server will run a backup program that culls connected devices to discover new files, such as family photos, that need to be archived. In other cases, a consumer may choose to ensure that all files of a certain type are only on the server. Either way, the media server becomes the central repository of the household’s digital horde.
  • Distribute content using streams or file transfers. Some content needs to be on a device, such as a notebook computer (a consumer may want to watch a TV show or listen to certain music while traveling), while other devices only need to access a content stream from the server. A home server would enable consumers to choose whether to move large media files and collections to devices, leave most files on the server, or make those decisions based on the capacity of each device.
  • Manage content –including DRM files — on devices and by accounts. In the two previous bullets, we talked about examples where consumers would determine how content was stored and accessed. This management function of the server will also be critical in terms of DRM content. If the music industry, for example, insists on keeping the 5-device limit on audio file use, the server software could be used to easily authorize or deauthroize devices. Also, the server could be configured so that some content, while household owned (by the “super” or Admin account), is restricted to certain users. In addition, it could manage multiple user accounts, each with their own authorization, so that siblings’ content was managed, but kept separate.

How Apple could do it: The “iServ” concept

Two companies are likely to lead the home server charge: Apple and Microsoft. However, since Apple dominates the digital download market for audio today, and since they have direct control over their PC and server hardware products, we will focus on what it could deliver. Also, Apple is continually looking to innovate with its consumers offerings, and the idea of an “iServ” media server seems very reasonable given the company’s history.

Image of Apple iServ concept

Inside the iServ

The server would be built around these concepts:

  • User upgradeable storage. The iServ would offer bays of hot swappable hard drives, perhaps up to 1.5 terabytes in a three-drive configuration. The large storage would provide a central repository for content as well as enable household backup of data on various other Mac, PCs, and digital devices. The iServ could ship with a single 250 GB drive; consumers would got to the Apple Store or order additional drives online.
  • Automatic syncing of household digital content. Any device on the network that buys a song, TV show, or movie from the iTS will inform the server of its purchase; a specialized iTunes iServ app will make a copy of all content purchased on authorized household systems. This copy will serve as both an archive, as well as a source for streaming or copying the file to other authorized devices.
  • Streaming access to content. Besides enabling simple backup and transfers, iServ would be hard wired or use wireless connections to directly stream content to other computers or the forthcoming ITV set-top box. For example, when a mom purchases a copy of the Office on her laptop, the device will notify and transfer a copy of the file to the iTunes server app on the iServ. Without any extra effort, the family can then access the show from the FrontRow interface on the ITV box.
  • Remote management of the iServ. The home server could be used in a headless fashion — controlled by a remote Mac — or with a local monitor. The iServ Remote software would enable the household administrator to set policies on content access, such as restricting streams or transfers of explicit content. From this remote console, a consumer could authorize and deauthorize household devices and otherwise manage FairPlay digital rights management issues.
  • Additional household software. Just as Apple offers complementary — but secondary — applications for its iPods, such as games, the iServ could offer its own complementary software, such as a server-based family calendaring solution. In addition, an iPhoto server app could archive, backup, and enable local distribution of family photos.

Could Apple really do it? Is it a realistic product? Yes, because:

  • Consumers might want it today, but they will need it tomorrow … Consumers will bump into a wall as they buy more and more digital content. Managing DRM files and swapping them to various devices will become increasingly frustrating, as will authorizing and deauthorizing systems. Losing content to a hard drive failure will make any consumer interested in a seamless backup solution. Overall, the iServ would make digital content ownership much easier.
  • … and Apple already has most of the pieces. The box itself could be basically a Mac mini with drive bays. The hot-swappable bays are technology Apple is familiar with in its Xserve and Xserve RAID offerings (the vendor calls them Apple Drive Modules). The iCal Server is already being developed for Mac OS X 10.5 Leopard Server. The core technology for remote manage already exists in Remote Desktop, and Backup and iSync technology have already been built.Apple could leverage its Core Animation development technology to create easy-to-use but powerful iServ management tools and apps. Other OS X Server features that could be utilized include Software Update Server, allowing a household to stay on top of Security Updates and other patches. Non-needed server features could be hidden, such as Open Directory and Xgrid. The most work would come from creating an iTunes and iPhoto server app.

Finally, what about price? An interesting Apple product that costs too much can fail (e.g., the Cube). While this note is not the result of detailed research on component pricing or likely acceptable consumer price points, we can make some assumptions based on current Apple, competitive, and peripheral products:

  • iServ with one 250 GB drive, Mac OS X Server (iServ Edition) and iServ apps – $999
  • Additional drives – 250 GB for $150; $500 GB for $300

With budding demand and the technical capability, we just have to wait and see how long it takes Apple to build and sell an iServ.

By: Tom Rhinelander, NRG Analyst

Installing WordPress on Mac OS X Tiger

Of the many options out there, many people choose to run their own blogging software as opposed to a managed service like Blogger or TypePad. On the software side, there are many decent tools available, such as Six Apart’s Movable Type (we have a tutorial for installing MT as well). WordPress is another mature, capable and free blogging engine that is very popular with many bloggers (like its founding developer, Matt Mullenweg) and rapidly gaining in popularity across the Web. WordPress is an excellent choice for a personal or professional blog, and the price is right, too. This tutorial will show you how to install WordPress 1.5.1.3 on OS X 10.4 Tiger.

Note: The most recent version of WordPress is 1.5.1.3, which contains a security patch among other improvements. This tutorial is fully compatible with the most recent version of WordPress. Version 1.5.1.3 is recommended for all WordPress users (upgrade instructions).

If you have installed another blog engine such as WordPress or Movable Type already, you may already have MySQL and/or PHP configured. If this is the case, you can skip right down to step 4.

Before we get started, let’s summarize what we’ll be going over in the installation:

  1. Downloading and Installing WordPress 1.5.1.3
  2. Enabling Personal Web Sharing
  3. Downloading and Installing MySQL
  4. Configuring MySQL
  5. Enabling and Testing PHP
  6. Configuring WordPress
  7. ???
  8. Profit!

Downloading and Installing WordPress 1.5.1.3

WordPress LogoIf we’re going to blog our way to stardom, we’ll need some blogging software, right? The first step we’ll take will be to download the latest stable version of WordPress, version 1.5.1.3. The compressed file should be about 250KB, and OS X will decompress it for you.

Once it’s decompressed, we’ll move the wordpress directory to OS X’s Web hosting directory in /Library/WebServer/Documents. By default, all requests for the domain’s root directory (like http://maczealots.com/) will go to this directory. This can be changed in Apache’s httpd.conf file, which we’ll cover later. If you like, you can also change the name of the wordpress directory to something else, like blog. This way the URL of the blog would change to http://www.yoursite.com/blog/ Additionally, if you want the blog itself to be at the root directory, delete all the items from the /Library/WebServer/Documents directory and move the contents of the wordpress directory to the now-empty Documents folder.

Enabling Personal Web Sharing

“Personal Web Sharing” (PWS) is Apple’s marketing name for Apache, the industrial-strength, tried-and-true Web server du jour. When you enable PWS, OS X starts up Apache, registers the modules, opens ports, etc. Since we’ll be serving the blog, we’ll need to have Apache running.

To enable Personal Web Sharing, open the Sharing preference pane in System Preferences. Check the box labeled “Personal Web Sharing”, and that’s it. (You may have to authenticate as an administrator before it will let you enable anything.) Go ahead and close System Preferences; you’re ready to install MySQL now.

Note: We are working on a version of this tutorial that includes the ability to host the database with SQLite, which is prepackaged in OS X 10.4. However, support for SQLite in WordPress is still being fully developed, so for now MySQL is still the way to go. If you’d like to see such an article, let us know.

Downloading and Installing MySQL

MySQL is the database backend that WordPress (and other blogging packages like Movable Type) can use to store blog entries, users, comments, etc. MySQL is free for personal use. First, download MySQL (4.0.24 at the time of publication). It will come as disk image with two packages and a readme. We will be installing both packages. First, open the main MySQL installer. It will install all the necessary components to run MySQL onto your OS X volume. After that installer has completed, run the startup item installer, which will automatically start up MySQL after any computer restarts.

Note: One of the most common problems reported is that people install MySQL 4.1 instead of 4.0. I can understand the desire to be on the bleeding edge of software, but WordPress (and most other blog/CMS engines) use an older authentication scheme that is incompatible with MySQL 4.1 and greater. There are hacks and workarounds out there, but for the easiest installation, stick to MySQL 4.0.

Configuring MySQL

Now that you have installed MySQL, let’s configure it so WordPress can access it. Open a new terminal session (found in /Applications/Utilities/Terminal.app) and type the following commands to navigate, make some changes, and start the MySQL daemon:

cd /usr/local/mysql
sudo chown -R mysql data/
sudo echo
sudo ./bin/mysqld_safe &

Next, let’s launch MySQL and use the test database (called test, even) to make sure everything’s running correctly:

/usr/local/mysql/bin/mysql test

If everything’s running correctly, you should see output similar to this:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version 4.0.24-standard

Type 'help;' or '\h' for help.  Type '\c' to clear the buffer.

mysql>

Once you’ve verified that MySQL is running correctly, use the command quit to return to the console prompt.

Now that MySQL is running, we’ll change the root password of MySQL so that WordPress (and you) can access it later. Use this command (where yourpasswordhere is replaced by your chosen password):

/usr/local/mysql/bin/mysqladmin -u root password yourpasswordhere

The last thing we’ll have to do in MySQL is to create a table for WordPress to store its data. We’ll call it wordpress to keep things simple. To accomplish this, we’ll enter MySQL, create the table, and allow WordPress to edit it.

/usr/local/mysql/bin/mysql -u root -p
CREATE DATABASE wordpress;
quit

Enabling and Testing PHP

Now that MySQL is ready to go, let’s fire up PHP. OS X ships with PHP installed, but not activated. Fortunately, this is really easy to do. The only file we’ll need to edit is httpd.conf, which Apache uses for its configuration.

Open the config file in your favorite editor (I’ll be using pico):

sudo pico /etc/httpd/httpd.conf

Mosey on down to the Dynamic Shared Object (DSO) Support section. It’s the one with all the LoadModule listings. The one for PHP 4 is towards the bottom of that list. Look for the line and uncomment it to activate it. You can uncomment a line by removing the pound symbol (“#”) from the beginning of the line. The new line should look as such:

LoadModule php4_module

We’ll also need to uncomment the PHP 4 entry in the AddModule listings, so that it looks as such:

AddModule mod_php4.c

Once those two lines are edited you can save the httpd.conf file and quit the editor. Since we’ve edited Apache’s load setup, we need to restart Apache so it will recognize the changes:

sudo apachectl graceful

With that out of the way, let’s make sure that PHP is indeed running. Create a new text file in your favorite editor (stay away from RTF-happy TextEdit, though – SubEthaEdit gets my vote) and fill it with the following text:

<?php
phpinfo();
?>

Save the file as test.php in the root directory (/Library/WebServer/Documents/) and load the address of the page (usually http://localhost/test.php) into a Web browser. If PHP was correctly enabled, the phpinfo(); command should output page after page about the PHP installation. If not, retrace your steps – it can be easy to make a mistake.

Configuring WordPress

Now for the last step: configuring WordPress. First, you’ll need to edit WordPress’ default configuration file wp-config-sample.php. You’ll find it in the root folder of the WordPress installation. This is where you’ll set up the database information. Edit the following settings:

define('DB_NAME', 'wordpress'); – Change ‘wordpress‘ to the name of the database you created in MySQL (in the example we named it wordpress).
define('DB_USER', 'username'); – change ‘username‘ to root.
define('DB_PASSWORD', 'password'); – change ‘password‘ to the MySQL password you chose.

Once you’ve made the changes, save the file as wp-config.php in the same directory and delete wp-config-sample.php.

WordPress ConfigurationNow, open a Web browser window and start the WordPress installer, found at http://localhost/blog/wp-admin/install.php. (Remember that if you chose to install WordPress in a different directory, such as the root directory, the address will be different for you.) WordPress will take you through the install process and set up the database with all the tables it needs to run.

After it completes, it will give you the login (admin) and password to log in to WordPress. The password is randomly generated and not recoverable so please write it down!

After you log in, there are two things you need to immediately do. First, change your password to something you can remember. You can find it in the Users tab of WordPress’ controls. Also, to avoid posting entries as “Administrator”, you can either create another account with a posting name, or simply enter a nicknaame in the admin account. But whatever you do, change the password and remember it — once you lose it, your data is hard to get back.

Now comes the moment you’ve been waiting for. Click View site » in WordPress’ controls or open a Web browser and go to http://localhost/blog and watch your blog appear! Roll up your sleeves, perfect the CSS, and wax poetic, serving it to the free world without spending a dime on extra software. Happy blogging!