Volume Number: 21 (2005)
Issue Number: 7
Column Tag: Programming

Patch Panel

Mac OS X Server 10.4

by John C. Welch

Tiger Server, An Overview, Pt. 1

Well, Mac OS X 10.4 Server, Tiger Server, is finally here! And there are a ton of changes. Enough so that most administrators are going to want to take their time upgrading, because Apple has given us what is the biggest upgrade since Server 10.0 came out. Literally, there is not one part of Server that has not been changed in some fashion.

Welcome

It's not just existing feature changes and bug fixes either. New stuff, stuff you've never seen before in Mac OS X Server without installing a lot of software and doing a lot of work on your own is here. Chat servers, Weblog servers, Software Update Servers, it's all there. This is one upgrade that's going to be worth the money, on pretty much any level you want.

However, like any kind of review, we need to focus on what we're going to cover, so, for the sake of some vague attempt at not turning this into "Tiger and Peace" we'll let the new server administration tools be our guide.

One thing to note here, by "Server" I'm not just restricting this to Xserves. I'm talking about any machine able to run Mac OS X Server 10.4. If I mention an Xserve-only feature, I'll make sure to note it as such.

Server Admin

Server Admin is the heart of the GUI toolset for managing Mac OS X Server, and as such, is the primary tool of the server administrator. Any changes in Server have to be reflected here, and because Server or not, it's still a Mac, the GUI has to work right the first time. Server Admin is not however a client management tool. That's Workgroup Manager, which we'll be looking at a little later on. Server Admin is only here to let you run your Mac OS X server installations. If you think about Server Admin's reach ending at the network interface, you're on the right track.

Server Settings

One new feature in Server Admin, and one that I'm very happy with, is the ability to turn SSH on and off. With earlier versions, you had to use other applications to remotely manage SSH, such as ARD or physically logging into the server. Considering the advantages of using headless servers, (no monitor), being able to remotely control SSH without having SSH on is a necessity, so making it a checkbox is a welcome feature.

The serial number in Mac OS X Server has changed as well. Each copy of server now checks on the network to ensure that you aren't running multiple copies of server with a single copy serial number. It only checks on the local area network, not back to Apple. While this is inconvenient, it's not going to hurt anyone playing by the rules. As well, if you are going to buy multiple copies of server, and want to automatically set them up so that you don't have to manually enter separate serial numbers, Apple will provide serial numbers in that case which don't use this feature, so that someone trying to set up a couple hundred servers via remote install doesn't lose their mind.

Date and Time now contains both the Date and Time settings, along with the Time Zone settings, so they're grouped together in a way that makes a little more sense. This consolidation of settings has been implemented throughout Server Admin, so if you're used to Panther's Server Admin, Tiger's will take a little getting used to, but I've found it to be a much nicer tool once I did.

Two changes in this part of Server Admin are how you manage SSL and access to services. In Panther, SSL management was done in the individual service settings. So, for SSL web services, you had to tell the web service about any certificates, set them up, etc. In the email service, your only option was to use SSL or not. If you wanted to do more with SSL in email, you had to leave Server admin and use the command line. In Tiger, SSL is more properly integrated in with the various services that use it. In Tiger, basic certificate setup is done at the server level, and you then tell the services which certificate you want to use. So you can have multiple certificates set up if need be, and then just select the certificate you wish to use within the service. If you want or need to use a service - specific setup that is different from the certificates you've set up in the main SSL settings, you can do that too.

ACLs

Mac OS X 10.4 Server has changed how you set access to various services, and this revolves around one of the biggest changes in Tiger as an OS, namely Access Control Lists, or ACLs. See Ed Marczak's May Mac In The Shell for more great coverage of ACLs!

With Panther and earlier, permissions were simple. Every file, or folder had one owner, one assigned group, and everyone else. Each file or folder had three options, read, write, or execute. (In Unix, when you list the contents of a folder, you are 'executing' it.) While this is simple, and reasonably universal, it's also very limiting. To change access for various people, you have to start getting complicated with group memberships. Of course, if you get too complicated, then you run into problems, because you can only belong to 16 groups prior to Tiger. (If this sounds like a lot, it really isn't. The first user on an OS X system belongs to two groups by default, their own, and admin. In a university or business environment, you can hit the sixteen-group limit with ease.)

Aside from the group limit, three permissions caused other problems. If you have write access to a file, but not the folder, while you couldn't delete the file, you could open it up and delete every bit of data in the file. Even with other options, like the sticky bit or the chflags command, the traditional Unix permissions scheme became very hard to administer if you needed to use things in a way that they simply weren't designed to handle.

Enter ACLs. ACLs approach permissions differently, and allow for greater flexibility. An ACL is just that; a list that defines who can access a given file or folder, and how. The big advantage to ACLs is that who can access a folder, and what they can do is not as limited. For example, let's say I have a folder and I have three groups of people who need different access to a folder, and the contents of the folder. Under Panther, I'd have to do a lot of workarounds to deal with multiple groups needing different access. With Tiger and ACLs, I can just assign each of the three groups to the folder and files and set their access accordingly. I can set individual user access separately too. I can also specify how inheritance works, too, so that a given ACL can apply to every subfolder a given user or group creates, and all the items that will ever be inside those subfolders, only the immediate children of that folder, or I can kill inheritance entirely.

Write access is now no longer a binary issue with ACLs. I can specify that a user can delete a file, but they can't modify the contents. I can allow a user to administer the permissions on a folder without making them the owner, and without making them an admin. I can have someone who can modify existing files but can't delete them. While smaller entities may not need this level of control, even a company with only a hundred users or so can easily get into some pretty complex rights management issues, and Tiger allows you to manage this outside of any sort of third party software.

Now there are some caveats here. Officially, ACLs are only supported on Mac OS X Server, and you have to use Workgroup Manager to manage them. You can observe ACLs in the Finder, but you can't set or change them. For most, this will work. However, if you want command line access to ACLs, you can use chmod to set ACLs, and fsaclctl to enable or disable ACLs on a given volume. By default, they are enabled for Tiger Server, and disabled in client. While you can enable ACLs in client, if you don't need to, I'd recommend not doing it. You can get very complex permissions structures with ACLs, and you can accidentally open some large holes. It's also going to take a little bit before third party software knows what to do when a user has write access but not delete access. (This comes into play if a file saves by creating an entirely new file, and deleting the old one. With the finer - grained controls of ACLs, it's trivial to break this if you aren't careful.)

A part of ACLs, are the Access Control Entities, or ACEs. An ACE is part of an ACL, and is the actual line in the ACL that specifies what a user or group can do. (The best way to think of it is that an ACL is a list of ACEs, and each ACE lists a single person or group's Access Control setting(s)). The ACE contains 4 items:

1. User/Group: Who the ACE refers to, identified by a 128-bit Universally Unique ID, (UUID) number. UUID's avoid the problem of "Which John are we talking about"

2. Permission Type: Is this ACE allowing or denying a set of permissions

3. Permission: Which of the 13 possible permissions are being used and how

4. Inherited: Is this ACL inherited from its parent, or explicitly set

Explicit ACLs are set manually in Workgroup Manager or via chmod. With the Tiger Server ACL model, there are four kinds of inheritance. "Apply to this folder" means just that. They only apply to the specific folder. "Apply to child folders" means apply these settings to subfolders, but not files. "Apple to child files" means apply these settings to files in the folder, but not subfolders. "Apply to all descendants" means apply these settings to everything. (Note that if you really want "Apply to all descendants to apply to ALL descendants without question, you have to check all of the last three options.) While it may seem silly to have to specifically apply permissions to the current folder, there's some sense. In the case of a school, you can have a master school folder that only administrators have access to, but a series of class(room) folders that have different permissions and inheritance settings. (I said it before, and I'll say it again, be careful with ACLs. There are 98,304 possible combinations of ACL permissions, before you take complex folder hierarchies into account. You can create some really bizarre problems with them if you just slap them on like paint.)

When you use ACLs, you also have to keep in mind that there are rules of precedence for ACLs/ACEs:

1. If an object has no ACEs, then traditional Unix, (or more correctly, POSIX) permissions are used

2. If an object has multiple ACEs, then Tiger Server starts at the first one, and works its way down the list until the requested permission is allowed or denied. It then uses that ACE, along with the POSIX permissions, to determine access

3. Deny permissions overrule Allow permissions. So if someone has allow as part of a group and deny as an individual, the Deny wins. Tiger Server also reorders ACLs so that Deny rules come first. (Did I mention that ACLs can get complicated?)

4. Allow permissions are cumulative, so Allow permissions are the union of all allow permissions, including POSIX permissions.

In addition to local file/folder ACLs, both Apple File Protocol, (AFP) and Server Message Block, (SMB) file sharing protocols support ACLs, and you have to be using HFS+ to use ACLs.

Finally, Tiger's ACLs are compatible with Windows 200X ACLs. While this may not make many in the open source community happy, for anyone working in an Active Directory environment, this is huge, since you can now use your Active Directory tools to manage permissions on Tiger Server Windows share points. As we will see in the Windows section, this creates some really cool capabilities.

However, those are just file system ACLs. With Tiger Server, we also get Service ACLs, or SACLs, set in the Access tab of the main server settings in Server Admin. SACLs allow you to split out access to various services in Tiger Server. So you can, for example, only allow your domain admin groups to physically log into a server and use SSH to that server, but allow anyone to use file sharing via Apple File Protocol, or AFP. While this could be done in Panther, it was a manual process, and tended to complicate things. Tiger greatly simplifies this. Just like with file ACLs, you can add multiple groups or users, however, with SACLs they'll all have the same setting, so there's less of a point in doing this in general.

Figure 1: Service ACLs in Server Admin

AFP Service

With Tiger Server, AFP is now at version 3.2, and includes a few new features such as support for Unicode file names, ACLs, and 64-bit file sizes. The maximum AFP volume size is 2TB, which, while well under a 64-bit size, is still a good size for a volume type that you'll only see over a network. The truth is, AFP is a mature protocol that already supported Kerberos, SSH tunneling, and most of the other features that Mac users need, so there's not much to change in Tiger, and Apple has wisely chosen to leave that which works alone. The one complaint I do have is that you can't force SSH connections, which is a nice option for those with a need for high security.

DHCP Service

DHCP as a protocol hasn't changed much in quite a while, so there's not a lot for Apple to change at the protocol level. From a management point of view, the big "new" feature is the ability to assign static addresses to a specific machine. (While you could do this in Panther, Tiger integrates this into Server Admin.) While static addresses may seem to be at odds with the idea of DHCP, it really isn't. Static addressing allows you to automate router assignment, subnet mask settings, DNS and LDAP settings, but still keep the IP address the same. This can be useful for servers, test machines that you want to always have the same address without having to manually assign the rest, etc. It's also handy for shops running their own DNS without the benefits of Dynamic DNS, aka DDNS. The client is still set to DHCP, they just simply always get the same IP address is all. One thing to note here, if you have a machine that uses multiple interfaces, like Ethernet and AirPort, you'll need an entry for each interface on that machine, since static DHCP uses the Media Access Control (MAC) address to identify the machine, and every network interface has a unique MAC address.

DNS Service

DNS is, in many ways, the most critical service in a Mac OS X network. While the Apple documentation talks about it in polite terms, I'll say this up front: If your DNS is not working correctly, you are going to have nothing but pain with Mac OS X Server. Period. A badly configured DNS will not only cause you problems, but can, and quite often will, reach out and cause problems for people all over the Internet. DNS is a place that you do not ever want to go without a good solid guide, and while Apple's documentation is good for enabling and managing DNS on Apple servers, you really, really, REALLY want to buy and become one with the O'Reilly book on DNS and BIND. It is the "bible" for DNS administration, and no one running their own DNS should be without it.

There, that's out of the way. In Tiger, Apple is using version 9.2.2 of the Berkeley Internet Name Domain, (aka BIND. DNS is the service humans use, BIND is the server that implements those services. BIND is also not a single process, but rather a collection of services, including the name daemon, or named.) While the version of DNS/BIND that Apple uses should normally support Dynamic DNS, (DDNS, that is, DNS names tied to your machine, not your IP address, so even if your address changes due to DHCP, you still have the same DNS name), there's no support for this in Apple's implementation, so if you want to use DDNS on a Mac OS X Server box, you have to install and configure DNS on your own without Server Admin. This is, by the way, a glaring deficiency in Apple's DNS implementation, and something that will make many network administrators choose a different OS base for their DNS services.

The only real change in Server Admin here is the addition of a Secondary Zones tab, which makes setting those up and monitoring them a little easier.

IP Firewall Service

Tiger's firewall has gotten quite a few updates over Panther's, although it is still based on IPFW. One change is semantic in nature, but just enough to make talking to someone remotely a bit confusing is that where Panther called firewall entries "Filters", Tiger calls them "Rules". Same thing, different name, but just enough to drive you insane on a remote support call.

The UI in Server Admin has changed quite a bit though. One change is that Active Rules are no longer shown on the first screen of the Firewall section. Instead, you get basic statistics for the firewall operation. Active Rules now have their own tab.

Setting up the Tiger Firewall is different as well. There is now a "Services" tab, which contains presets for the services that are running or can run on the Server. Address groups now have their own section as well, as opposed to Panther, which combined these two functions in the "General" tab. The Services tab in Tiger has far more entries, including explicit entries for Apple Remote Desktop's (ARD) functions, both 2.x and 1.X, as opposed to Panther, which only has a default entry for ARD 1.2's single port setting. This allows administrators quick access to enabling or disabling various OS X services with ease. One welcome addition is that iTunes Internet Radio streams have their own entry, (Ports 42000-42999 TCP), so allowing local network iTunes sharing but disabling Internet Radio streaming is a snap. A new feature of the Services tab is that you can create, edit, and delete Service entries in the GUI, something that you could not do in Panther. (You can't do it with Tiger's Server Admin tools against a Panther server either.) This allows you to add your own service entries without having to do so in the "Advanced" tab.

The Advanced tab hasn't changed its basic functionality much. It's still the place where you create very specific rules for the firewall. The UI does now show you which rules are locked and not editable in the GUI, a very welcome change from Panther's "surprise" mode for such things. The other changes here are controls for "Stealth Mode". When enabled for TCP, UDP, or both, a computer attempting a connection on a closed port doesn't get a failure message. Instead the packets for that port are dropped, and for all practical intents, you don't exist. This is a nice addition to the security features of Tiger, since if a server isn't seen it's much harder to attack. Even a negative answer is a positive answer if all you care about is the answer's existence, and not the content.

Figure 2: The new Firewall Services tab

One welcome addition is not in Server Admin, but in the documentation for Network Services under Tiger, where Apple gives you step-by-step instructions on how to reset your firewall back to the defaults, in case you did something silly, like kill all external network access to your server. For a new admin, this is something they will need, and having it documented is A Good Thing. Another change that may or may not be welcome is the elimination of the sample command line rules from the IP Firewall Service documentation in the Network Services manual. They're still documented, but are now part of the newer command line reference manual.

FTP Service

Tiger's FTP service is, like FTP, essentially unchanged. The only "new" feature is that the FTP service enforces ACL settings. Other than that, it's what it was in Panther.

iChat

The iChat server is however, completely new to Tiger, and has no analogue at all in Panther, so we don't have to care about any changes. The iChat server in Tiger is not an AIM server, but rather Jabber server. Jabber is, according to the Jabber organization, (at http://www.jabber.org/)...best known as "the Linux of instant messaging" -- an open, secure, ad-free alternative to consumer IM services like AIM, ICQ, MSN, and Yahoo. Jabber is also extensible, so, with a little work, you can use Jabber to talk to pretty much every IM network on the planet.

Setting up the iChat server in Mac OS X is, for basic functionality, ridiculously simple. You set up the Host domain, usually the DNS name of your server, set up a welcome message, and decide if you want to use SSL. If you do, you select the certificate you want to use, save your settings and click the "Start Service" button. That's it, you're now an iChat server. Jabber supports all the basic IM functions, but not every client supports every function the same way.

Out of the box, iChat in Tiger can (obviously) hook up to an iChat Server. As long as you have an account on the iChat Server, you can log into the iChat Server. You just create a new Jabber account to do so. When using Jabber, there are some unique aspects of Jabber to be aware of. First, your Jabber userID looks like an email address, and is shortusername@ichatserverjabberhostname So, if your short user name is jwelch and your iChat server name is jabber.mactech.com, then the Jabber user ID is jwelch@jabber.maccentral.com. Since Jabber doesn't support Kerberos as a standard feature, and there are, as a result, not a lot of Jabber clients that support Kerberos, you can't use the iChat Server in a single-signon environment. What this means is that when you're setting up Jabber clients, whether iChat or not, you're going to have to enter the password into that setup, even though it's the same password you use in Tiger Server's single signon environment.

Figure 3: iChat Server Settings

Another caveat is that if you use iChat, the only version of iChat that supports the iChat server is version 3.0, so if you're using an older version of iChat, you'll have to use a separate Jabber client to talk to the iChat Server. While the iChat Server supports using SSL for security, it's not all encompassing. Only the text conversations are encrypted. Your login session, file transfers, and any audio or video chats are not encrypted. So if you need an extremely high security setting for IM, you're going to have to do that work yourself.

As I said before, not all Jabber clients support ever Jabber configuration the same. So sometimes, even a really neat Jabber client won't work with every feature of iChat's Jabber implementation. For Windows and Linux, the client I found that worked the best with the iChat Server was Psi, (http://psi.affinix.com/). It was easy to set up, and supported file transfers well. PSI's interface is a bit too ICQ-ish for my tastes, but it works well. Psi runs on Mac OS X/Windows/Linux, so if you want a "standard" environment, it's an option. It supports GPG and PGP for file encryption, one way of dealing with the iChat Server's lack of security here. If you want a pretty client for Windows/Linux, Gush, from 2entwine is an option. It doesn't support file transfer, but it's very pretty, which is always nice.

For Palm device users, your best bet is Chatopus, (http://www.chatopus.com/), which supports SSL connections. (I wasn't able to test Chatopus since I don't have a Palm device. However, anyone wishing to send me a Treo 650, feel free to do so, and I'll happily test it for you.)

For Pocket PC/Windows Mobile devices, I found imov, (http://www.movsoftware.com/products/imov/imov.htm) to be a good choice. It works well with iChat server, and in my tests on a Sprint PPC-6600, was easy to set up and use, although file transfer isn't supported. This is probably not a major problem for most PDA/Smartphone users. There are a number of clients for the Blackberry and Symbian devices, but I have no idea about which ones work best. (Although like my Treo offer, if you want to send me a BlackBerry or a Sony p910/Nokia 93XX device, I'll test it for you, no problem)

One thing the iChat Server doesn't do is automatically log the contents of IM conversations. This can be an issue for companies in this day and age of Sarbanes-Oxley and other regulations. The only way I could find to do this is a third party plugin, Bandersnatch, from Funky Penguin, (http://www.funkypenguin.co.za/tiki-view_articles.php). It's not a dead simple setup, but if you have the need, and some basic MySQL skills, then it can log all iChat Server conversations. (This is one of those things that can be used for good or evil, but there are cases where it's necessary, and in that case, you either use it, or don't use iChat Server.)

Mail Service

While not new in Tiger, the Mail Service has been the recipient of a number of changes, fixes and new features at almost every level. Two critical new features are the integration of SpamAssassin and ClamAV for anti-spam and virus detection. While there are still no native Mac OS X viruses, and less than a handful of trojans, when you run an email server, you don't know what platform is going to be connecting, so it's better to have extra protection than not enough. Virtual Hosts are now supported in Server Admin, so you aren't forced to the command line for this. This is something of no small importance to ISPs. Sieve scripting, for creating server-side mail rules is supported in Tiger, and even documented. While you could implement Sieve in Panther, you had to do it from third - party documentation. Server rules are an important part of enterprise mail services, so it was important that Apple do more for things like Sieve.

For administrators with large email setups, you can now split mail stores across multiple partitions or even remote filesystems mounted locally on the server, so that a single hard drive incident doesn't cause a loss of service for your users, or so you can load - balance the storage duties of user email. Tiger's mail service also supports the new Service ACLs, so you can have better control over who has access to the email service on any given server. This can create some confusion as to what a given user can really do when you have separate user account settings in Workgroup Manager for mail access. The simple rule of thumb is, if a user has email service enabled either in Workgroup Manager or in the Mail SACL in Server Admin, then they have access to Tiger Server's Email service. If you want to make sure a user doesn't have access, then they have to be denied access in both locations.

With Tiger, you now have two options for email aliases. You can either use Workgroup Manager's ability to create login aliases and use those for email aliases too, or create them manually in /etc/postfix/aliases. The biggest difference between the two is that aliases created in Workgroup Manager won't work with Sieve scripts. Yet Another New Tiger Email Feature is that you can now manage mail quota handling in Server Admin.

Postfix, Cyrus, and SquirrelMail are still used for SMTP, POP/IMAP, and Webmail respectively, so there's no changes to the root servers that make up the email service beyond version numbers.

The Mail service module in Server Admin has been redesigned up and down to give Mail administrators more power outside of the Command line. Along with this greater power, the Mail service documentation has been extensively revamped and rewritten so that mail administrators can get a lot more use from Reading The Fine Manual. The mailing list section alone goes into more detail in its first section than Panther's documentation did for the entire mailing list entry, including solid information on what you use the web interface for as opposed to Server Admin, a welcome change and an important improvement to Tiger Server.

As I've been noting, Server Admin's Mail Service module has been extensively revamped, to give the GUI the kind of power that an email admin needs. Outside of new settings, there's a "Maintenance" panel, that allows you to handle basic mail, well, maintenance functions. So things like the mail database repair function can be run from Server Admin with a click. The Database tab here also allows you to view basic information on all the mail stores a server is using, (important, since Tiger lets you have multiple mail stores in multiple locations). Mail Queue management is another feature of Tiger, allowing you to view the current mail queues and either delete or retry messages that are having problems. The Migration Tab allows you to import any Mac OS X Server 10.1 or 10.2 mail databases from Server admin, giving you the option of migrating selected users or every user.

Figure 4: Mail Database Maintenance tab

The Settings panel has a metric ton of new capabilities, all aimed at making the GUI more useful. In the General tab, you can now set the mail server to deliver to /var/mail when you turn off POP and IMAP services. This can be useful if you need to receive mail without delivering it, and not cause email to bounce. The controls for enabling SMTP are also where you specify the domain and host names for the email server. Along with enabling SMTP/POP/IMAP, you can now separately start or stop incoming and outgoing mail here. This is a real convenience for everything from troubleshooting to dealing with network congestion problems.

The Relay tab is new, and has the functions of the "Filters" tab in Panther's Server Admin. With the separate anti-spam and anti-virus capabilities of Tiger, and the fact that the settings in this tab are more focused on relaying settings, adding this tab just makes for a more logical and more intuitive UI for administrators.

The Filters tab is now where you control your anti-spam and anti-virus settings. SpamAssassin's junk mail score setting, accepted languages, locations, what to do with junkmail, how to handle it if you forward it are all here. The Virus settings are pretty simple: Turn AV on/off, what to do with infected email, and who to notify of infected email. You can also set the frequency of daily updates to your anti-spam and anti-virus databases here. Once a day is probably the slowest you'd ever want to set this.

Figure 5: Mail Filters tab

The Quotas tab is a new feature in Tiger, and works with the Quota settings in Workgroup Manager. This is where you set things like maximum incoming message size, and how to handle users near quota or over quota.

The Mailing List tab is unchanged, an island of familiarity in the newness of Tiger's admin tools. The Logging tab adds detail level settings for the Junk Mail and AV features, along with finer control of the logging levels for SMTP logs and POP/IMAP logs.

The Advanced tab is now split into three sections. The security section is where you set your authentication methods for SMTP/POP/IMAP, and your SSL usage for SMTP and POP/IMAP. SSL usage now allows you to specify the certificate used, instead of just the Use/Don't Use/Require settings in Panther. The Hosting section is where the Virtual Domains and Virtual Host settings are contained. Finally, the Database section is where you specify the mail database location, the main mail store location, and the location of any additional mail stores.

Keep in mind that any command line options you used in Panther are still there. None of the GUI improvements are coming at the expense of the UI. You just now have a better GUI to use along with the command line if you want.

NAT Service

Like FTP and AFP, Network Address Translation hasn't changed much in concept or practice in a while. Server Admin in Tiger adds the convenience of being able to set the NAT service to just act as an IP Forwarder, or to perform IP Forwarding and NAT.

NetBoot Service

While Tiger doesn't do anything radical to NetBoot/Netinstall, there are some small, yet welcome changes. The number of AFP connections has been increased to whatever the resources on your server limit it to, nice for those administrators with high-powered setups. Network install images can now be created as block - copy images instead of file - copy images, which result in much faster installation speeds. The previous command-line only option for setting up images on remote servers is now a part of the GUI tools. Images can now be created with Directory Services settings configured in the image, so that as soon as the machine boots, it's configured correctly without needing to use the DHCP LDAP settings. (You could do this in Panther, but you had to copy /Library/Preferences/DirectoryServices/ from the machine you were creating the image from to the image. In Tiger, this is integrated into the toolset.)

Since so much of NetBoot/NetInstall revolves around image creation, we should start with a look at the new features in the System Image Utility, formerly the Network Image Utility. One thing administrators will notice right off is what's missing: Information on creating Mac OS 9 boot images. Considering how dead OS 9 is to Apple, along with the fact that Intel - based Macs can't run Classic, much less boot OS 9, this is no surprise, but it means that if you still need to create new OS 9 install images, you should consider keeping a machine running Panther Server around.

The basic functions of the System Image Utility haven't changed, but the implementation has been expanded somewhat. You can now explicitly assign the protocol to use to serve the image, although NFS is the preferred method still. You can, as I said earlier set up a machine as an image server and let NetBoot serve from there. You have to create the image locally, and manually copy it to the specified location, but once it's there, you can serve it from there. While this would seem to make it an ideal candidate for an Xsan and a few front end Xserves, that's not the type of use an Xsan's optimized for. That's not to say you physically cannot do it, but you would really want to test this out first before buying the gear. A new option for install images is the "Change ByHost preferences to match client after install" feature, which allows administrators to create ByHost preferences, (preferences tied to the Media Access Control, or MAC number of the main network interface card.) This takes the ByHost of the image source, and when pushed down to the client, will change the preference to match the client. Considering that preferences like screensaver settings, iTunes settings, .Mac and Classic settings, et al use ByHost, this saves a lot of work on the back end of the install for administrators.

One new trick that rates high on my "cool list" is the Model Filter setting for both install and boot images. This allows you to tie an image to specific models of Mac. This is very important in situations where you have different images for portables versus desktops. This avoids someone accidentally or deliberately installing the wrong image on a type of hardware that you don't want it installed on.

Figure 6: System Image Utility Model Filter tab

Another problem that Tiger makes easier to solve is naming imaged machines. If you have to image a dozen or so machines, giving them all unique sharing names can be tedious. Tiger's System Image Utility gives you two options right in the UI for doing this. If you want them all to have the same name, with the MAC address grafted on then you just enter that name (sans MAC address) in the "Computer Name" field in the "Sharing Prefs" tab for boot or install images. If you leave it blank, then they either get -AUTOMATIC- or DNS names from the network based on their IP address. You can also create a tab-delimited text file that has the desired name for each machine and the corresponding MAC address, and tell the System Image utility where the file is in the "File Path" field. When you image the machines, if they have a MAC address that's on the list, they get the name you give them. If they don't have an address in the list, then they get the name from the setting in "Computer Name".

Once you've created the image, then you can use some of the new tricks in the NetBoot service to make managing them easier. One thing administrators love is information on our servers. We love knowing all the details, and we hate having to spend a lot of time sussing them out. Server Admin in Tiger does that for NetBoot far better than Panther did. The first screen in the NetBoot service tells you which images are enabled, and if the necessary protocols are running for each type of image, (AFP/NFS/HTTP/DHCP).

Monitoring NetBoot clients is easier with Tiger too, as you get, in addition to all the info that Panther provided, information like the System Type of the client, handy if you have a couple thousand machines and haven't yet memorized every detail of every system.

The settings haven't changed much. You can set the maximum number of AFP connections, you can have Server Admin look up MAC addresses for you based on the client's IP address or DNS name, and you can set the logging level.

NFS Service

Tiger's NFS service is generally unchanged from Panther's. If you want to do more than turn it on/off, select the number of daemons, and the connection type, you're going to need to use the command line and become one with the various NFS books.

Open Directory Service

There are many, many changes in Open Directory, especially in the areas of Windows integration, and they are both welcome, and needed. Open Directory is literally the heart of Mac OS X Server. Every service, every feature at some point deals with Open Directory, so improvements here ripple out into every other part of Tiger Server. However, it's important to remember that Open Directory, (OD) isn't just one thing. It's not like Microsoft's Active Directory, which is a single, albeit, complex product. Open Directory is more of a collection of technologies, integrated so that they all work together for Mac administrators. By default, Open Directory is primarily OpenLDAP on a BerkeleyDB datastore, with a MIT Kerberos Domain Controller for primary authentication and Single-Signon.

But OD is not just that. In fact, it's really nothing more than a container. LDAPv3, NetInfo, Active Directory, NIS, etc. are all just plugins to OD. Apple provides a base set of plugins with Tiger, including: Active Directory, AppleTalk, Bonjour (nee Rendezvous), BSD Flat Files & NIS, LDAPv3, NetInfo, SLP, and SMB/CIFS. You can also get a number of third party plugins that add features, like direct support for Novell's eDirectory, or provide additional features for things like Active Directory that Apple's plugins don't give you.

With Tiger Server, Apple has further refined Open Directory so that it provides not just improved features, but better security as well. Improvements include things like Trusted LDAPv3 binding, where not only does your system have to authenticate to the server, the server has to prove it's the right server to your system. This is a critical feature, one that makes using directory services a much more secure proposition. With this, and the various features in Mac OS X 10.4 Server, such as Kerberos signing and SSL encryption of Open Directory server communications to the client, doing things like creating a bogus Open Directory Master is effectively impossible, since the server will be unable to authenticate itself to the client. (If the only authentication is client to server, then creating a bogus server that can root your clients is much simpler. It's not child's play, but it gets a lot easier.) Now, if you implement Trusted binding, then you can't use the DHCP discovery of Open Directory Masters, but until there's a standard for trusted DHCP, that option isn't a great idea anyway. The only reason to use the DHCP Option 95 LDAP server discovery was so that you didn't have to set up directory bindings on each client. However, since the new NetBoot/Netinstall features in Mac OS X 10.4 take care of this, that's no longer as much of an issue.

Active Directory integration is much better, thanks not only to ACLs, but also to support for using AD info for home directories, and better directory information mapping between OD and Active Directory. Along with that, many of the options for Active Directory that were formerly only accessible via the dsconfigad command line tool are now in the UI. Binding a Tiger Server to an Active Directory realm is far simpler, and finally gives you the benefits that it should have in Panther. You can store the LDAP scheme in the directory for convenience, and improved replication.

Looking at the new Directory Access application, in /Applications/Utilities/ there's some obvious changes, mainly the renaming of "Rendezvous" to "Bonjour", which keeps Tibco off of Apple's back, and still keeps the company's Francophilism firmly intact. (Personally, I thought Achtung! would have been better, but only if Apple also bought the rights to "Hogan's Heros")

The Active Directory plugin, now at version 1.5, as I said earlier, has had a GUI revamp. Options that were previously only settable or readable from the command line are now in the GUI, such as the mount style for network home locations and whether to force local home directories. New options allow you to set the default shell for a user, more fine-grained control over attribute mapping, using the UNC path in Active Directory settings for a user to set the network home directory location, and a much nicer UI for entering in Active Directory administrative groups. AppleTalk is still the same, and like before, only controls your ability to browse via Appletalk protocols. (AFP file transfer in Mac OS X 10.4 should be assumed to be AFP over TCP/IP only.)

Figure 7: Directory Access Active Directory Settings

The BSD Flat File and NIS plugin has received only minor adjustments, but as that is clearly a legacy technology to Apple, this isn't surprising.

Bonjour/nee Rendezvous Service Discovery is now permanently on in Directory Access. If you want to disable that, you can't do it from the GUI. Note that this is not enabling/disabling all the Zeroconf technologies that Bonjour encompasses, just the ability to find other Bonjour services.

Given all the changes in Mac OS X 10.4 Server's Open Directory infrastructure, one would expect that the GUI for LDAPv3 in Mac OS X 10.4 to have radically changed. But it hasn't, instead getting some minimal changes to improve usability and account for new features. Setting up an LDAP server is more automated, and the UI for options is clearer. For example the initial screen when you add a new server lets you set up SSL, authentication and contact options right away. The manual options have new features as well.

Figure 8: Adding an LDAP server to Directory Access

The Connection tab now lets you set rebind attempt periods and idle timeouts, and gives you the option to ignore server referrals, (Server referrals are where the LDAP server you connect to can tell you to look on other LDAP servers for different information. If you have a lot of referrals or a wonky network, this can greatly increase your login time.) or use LDAPv2 in read only mode.

The Search & Mappings tab adds the ability to save custom mappings out as a template so you can get to them easier next time you need to.

The Security tab is new to Mac OS X 10.4, and incorporates the "Use authentication when connecting" option in Panther's Connection tab, but adds in the new options for the trusted binding options. Within the new Security Policy options, you can avoid rogue LDAP servers compromising your network. The new options are:

• Disable clear text passwords: This one's obvious. It means that you can't use unencrypted passwords to communicate with the LDAP server. From a security POV, this one should be a default.
  
• Digitally sign all packets (requires Kerberos): If you are using a wide area LDAP implementation, this option is critical. It allows you to ensure that the packet you get is the packet that was sent, unmodified and unmolested. If the packet is changed enroute, then the digital signature will be wrong, and the packet won't be accepted. This option requires that you use Kerberos.
  
• Encrypt all packets (requires SSL or Kerberos): Again, fairly obvious, and goes along with disabling clear text passwords. This ensures that all data between client and directory server is encrypted.
  
• Block man-in-the-middle attacks (requires Kerberos): This option works with the digital signing option to prevent someone from setting up a rogue server posing as an LDAP domain controller.

Note that you can override any of these options at the server level, which is always a good idea on a managed network.

Figure 9: Directory Access LDAP options

I know that some of you are thinking "Well, I've got a really good firewall, why should I worry?" Firewalls aren't magic. For example, do you require every machine on your network to meet a specific security profile before it can use your network? If so, how do you force that? You can do this with Windows, but Mac OS X support for this kind of thing is still as yet unimplemented. A single badly configured machine inside the firewall can leave you open to attack. Firewalls also don't do much about disgruntled/paid off employees. This is not to say that firewalls are not good, useful things, but that they are only a part of a good security policy. Avoiding unencrypted, unsigned data transmissions wherever possible only enhances your security, and gives you additional layers of protection.

Server Admin has new features to make a Mac administrator smile as well. The Log tab in Server Admin's Open Directory settings in Mac OS X 10.4 Server adds in the kadmin & kdc kerberos logs, a Password Service Replication log, and slapconfig log. This helps answer one of the most frustrating things about Mac OS X 10.3 Server. Logs are the best way an administrator has to troubleshoot problems on their network. The fact that Mac OS X 10.3 didn't log Kerberos - specific events by default was one of the most frustrating things about that version. Kerberos troubleshooting can be extremely tricky on a good day, and no logs are not the way to a good day by any definition. There's also a search/spotlight window built into the Log tab, (indeed, it's in all the Log tabs in Server Admin), which allows you to filter a log for specific conditions. Another new, and very welcome application - wide change in Server Admin is the inclusion of the path to the log you're viewing, so if you want to look at a log outside of Server Admin, finding the specific log file is much simpler.

The Archive tab is a new Mac OS X 10.4 feature for Server Admin. It allows you to quickly back up and restore Open Directory Master settings, including:

• LDAP directory database and configuration files
• Open Directory Password Server database
• Kerberos database and configuration files
• Local NetInfo domain and shadow password database

This is designed as a supplement to using a proper Open Directory replica setup, or in cases where replicas are not possible or practical.

The Settings tab has gained new capabilities, particularly with regard to security and joining other directory systems. In my tests, joining a Windows 2000 Active Directory realm was a three or four - click process in Server Admin, and about 3 minutes in Directory Access and you were done. Once you've finished that, it just works, no fuss, no muss, with far less pain than Mac OS X 10.3, and thanks to new Windows features and ACLs, you get a much nicer level of integration than ever before. The "Authentication" pane in Settings is now "Policy, and has three sections. The "Policy" section is much the same as it was in Mac OS X 10.3. The binding settings are about the same as in Directory Access, however they will override client Directory Access settings. You can also disallow binding if need be. Finally, the "Security" pane allows you to set various security methods. Before you go shutting things off or turning things on here, you'll want to be very careful to make sure that you aren't accidentally killing access for clients that can't use the settings you want. A network that can't be used may be secure, but it's also useless.

Figure 10: Open Directory Server Policy Settings

One final note: Apple has released a new Open Directory manual that clocks in at over 242 pages. Even if you have been running Open Directory for a while now, read it, take notes, annotate the PDF. A couple days of planning in this manual, and the other manuals available on the Mac OS X 10.4 Server Documentation page can save you months of pain down the line. I also highly urge you, if possible, to take Apple's server classes, which should already be updated for Mac OS X 10.4. They aren't cheap, but the time you save will more than make up for the cost of the class within months, which is not a bad ROI at all.

Print Service

Considering that Mac OS X 10.3 Server's print service was, to be kind, suboptimal, almost any improvement in Mac OS X 10.4 is welcome. The big news is that instead of ignoring CUPS, (version 1.1.23 in Mac OS X 10.4 Server, from Mac OS X 10.3 Server's 1.1.20) at all but the lowest levels, ala Mac OS X 10.3, Mac OS X 10.4 Server is integrated with CUPs pretty much from to to bottom. This pays off in a number of ways, such as sharing via IPP and better logging, (the CUPS logs are actually useful now). You can set cover sheets in Server Admin, (although custom cover sheets still require some work in CUPS, to create custom sheets and get them in the right spot.).

Another bonus to having the print service better integrated with CUPS is that it makes it easier to use CUPS for the settings that Server Admin or the Apple command line tools don't handle. So, if you want to go beyond what Server Admin gives you, or you want to use different CUPS features, it's a much nicer time to do so.

There's still a couple of annoyances here, such as the only support for authenticated printing in Server Admin is still only via SMB. You can do authenticated printing with CUPS and IPP, but it should be in the Server Admin UI too. Adding shared printers and queues to Open Directory is still a manual operation, which is puzzling. Using Open Directory to manage printers is something that should be automatic. The printer entries should be created as you set them up in Server Admin. Open Directory Printers have to be LPR queues, another annoyance. Bonjour printing is LPR only, however, finding IPP printers shared by Mac OS X 10.4 Server from a Mac OS X 10.4 client is pretty braindead, (They show up in the Printer Browser that comes up when you click "Add" in Printer Setup Utility with a connection type of "Shared Printer"), so it's not as big of an annoyance as it could be. While you can't auto-download Windows client print drivers by default, setting this up is pretty straightforward (and I go over it in the Windows Services section), so Mac OS X 10.4 is a much nicer Windows client print server too. The UI in Server Admin hasn't changed noticeably, other than the aforementioned Cover Sheet and IPP additions. Most of the changes here are under the surface.

QuickTime Streaming Service

While there are a ton of changes in QuickTime itself, hence QuickTime 7, the QuickTime Streaming Server tools having changed as much from Mac OS X 10.3. The biggest changes are to reflect new features in QuickTime, such as H.264, HD Streaming and 3GPP features. The Server Admin UI is about the same as in Mac OS X 10.3, as is the QuickTime Streaming Server Web UI.

QTSS Publisher has had some work done on its UI, mostly to support ease of use and user home directory streaming. There is one big change, and it is not only welcome, but fits the workflow of QTSS Publisher perfectly: AppleScript. QTSS Publisher joins Server Admin and the Gateway Setup Assistant as the only server administration applications from Apple with AppleScript implementations, and QTSS Publisher's is by far the best thought-out and most useful. This is a refreshing change from the first generation AppleScript dictionaries seen of late from Apple, (I'm thinking of Keynote and GarageBand in particular), which are mostly read - only, and of not a great amount of real use. The QTSS Publisher dictionary is full-featured and looks to have been created by folks who not only know what AppleScript can do, but have used AppleScript themselves. The terms are explained, and looking at the object model in Script Debugger's browser, it looks clean and neat. Good job folks!

Figure 11: QTSS Publisher AppleScript Dictionary

Software Update Service

The first thing that must be said about the new Software Update service is best quoted from the Mac OS X 10.4 Server documentation:

Note: You can't use Software Update service to provide third-party software updates.

The second thing that must be said about Software Update service, also from the Software Update service documentation:

You can't make your own Software Update packages. For security considerations and to protect attackers from faking packages, the Software Update package installer won't install a package unless it's signed by Apple. In addition, Software Update service will work only with the new package format supported in Mac OS X Server v10.4 or later.

The right or wrong of these items is best left to debate elsewhere, but as of Mac OS X 10.4.0, Software Update service is only for Apple Software Updates, and only for software updates using the new Mac OS X 10.4 package format created by and signed by Apple.

When you connect to Apple's main update servers with your own Software Update service server, Apple does collect the following data from your server:

• Language
• Type
• Browser

So Apple's not doing any deep, evil data mining on your Software Update service server. Having said that, Software Update service is not useless by a long shot. If you have 100 machines, or even ten machines, a way to ensure that your clients only get the updates you approve and don't all have to go out on the Internet to get them is A Good Thing. Yes, you can do this with Apple Remote Desktop, but that's a manual process, and doesn't allow you to assign Software Update service servers to specific clients. It also allows you to better compensate for revoked updates, that Apple may pull for a variety of reasons, since those packages are not presented to users. So, while Software Update service isn't everything, it's better than nothing.

Clients must be running Mac OS X 10.4, which is a bit of annoyance for system administrators who were hoping to use this without having to upgrade their clients to Mac OS X 10.4. As well, you'll want to think about capacity planning well, since pushing out a 50MB update to 500 clients on a 100MB line will make your network cry. If you have a large number of clients, you'll want to consider multiple Software Update service servers, and use Workgroup Manager to assign groups of clients to specific servers.

Looking at Software Update service in Server Admin, you have the Overview Tab, which allows you to see the current status of Software Update service, such as last check, the number of updates that are Mirroredor copied and stored locally for clients, and the number of updates that are Enabled, or made available to clients. You also get the status of the Auto-Mirror and Auto-Enable functions.The Log tab shows you the current contents of the Software Update service log.

The Settings tab has two parts. The first part, "General" allows you to enable or disable automatic mirroring and automatic enabling. Note that the auto-enable is a binary setting. It's on or off, there's no "only on for some updates". You can limit bandwidth between the Software Update service server and client Macs, and you specify the port you're going to provide the updates on here as well. The "Updates" tab shows you the updates you are currently mirroring and their status.

I will agree that Software Update service is not a complete, full solution for Enterprise IT needs by a long shot, but it can help you manage Apple updates a lot better than was previously possible. That's a win, even if it isn't everything it should be.

VPN Service

This has not changed by huge amounts from Mac OS X 10.3 Server. In Mac OS X 10.4's Server Admin, there are new options for LT2P, such as being able to user MS-CHAPv2 or Kerberos Authentication, and you set the IPSec authentication options for L2TP to either shared secret or SSL Certificates. PPTP is unchanged in Server Admin. Logging and Client Information options remain unchanged from Mac OS X 10.3 Server.

Web Service

Unsurprisingly, the web services in Mac OS X 10.4 Server have their share of updates, the most obvious one being the new Weblog functionality, based on Blojsom, the java - based weblog software. The weblog service gives you fire and forget weblog setup, however, if you're looking for something that gives you point & click functionality on a par with a standard Blojsom install, or MovableType, you'll not be terribly happy with Mac OS X 10.4's implementation. But, if you're looking for a weblog that would be good for smaller children, or you want a simple, basic weblog, then Mac OS X 10.4's weblog is great for that. One thing that is important to note if you plan on hosting multiple sites from a single server: If you turn on weblogs, they're on for every site on your server so be careful there. Finally, using the Weblog service with clients like ecto is far more tedious to set up than it should be.

Figure 12: Weblog Settings

There are new authentication options for Apache, most notably Kerberos via Microsoft's SPNEGO protocol. So you can now user Kerberos authentication for not just web pages, but for realms as well. SSL support in Mac OS X 10.4 Server supports SSLv2, SSLv3, and TLSv1, although not every other application is guaranteed to support these versions. The primary version of Apache in Server is at 1.3.33. Apache 2 is provided for testing, in /opt/apache2/. Like every other service on Mac OS X 10.4 Server, Web Services support SACLS.

As we noted earlier, SSL certificate handling is better at all levels, including web services. The way that Apple has made using SSL in the various services in Mac OS X 10.4 Server will make the use of more secure websites much more prevalent.

The performance cache is still in Mac OS X 10.4 Server, but has changed its behavior somewhat, in that you no longer have to keep port 16080 open, since Apache in Mac OS X 10.4 Server handles the performance cache a little more gracefully. If you need to use SSL or Keep-Alive, you can't use the performance cache, and any request containing cookie headers will not have its responses cached. You'll also want to disable the cache for any sites with WebDAV enabled; as it can conflict with uploads.

You can set up search pages in Mac OS X 10.4 Server that can talk to Spotlight. While Spotlight is disabled by default on Server, you can turn it on by changing the Spotlight line in /etc/hostconfig from SPOTLIGHT=-NO- to SPOTLIGHT=-YES-, then start the Spotlight metadata process with sudo SystemStarter start "MetaData Search", or restart the Server. From there, you have to set up the searches for the site/pages, but this is all explained in the Web Technologies Admin Guide from Apple.

WebMail in Mac OS X 10.4 Server is still SquirrelMail, version 1.4.1.

Server Admin hasn't changed much with Mac OS X 10.4 Server, mostly just to handle some of the new features. The "General" area in the Settings now has controls for Allow Persistent Connections, so you can set the number of persistent connections and their timeouts. The "Weblogs" area has all the settings for the Weblog service, which consist of: Enable/Disable Weblogs, set the Default Theme, set the Weblog folder, and the Email domain for emails generated by the Weblog(s). Like I said, it's there, and it's easy. Sophisticated it ain't.

The "Sites" area has had the most changes overall. The Options pane now has a specific Server-Side Include (SSI) setting, and the order has changed. As I said earlier, realms can now use Kerberos authentication, which also requires SSL, and this is in Realms pane. The Security pane has changed to reflect the new SSL integration, like everything else in Server Admin. Finally, the Aliases pane now has different settings for Web Server aliases vs. URL Aliases and Redirects.

WebObjects Service

The WebObjects service is new in Mac OS X 10.4 Server, although WebObjects is hardly new to Mac OS X. Since all this service does is control the WebObjects application server, there's not much to do with it in Server Admin, nor would there be, since WebObjects is more the realm of Xcode. You can get an overview of what's going on with WebObjects if it's running, and you can set the ports that the WebObjects Monitor, and the wotaskd process run on. You can also enable/disable the monitor.

Windows Service

In a stunning surprise, nothing has changed for Windows services...no, I'm lying, but I'm also running out of ways to say "There's been a lot of changes to . But, once again, there's a lot of new features in the Windows Services in Mac OS X 10.4, and they're stuff that I missed dearly in Mac OS X 10.3.

For sysadmins who aren't using Active Directory, but want to migrate their domains off of Windows NT 4, Mac OS X 10.4 Server supports Backup Domain Controller, (BDC) functionality along with the Primary Domain Controller, (PDC) functions in Mac OS X 10.3 Server. This requires you, (somewhat obviously) to set up the PDC Mac as an Open Directory Master, and the BDC Mac(s) as Open Directory Replicas. All the information is then stored in Open Directory's LDAP store. One thing to note here, since this is for NT4 domains, not Active Directory realms, you have to deal with NetBIOS name restrictions for your network. Machine names should be no more than 15 characters, no special characters or punctuation. This is also a good policy for SMB shares in an NT4 domain.

Mac OS X 10.4 Server is now able to be an Active Directory member server with greater ease and better reliability than before. As I mentioned in the Open Directory section, the setup for this is much simpler and more reliable than in Mac OS X 10.3 Server, and thanks to the ACL support in Mac OS X 10.4 Server, dealing with permissions is far simpler. Thanks to Apple using Windows - compatible semantics in Mac OS X 10.4 Server, you can change ACLs from a Windows box, a plus for people managing AD networks with Macs. Thanks to ACLs, you can finally have nested Windows or Mac groups with access to a share or service, and not run into Unix permissions problems, or the 16 - group limit that Unix permissions forced on you. As with the other services in Mac OS X 10.4 Server, you can also use SACLs to restrict access to the service itself.

Mac OS X 10.4 Server's file locking is improved, so if you enable strict locking for any SMB shares, you should be able to avoid some of the file locking issues that were a problem in Mac OS X 10.3 Server when you had people hitting the same file with different protocols. While Mac OS X 10.4 Server does support oplocks for SMB shares, you should only use those if Windows clients are the only machines that will be using that share.

On the authentication side, Mac OS X 10.4 Server now supports NTLMv2 and Kerberos for Windows clients. It also supports using Kerberos for Macs accessing other Windows shares, so Mac OS X 10.4 users get Single-Signon for SMB too. As we'll see, you can force NTLMv2 and Kerberos authentication for clients connecting to Mac OS X 10.4 Server, but you should be careful of doing that if you have older Windows boxes, since you have to be running Windows 98 or greater to use NTLMv2 & Kerberos.

Figure 13: Windows Access Settings

One benefit to all of this is that using Mac OS X 10.4 Server to host roaming profiles, the Windows version of Mac OS X 10.4 Server's mobile home directories is much easier than it was in Mac OS X 10.3 Server. One caveat with roaming profiles: If you're going to use them for Windows clients, you have to be rather hard-nosed about profile size quotas. With Windows, a Roaming Profile downloads to the client on login, and uploads from the client at logout. If you have a large profile size, (mine is about a GB and a half or so), login and logout on anything but a very fast network can take a long, long, long, time. Enough to where people will think something crashed. Watch your sizes on roaming profiles.

As before with Mac OS X 10.3 Server, Mac OS X 10.4 Server is able to act as a print server for Windows boxes, and can even provide automatic driver download for Windows clients, so they don't have to worry about installing drivers when printing to a Mac OS X 10.4 Server print queue. While the basic documentation is available on the Samba site, as it turns out, doing this in Mac OS X 10.4 Server is a good deal simpler than the Samba howtos show:

1. Add the printer you want shared to Mac OS X Server via Printer Setup Utility

2. Share it out in Server Admin via IPP and SMB (Win2000 and later can use IPP too, but SMB is much easier to use here for a number of reasons. IPP is just better for your Mac clients, but if you won't have any needing to get to this printer, then you can just use SMB)

3. In Workgroup Manager, (WGM) create a share with an SMB name of print$. It must have that exact name as the share name in WGM for SMB sharing, as this is hardcoded into Windows 2000/XP for this function. Make sure you set up the proper ACLs for it, at least giving Domain and Enterprise Admins full control. This is one case where you really want to be one with ACLs, it will make life much easier for windows users and administrators.

4. Create the following subdirectories in print$ in WGM
a. W32X86 for NT/2000/XP
b. WIN40 for 9X/ME (Note: The procedure I'm detailing only works for Windows NT/2000/XP clients. You can set it up for 9X clients, but it's much more tedious, and those machines are a bigger hindrance than a help anyway)

From a Windows 2000/XP machine, navigate to the "Printers and Faxes" share on the Mac server, and select "Properties" on the printer you want
a. When asked to install the driver select "No"
b. In the Advanced tab, click "New Driver..."
c. Run the Add Printer Driver Wizard (note, if run from an XP machine, this only installs drivers for NT/2000/XP, NOT 9X)
d. The drivers actually install into the "3" subdirectory in the W32X86 directory (There's a long explanation of why, has to do with earlier versions of NT print drivers living in the kernel. In Windows 2000 and later they aren't. This is all handled automatically for you. )
e. Configure the standard settings on the printer. Note that device settings will be pre-set this way, but not print job settings, even though you can set them here.

6. Add the printers to the clients either via the printer wizard, or just connecting to them in "Network Places".

That should do it. You can also publish OS X Server's printers in Active Directory via the Active Directory tools, a good idea, since it allows you to just search AD for them. (AD's printer search is pretty weak, but that's MS's problem) One reason why I recommend ACLs here is that they're a better way to lock down access to a printer, and you can do this from AD tools, which are still a lot nicer to deal with than OD tools. As with computer and share names, watch the 15 - character limit for print share names.

As far as Server Admin goes, there aren't a lot changes. The Overview tab no longer shows you the logging status. In the Settings tab, the "General" panel adds an option to set up your server as a BDC, and shows you the name of the Active Directory realm if you're joined to one. The "Settings" pane now has a selector for Authentication options: NTLMv2 & Kerberos, NTLM, and LAN Manager. You can select these in any combination you need.

Xgrid Service

Xgrid is Apple's implementation of Grid Computing. Grid computing is a lot of things to a lot of people, but at it's heart, it's just a way to split a task or group of tasks up between multiple computers. Xgrid is not, however, a magic "Make it faster" spell. The job has to be designed for multiple computers to work on. 3-D Rendering, ala Pixar is an example of a job type that can benefit from Xgrid. Burning a DVD is an example of a job type that won't benefit from Xgrid. Grid computing is very big in the scientific community, where jobs are easily set up to benefit from Xgrid or similar implementations. (SETI@Home is an early grid computing implementation.)

Within Xgrid, you have a controller, a client, and an agent. The client submits the task to the controller, which then parcels out the job to a grid, which contains multiple agents. (Yes, you probably could have a single-agent grid, but what's the point?). Apple has two pieces of software that ship with Mac OS X 10.4 Server to help you with Xgrid. The first is the Xgrid Admin utility, the management utility for your grids, which allows you to set up a machine as a controller, and control which grids run which jobs on which agents. Note that while you can have multiple grids run by a single controller, you can only have an agent in a single grid at a time, and a job can only run on one grid at a time. You also can't move an agent between grids while it's running a job, nor can you move a running job between grids.

To avoid problems with rogue agents, there are three levels of security in Xgrid. The highest is Kerberos authentication, which uses Open Directory's Single-Signon to handle authentication. Then there's Password, where you set a single password on the agents, and then set up the controllers and the clients with that same password. There's also no security at all, but that's a bad idea for many reasons. Many, many, reasons.

Within Server Admin, the controls for the Xgrid Service are pretty simple. The Agent Tab allows you to set up the server as an agent, decide how you want to pick your controller, and which controller to connect to if you're picking a specific controller. You can also set how you accept tasks, and what type of controller authentication you want to use. The Controller tab lets you set up that server as a controller, and set up the client and agent authentication types you want to use.

You can have a single server acting as an agent and a controller, (and a client too, for that matter), but it's not a great way to get maximum performance. Note that job submission is done by the xgrid command line utility, but if you're using Xgrid, the command line is not going to be anything to worry about.

Conclusion

If you think this is it, well, you're wrong, but unless you want this issue of MacTech to be the "John C. Welch Memorial Issue", we'll end this month's column here. Next month, we'll take a look at Mac OS X 10.4 Server from the Workgroup Manager POV.

Bibliography and References

Almost everything in this article can be found in Apple's Server Documentation, at http://www.apple.com/server/documentation/. What little isn't there, I pried from the ridiculously busy brains of people like Schoun Regan of I.T. Instruction, Michael Bartosh of 4am Media, and Joel Rennich of AFP548.com. Schoun and Michael are the authors of the two best books on Mac OS X Server available, the Visual Quickstart Guide to Mac OS X Server, and Essential Mac OS X Server Administration, respectively. Buy them both, they're great books. If you read any of my columns and don't regularly read AFP548.com, then you're missing out on a fantastic resource. All three of these guys, Schoun, Michael, and Joel are Apple Trainers too, a great reason to take the Apple courses if you haven't yet. Those courses are taught by some of the best folks in the Mac market, and well worth the cost.

---

John Welch (jwelch@bynkii.com) is the Unix/Open Systems Admin for Kansas City Life Insurance, a Technical Strategist for Provar, (http://www.provar.com/) and the Chief Know-It-All for TackyShirt, (http://www.tackyshirt.com/). He has over fifteen years of experience at making Macs work with other computer systems. John specializes in figuring out ways in which to make the Mac do what nobody thinks it can, showing that the Mac is a superior administrative platform, and teaching others how to use it in interesting, if sometimes frightening ways. He also does things that don't involve computertry on occasion, or at least that's the rumor.