Mac OS X SIG

I realize now that writing technical articles in a word processor isn't the best way to go, since it's a pain to revisit and edit things later (once you find a mistake, which is invitable). So, I'm taking the original article I wrote and reprocessing it here. (Figuring out how to make a nifty inline box for easier reading of code entries helped out, too.)

This article's a broad-stroke outline on how to integrate Samba 3, OpenLDAP, Kerberos and AFP in Leopard Server, specifically as it would apply here at Stanford. What this gets you:

• Filesharing services to both Macs and Windows clients
• Using the campus' OpenLDAP directory for account provisioning
• Using the main campus Kerberos realm for authentication
• Using Open Directory for delegating share access using ACLs

I want to say that we have WebAuth working on 10.5.2, but it's not. At least not yet.

At issue is the changes undertaken in web services between 10.4 and 10.5. They're quite substantial.

Tiger's web server was Apache 1.3, was 32-bit and either built for PowerPC or, later, to be "universal" to additionally run on Intel processors. Leopard's web server is a whole other beast. The default web server is now Apache 2.2, it's all 64-bit and it's built for four different processor families.

This will pose some challenges.

I've been busy modifying the syslogd.conf file on various servers to additionally send entries to a central syslog server. Getting syslogd to restart properly after modifying the conf file proved to be more problematic than it should be.

You'd think you'd be able to use a kill -HUP, but that's not appropriate here. You'd think you'd be able to issue a launchctl stop command, but that doesn't do it either. If you just kill it, even with a -9 flag, you'll see launchd just happily pops up a new one. That was my case, but the new syslogd wasn't actually logging.

Instead, what worked for me was to issue this command.

SSL certificates are a necessary component for using WebAuth and for serving any web pages using https. ITS provides some guidelines for getting SSL certs, with information on how to procure certs from Stanford's "certificate authority of choice" --essentially the third-party vendor with whom ITS works most often. There's even a nice web form to streamline the process. InstantSSL is fine, but they cost $83 per two-year certificate. This is the best choice if you have sensitive data and need that level of confidence.

But for other occasions, there are alternatives worth considering. You can use a self-signed certificate, but that might just annoy or confuse your users with browser warnings about untrusted certificates (and they don't enjoy a high degree of trust). Or, you can use ipsCA, which is a Spanish certificate authority that offers free two-year SSL certificates to educational institutions. Their root certificate (IPS SERVIDORES) is on just about every computer out there, too, so it works almost every browser. In other words, it's legit.

Here are some simplified instructions on how to implement SSL on your Leopard web server on a SUnet host. We'll start with generating the certificate signing request (CSR).

I needed to get WebAuth working on my Leopard server, but out of the box, there are some issues with building the modules. I want it to work with the included Apache 2.2, so that I and other admins can use Apple's Server Admin tool to configure sites and directories. (Admittedly, I get that tingly, satisfying feeling when third-party tools fit like a puzzle piece in your operating system of choice. Can't discount that motivating incentive.)

But time pressures prevailed, so I had to prioritize a workaround to meet a looming deadline. Personally, "workarounds" almost always gives leave me dissatisfied, but in this case, it's a necessity. Here's how I implemented WebAuth, opting to give up the web server administration utility of Server Admin (which, at the end of the day, isn't too great a loss).

In short, you'll 1) build Apache 2.2 from source, 2) build WebAuth, 3) add the WebAuth Kerberos keytab, 4) add an SSL certificate, 5) hand-configure your conf files to protect your sites and 6) add a launchd file to start it all automatically.

I wrote a simple bash script to help monitor some aspects of Mac OS X Server. You might find it helpful. You'll need to edit it accordingly for your purposes, and of course, there are no guarantees. Feel free to modify it to your purposes and environment.

I tried to make somewhat agnostic regarding hardware (specifically, which NIC reflects the primary IP). And since I use Tivoli Storage Manager to back up some of our hosts, it includes a grep statement to send notices about TSM.

I'm quite certain it can be made more sophisticated, as I'm a scripting newbie, I'll admit. Nevertheless, you can find it at http://stanford.edu/~nbfa/files/daily-report.sh.

On my 10.4 and 10.5 servers, I made a launchd process that runs this script daily. On my 10.3 server, I made a cron job.

If it helps you learn, then all the better. If you repurpose and use it, then rock on. If you have suggestions to make it better, please comment.

I had a client request an anonymous FTP service be configured on their Leopard server. I did this, but had a concern that users with accounts on the server might try to connect. This would be highly undesirable; FTP as we all know, is an insecure protocol. So how to allow anonymous access only, but deny account holders with valid credentials?

This confounded me until it I sorted it out. Once done so, it made sense, but it doesn't help that, in this case, the user interface is unhelpful and unintuitive, and the behavior is different than other configurations for similar machines. (Note: I haven't regressively seen is this is the case pre-Mac OS X Server 10.5.7 Update or pre-Server Admin Tools 10.5.7.)

On this Xserve (Late 2006), Server Monitor.app on the local machine has the LOM feature configured for Network 1 (which corresponds to en0 aka the port labeled Ethernet 1 on the machine and by default the Network preference pane). This LOM interface has its own MAC address distinct from the physical port. I've registered this address for convenience's sake.

To configure this server for monitoring, launch Server Monitor --> Server --> Configure Local Machine. Give it an IP (again, distinct from the physical Ethernet ports), give it a username and password. This is the only step that's the same on this and the Xserve (Early 2008) model.

Like many universities, we use OpenLDAP for our central directory system. As you might guess, the hostname for this system is ldap.stanford.edu. This is actually a DNS pool, though. There are multiple machines offering the same service. There's ldap1.stanford.edu, ldap2.stanford.edu, ldap3 and so on.

When I configure a Mac to use an external directory system, it's usually our OpenLDAP directory. Using Directory Access.app in the Utilities folder (or the command line equivalent, dsconfigldap), I usually enter that hostname, ldap.stanford.edu. However, there are limitations to this.

At some point during configuration, the Mac connects to the DNS pool, gets sorted to one of the physical machines, does a forward name resolution, then uses that numerical IP address for subsequent connections.

Here's the rub: if the IP address of that specific host changes, things break.