Essential Mac OS X Panther Server Administration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Installation seems like such a benign thing, and traditionally, in the Mac OS world, it has been: sit down in front of the server, insert the install CD, format the drive, install, and repeat. Largely unchanged since the word CD replaced floppy, server installation is a process most administrators and technical staff are familiar with, and if nothing else it seems like a logical—if also a very boring—way to begin a book. Unix administrators, however, have long had a number of other options: possibly still boring, but in any case much more powerful and flexible from a systems management standpoint. With Mac OS X, and especially with Mac OS X Server, many of these options make their way to the Mac world, often with Apple's characteristic ease of use.

A second and very important aspect of this process is planning. Technology vendors—particularly Apple—endeavor to remove complexity from the computing experience, in many cases very successfully. Integration into heterogeneous environments, though, is still a complex issue with a number of facets. Good planning can go a long way towards reducing the number of headaches and unexpected speed bumps that administrators experience. Unfortunately, planning is a little-documented and often-neglected part of deployment. This chapter examines that pre-installation process, starting with purchasing and policy decisions and traveling down several feasible installation and configuration routes.

Covering installation planning in the first chapter might seem a little awkward. You'll be asked to take a lot of things into consideration, many of which you may not have any experience with yet, but most of which will be covered later in the book. With that in mind, this first chapter contains a lot of forward pointers to other material. Feel free to use it as a jumping-off point in order to explore concepts that are new to you.

The installation process actually begins well before a machine is booted for the first time. It can and

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The installation process actually begins well before a machine is booted for the first time. It can and should begin even before the machine arrives on site. Planning is an often-neglected aspect of server management, and probably the single most important factor in reducing support costs. This is especially true for a server product, since a server installation by its very nature affects more end users than a workstation install. While it's important to keep from getting stuck in the quagmire of chronic bureaucratic deliberation and massive committee decision making, rushing into a server install is the last thing you want to do. Specific areas of planning focus should include the hardware platform, storage platform, volume architecture and management, and networking.

Apple's Xserve, a 1U (single standard rack-size) server product, has effectively ended most conversations about hardware choices. When the numbers are run, the Xserve, with its included unlimited client license version of Mac OS X Server, is almost always a better value than a Power Mac G5 with a separate Server license tacked on. The only real exceptions are very small deployments—particularly in education environments, environments with existing hardware that can be put to work as a server, or when the purchase of new hardware can't be justified.

That said, Mac OS X Server can run on virtually any hardware platform that Mac OS X can. In fact, much of the testing that went into this book was carried out on a set of iBooks I carry around while traveling. This isn't to imply that Apple supports such a configuration; in fact, portables are specifically not supported by Mac OS X Server. Real deployments should always conform to Apple's list of supported hardware, if for no reason other than that getting support for an unsupported hardware platform can be quite difficult.

According to Apple's web site, Mac OS X Server requires an Xserve, Power Mac G5, G4, or G3, iMac, or eMac computer; a minimum of 128 MB RAM or at least 256 MB RAM for high-demand servers running multiple services; built-in USB; and 4 GB of available disk space. These specifications are probably underestimated for most server roles.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

After the planning process is complete and your server hardware is onsite, you can proceed with installation. The exact methodology used will vary tremendously from organization to organization and from site to site.

Jaguar Server marked a fairly substantial departure from previous Apple software installation processes. From a fairly mechanical or procedural standpoint, this difference was not very obvious—sitting down in front of the server console, inserting a CD, and pressing some buttons still yielded a complete install. However, much of Jaguar Server was designed in order to support the Xserve, a design goal of which was complete remote operation—including installation. These remote installation options bring a whole new set of possibilities to deployment planning. In a nutshell, the server install—whether booting from CD or via NetBoot into a network install—sets up a TCP/IP stack, starts an ssh daemon, and advertises itself using a multicast response similar to Rendezvous. Mac OS X's Unix heritage allows for a wide range of features, which Apple had essentially finally chosen to leverage. Panther Server builds on that basic architecture, specifically extending its post-install configuration options in order to better suit large-scale deployments. We'll examine that evolution in some depth in this chapter, including even a number of strategies outside of traditional installation.

In order to best understand installation options, it is important to have a thorough knowledge of the installation architecture. How is the installation environment prepared? What happens during system startup, and what services are available to the OS? Apple has actually developed a very modular boot process, flexible enough that the same sequence is used regardless of whether the machine is booting from CD, off of the network or from the local hard disk. We'll be looking specifically at an OS install in this case, but some of this material is general enough to apply to other types of booting as well.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In order to best understand installation options, it is important to have a thorough knowledge of the installation architecture. How is the installation environment prepared? What happens during system startup, and what services are available to the OS? Apple has actually developed a very modular boot process, flexible enough that the same sequence is used regardless of whether the machine is booting from CD, off of the network or from the local hard disk. We'll be looking specifically at an OS install in this case, but some of this material is general enough to apply to other types of booting as well.

When the machine is booted, it is initially controlled by its built-in boot ROM, consisting of a minimal Power On Self Test (POST) and Apple's Open Firmware environment (OF). Unless otherwise configured, OF, after building a device tree, executes BootX, the system's booter. In most cases, BootX is executed from the device specified in OF's boot-device variable, which looks something like Example 2-1 when booting from an internal IDE drive:.

Example 2-1. Here I've used the nvram command's -p flag to print the contents of Open Firmware. This output is filtered using the grep command so that only the boot-device setting is shown.

Big15:~ mab9718$ nvram -p | grep boot-device
boot-device   pci2/ata-6@D/@0:9,\\:tbxi

However, when installing an OS, it's common to choose a startup volume manually. There are several ways to accomplish this. By far the most common is to hold down the C key at startup, overriding the boot-device variable and booting from CDs. Other options include holding down the N key (boot off the network) and Option, which provides a list of local volumes to boot from. It's unlikely in many cases that you'll have easy keyboard or monitor access to a server in a rack. With this in mind, Apple has built a completely headless boot menu into the Xserve. Find out more about it here:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The simplest, most common form of installation is a local , graphical install. We'll start there in order to get a basic understanding of the install process and Apple's goals for it.

A local installation—booting from CD, sitting in front of the server console—is pretty straightforward. By this point in the installation process you should have both a sane plan for deployment and a good understanding of the CD boot environment. When booted from the Panther Server CD, you have easy access to Terminal, Disk Utility, a Reset Password utility (to reset the password for users on an already-installed system) and a utility to change the current startup disk, all under the Installer menu (the Jaguar Server installation process has no Startup Disk utility). The initial installation screen, listed in Figure 2-1, allows for the choice of an installation language.

Your first stop will typically be Disk Utility. In Panther, Disk Copy's functionality has been rolled into a new, single-window disk utility interface, seen in Figure 2-2. Its functionality is very contextual, with the right pane of the application changing to reflect the functions supported on the selected object (disk, partition, or image).

Entire disks may be repaired, erased, partitioned, added to a RAID or restored (the last is a new option in Panther that we'll discuss later in this chapter). It is an

Figure 2-1: The initial installation screen when booted from the Mac OS X Server install disk.

Figure 2-2: Panther's Disk Utility when booted from the Mac OS X Server install CD.

intuitive interface. In addition to options similar to Jaguar's, the Erase function in Panther optionally supports two advanced security options:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You might have already realized that there are some real limitations to the remote graphical installation. It's not currently possible to do any advanced disk management, such as RAID creation or repartitioning, using Server Assistant. Similarly, advanced partitioning schemes—mounting nonroot volumes in places other than /Volumes--isn't supported in any graphical interface, much less by Server Assistant. Finally, note that Panther Server seems to have trouble installing graphically onto XServe Hardware RAID volumes.

In Jaguar, the client managing the remote install must typically be on the same subnet as the server (since servers are discovered solely via multicast queries). In most environments, clients may not freely access the data center subnet, although widespread use of VLANS and multicast routing is making it more feasible.

The good news is that, since Server Assistant (both in the case of Server Installation and Configuration) simply uses SSH to log into the server and issue installation commands, a full, flexible, and very powerful installation environment is available to those who would choose to log into the server from an SSH client. This approach has the additional advantage of allowing for administration from non-Apple hosts.

The first task is locating the server. Once again, given some infrastructure work, this could be very trivial, since a DHCP server could be supplying the server a consistent address when booted from CD. If this isn't the case, however, you can still locate the server with the sa_srchr command (like several other utilities we've discussed, sa_srchr is in /System/Library/ServerSetup). Its default usage is to search the multicast address 224.0.0.1:

ladmins-Computer:~ ladmin$ /System/Library/ServerSetup/sa_srchr 224.0.0.1
localhost#unknown#169.254.182.38#00:30:65:fb:41:c2#Mac OS X Server 
10.3#RDY4PkgInstall#2.0#512

Notice that the sa_srchr response contains a number of pieces of data, including a version number, the server's MAC address, and the fact that the machine is waiting for a package install (RDY4PkgInstall, rather than waiting to be configured). This is the exact method that Server Assistant uses to locate data for itself.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We briefly mentioned earlier that Server Assistant—whether run locally or remotely—was able to create persistent configuration records that could be subsequently used to automatically configure other servers. In fact, you don't even have to be logged into a particular machine to do this. Server Assistant can be run from any supported platform, and one of its initial choices on startup is "Save setup information in a file or directory record," illustrated in Figure 2-24.

Figure 2-24: Using Server Assistant to save setup information into a file or directory record.

The process to gather the data for this record is identical to any graphical configuration using Server Assistant, so we won't cover it again; you're just running through the configuration options as if you were actually configuring a server. The real differences in the process show up after configuration is finished. When saving the output file, you have several choices. The first, seen in Figure 2-25, is to save to a text file. The result is basically just a record of your configuration choices, and has been around since 10.0. Its output looks something like this:

Language Selection:           Use English to administer the server
Keyboard Selection:           U.S.

Figure 2-25: Saving server configuration data to a text file. This option produces a record of configuration choices, but does not allow for easy reuse of configuration data.


Adding New User:              admin
Short Name:                   admin
Setting the Administrator (root) password to your local account password.

Host Name:                    xserver
Computer Name:                cxserver
Rendezvous Name:              rxserver

The second, though, (seen in Figure 2-26) is new with Panther, allowing us to save the configuration for re-use with another host.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Server installation and configuration should not necessarily be limited solely to Apple's included installation tools. As flexible as they are, no vendor can feasibly meet the needs of every environment within which its products might be deployed. In practice, alternate tools from both Apple and third parties can be used to supplement or replace the standardized install process (this statement is well illustrated by the NetInstall example earlier in this chapter). In the interest of time and space, I cannot cover every aspect of every tool. Instead, the goal of this section is to provide the high points, information from which sane architectures may be customized for your environment and thoroughly tested.

The simplest of these installation options eliminates the CD and runs the installation while booted from the network, using Apple's NetBoot technology. The installation process—other than booting the server from a NetBoot server—doesn't differ much from a CD-based install. The obvious benefit is being able to run an install without having to tote around a bunch of CDs. This benefit is counterbalanced by the necessity and added overhead of maintaining a NetBoot server and Network Installation Images.

NetBoot as a component of Mac OS X Server is covered in Chapter 28.

Network Install is configured using Apple's Network Image Utility , pictured in Figure 2-30. Its use is straightforward, but it is not on the whole a friendly application, being subject occasionally to odd timeouts and unexpected and frustrating pauses. Nonetheless it has progressed remarkably since its introduction, and is now capable of exporting disks to and importing them from remote NetBoot servers (using sftp,which is enabled as a part of Mac OS X Server's default OpenSSH configuration).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Most of these tools conform to a common principal—the more granular they are, the slower they become, since that granularity typically requires a file-by-file analysis. So, in most cases several solutions work best together.

When managing large-scale Mac OS X Server deployments, I like to use radmind in conjunction with some sort of ASR-based process and Server Auto Configuration. In the past, this usually meant using a third-party product like Mike Bombich's NetRestore (www.bombich.com/sofware/netrestore.html). With the advent of ASR-enabled Network Installs, though, that has slowly begun to change. NetRestore is probably still a more powerful option, but given the time constraints often associated with consulting work, I prefer to use built-in tools whenever feasible. At my last cluster installation, I used an automated, ASR-based Network Install to lay down the bulk of the system software. Coupled with Server Auto Configuration, this produced working and well-managed Mac OS X Servers. Fine-tuning (installing site-specific software) was achieved with radmind. I'm really fond of this trio.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Management tools can make or break an integrated server product, especially one from Apple. From user creation to the management of share points and services, the maintenance of a server can be quite onerous. Add to that the complexity and breadth of a product like Mac OS X Server—plus its wide feature set and audience, and the diversity of its deployment scenarios—and the outlook only becomes more daunting.

To help surmount this challenge, Apple provides a variety of graphical and command-line tools designed to simplify the deployment and management of Mac OS X Server. This chapter introduces and dissects those tools along with the underlying protocols and technologies that make them possible. Along the way, I'll discuss best practices, security, logistical approaches appropriate for various deployed environments, and practical tips for day-to-day server management.

A warning about nearly all of Apple's graphical management tools: most allow users to save the administrator's password to the Keychain. This is surely convenient, but beware: it also makes the administrator's machine a valuable target for malicious parties, particularly if that machine happens to be a laptop and if the administrator manages multiple servers. Even though Keychain itself is very secure, adding another link in the security chain necessarily also adds another feasible point of failure. If you do choose to make use of this feature, be sure to protect your Keychain and login passwords accordingly.

The user experience is Apple's temple. For a good portion of the company's history, it was (justifiably) the biggest reason behind their existence, and Apple has in many ways continued to revolutionize the user experience with each OS release. Server management, though, has its own set of requirements that are wholly different from those of home users wishing to better organize their digital life. Although Apple's server tools have generally been very simple and easy to use, they have not always scaled up to complex or large deployments as well as the underlying OS has. Toward these ends, Panther Server is a solid step in the right direction, and although it isn't perfect, it provides by far the most scalable management interface Apple has ever presented.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The user experience is Apple's temple. For a good portion of the company's history, it was (justifiably) the biggest reason behind their existence, and Apple has in many ways continued to revolutionize the user experience with each OS release. Server management, though, has its own set of requirements that are wholly different from those of home users wishing to better organize their digital life. Although Apple's server tools have generally been very simple and easy to use, they have not always scaled up to complex or large deployments as well as the underlying OS has. Toward these ends, Panther Server is a solid step in the right direction, and although it isn't perfect, it provides by far the most scalable management interface Apple has ever presented.

We'll start by analyzing Panther's simplified, reduced toolset. Rather than examining each option of each tool in great depth, we'll instead focus on the tool's high-level functions, revisiting its specific capabilities later, when our focus is the protocols and technologies those tools manage.

One very important aspect of all of these tools is their ability to be run remotely. Mac OS X Server is, by design, a remotely managed platform; every tool we'll look at (even when run locally) connects over TCP/IP to one of several backend daemons running on the server. Given the proper network access, this means that Mac OS X Server can be managed graphically from anywhere, as long as you have access to another Mac. Remote management is so important to Apple that, beginning with the Xserve G5, Apple's servers no longer shipped with a video card as a standard option.

Panther moves a step further, with command-line equivalents to many of these functions. This design takes remote management to another level, since the server can now, given proper network access, be managed remotely from any platform using an ssh client. The next logical step is a web interface to these functions, allowing for platform agnosticism in graphical management as well. Apple has not, as of yet, indicated that such a feature is forthcoming, although many server management tools do use HTTP as an underlying protocol.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As Unix derivatives, Mac OS X and Mac OS X Server automatically inherit 20 years of command-line management tools. These tools have evolved mostly in response to traditional Unix administration tasks and according to traditional Unix requirements. With Mac OS X's introduction, many of these tools proved inadequate for managing Apple's new server applications and subsystems. In response, Apple began a slow evolution of its own command-line utilities to complement those more traditional tools. Panther's latest progress towards this evolution is substantial, and for the first time, command-line administration of Mac OS X Server doesn't require in-depth knowledge of the configuration mechanisms of 14 different server technologies.

This section will focus on both Apple-specific tools and traditional Unix tools that Apple has modified for their own use. The latter case is actually quite rare; Apple generally prefers cross-platform compatibility to modification of Open Source tools.

serveradmin is the command-line equivalent of the Server Admin application. Due to the breadth of its function and the resulting complexity in the syntax of certain options, some features are more appropriate for scripted applications. Nonetheless, it is an extremely useful tool, and its existence points to Apple's focus on the professional system administration market.

Unlike its graphical cousin, the serveradmin utility cannot be run as an administrator; it must be run as root. This might seem like a minor point, since by default, all administrative users can use the sudo utility to execute command processes as root. However, sudo is quite powerful, and in a highly granular, managed environment, it might be desirable to allow access to certain serveradmin features without allowing the user to have full root privileges. While sudo is flexible enough to accommodate this in advanced configuration scenarios, I feel this is too much to ask of your average Mac OS X administrator, who probably just wants to delegate some basic management functions to less-senior personnel. This lack of delegation is a common theme in many of Apple's command-line tools, most of which must be run as root.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Behind the glossy ease of use of Mac OS X Server's management applications lay several daemons. Actually responsible for the work that is carried out, they are the central points through which most system administration flows, translating button-clicks, switches, and serveradmin flags from the administrative process to the actual configuration changes executed on the server side. This section examines each of the server management daemons, discussing their function, architecture, startup, and, in some cases, extensibility.

SSH is a secure, modern protocol designed to replace a number of less-secure remote management tools like telnet. Due to its flexibility, sshd is worth mentioning first. Because of the secure remote access it provides, most command-line management can easily be accomplished away from the server's console. Remember too that the Server Assistant application is really a graphical shell that executes some very specific commands via SSH to set up the server.

In Panther, sshd is started by the xinetd super-server, due to the existence of the /etc/xinetd.d/ssh file (Example 3-13). While a complete examination of xinetd is beyond the scope of this chapter, it's worth noting that when an SSH connection comes in, xinetd executes the /usr/libexec/sshd-keygen-wrapper script.

For more information on xinetd, including its architecture and significance in Mac OS X, see Chapter 18.

Example 3-13. The /etc/xinetd.d/ssh file contains xinted's SSH configuration.

service ssh
{
        disable = no
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/libexec/sshd-keygen-wrapper
        server_args     = -i
        groups          = yes
        flags           = REUSE IPv6
        session_create  = yes
}

The sshd-keygen-wrapper script checks for the existence of various host keys, creates them if needed, and then executes

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In a way, this entire book revolves around system administration. The details, processes, and infrastructures that make up Mac OS X Server are documented—hopefully to a depth that can't be found elsewhere—specifically to enable their secure and robust management. System administration, however, is a topic of a much greater depth, and moves well beyond a mechanical understanding of how various pieces fit together, into a set of philosophies and best practices that pervade and are consistent among most aspects of the system. This chapter concerns those philosophies and trends, throwing in a few mechanical tidbits for good measure. In keeping with the spirit of this book thus far, we will examine those components specifically in the light of Mac OS X Server, especially where that differs from the practices and philosophies around other operating systems.

Note also that these are my opinions and are, in many cases, assertions of the worst kind, with very little data presented behind them. Take them as you will, and where time and budget allow, data will be presented.

Most academic disciplines develop heuristics, or ways of thinking about certain types of problems. System administration (and IT in general), although it has not been widely examined in an academic context, is no different, having developed some common approaches in its young history. While these approaches are not necessarily specific to Mac OS X, and while I hope they are illustrated throughout this book, it does make sense to call at least some of them out here. Remember that there are no hard and fast, black and white rules. These are guidelines that have proven productive in many environments. This does not necessarily mean they will be applicable to yours—only that the possibility deserves analysis.

Infrastructure is developed to support certain functionality, and in general, several applications might rely on a single infrastructure element. Few applications, for instance, are useful at any scale without properly configured routing. Similarly, many separate applications (desktop logins, in-house web applications, file servers, and mail delivery, to name a few) might depend on an available and properly functioning directory server, and certain DNS conventions might be established to minimize discrepancies when managing certain classes of devices. The list is really endless. The point is that organizations develop interlocking and centralized systems in order to support other systems that meet their business goals. Significant resources are often invested into development of such environments, and systems being introduced into any organization should seek to fit in as seamlessly as feasible, interrupting as little as possible.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Most academic disciplines develop heuristics, or ways of thinking about certain types of problems. System administration (and IT in general), although it has not been widely examined in an academic context, is no different, having developed some common approaches in its young history. While these approaches are not necessarily specific to Mac OS X, and while I hope they are illustrated throughout this book, it does make sense to call at least some of them out here. Remember that there are no hard and fast, black and white rules. These are guidelines that have proven productive in many environments. This does not necessarily mean they will be applicable to yours—only that the possibility deserves analysis.

Infrastructure is developed to support certain functionality, and in general, several applications might rely on a single infrastructure element. Few applications, for instance, are useful at any scale without properly configured routing. Similarly, many separate applications (desktop logins, in-house web applications, file servers, and mail delivery, to name a few) might depend on an available and properly functioning directory server, and certain DNS conventions might be established to minimize discrepancies when managing certain classes of devices. The list is really endless. The point is that organizations develop interlocking and centralized systems in order to support other systems that meet their business goals. Significant resources are often invested into development of such environments, and systems being introduced into any organization should seek to fit in as seamlessly as feasible, interrupting as little as possible.

This is particularly the case where Apple technologies are concerned. Mac OS X has paved the way for acceptance into many environments that Apple previously could not have considered. The Macintosh is, however, still a minority platform, and it makes little sense when working to gain acceptance somewhere to ask that organization to make fundamental infrastructure changes in order to support the Mac. Such changes, because they are made to centralized, enterprise systems, are costly, and if it is costly to bring Apple technologies into an infrastructure, then those technologies have a quickly diminishing likelihood of adoption.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section of the chapter delves into specific features and options available to support the services available in Mac OS X Server. While none fit into a specific existing chapter, all are important to day-to-day server management. These fundamental features affect the overall health of the server rather than supporting specific systems. Managing them correctly helps to support the conceptual elements outlined previously, and it is hoped, will result in a healthier server.

One challenge of server management common to nearly any organization or platform is that of software updates . Vendors release updated software versions, and even subtle changes in functionality or feature set can adversely affect established support infrastructures. Worse yet are new bugs, introduced unknowingly into new software versions. Either case may result in considerable downtime and lost revenue. A careful balance must be struck between secure, up-to-date software and stable, predictable systems. A careful analysis reveals three distinct phenomena in this area: major updates, like the one from 10.2 (Jaguar) to 10.3 (Panther); minor revisions, such as the one from 10.3.4 to 10.3.5, and Security Updates, issued to counter specific vulnerabilities in specific OS versions.

Section 4.2.1.1: Software update methods

Apple includes a variety of mechanisms for accessing both minor OS versions and security updates via their Software Update infrastructure. (Generally, major OS revisions must be purchased.) Update lists are available from pre-established hosts (swscan.apple.com and swquery.apple.com), while the updates themselves are usually outsourced to companies that specialize in high-bandwidth downloads, like Akamai and AT&T. All activity—software scans and downloads—occur over port 80. Updates themselves are cryptographically signed so that bogus updates—from DNS spoofing, compromised DHCP, or any other malicious source—may be discarded. Apple includes three tools designed to help keep Mac OS X Server up-to-date:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Troubleshooting Mac OS 9 was largely a set of black-box procedures. Recall this conversation, early in the computing experience of many Mac users: "Zap the PRAM, start up without extensions, and rebuild the Desktop." Why? "Because it fixes a lot of things."

Mac OS X is a beast of an entirely different nature. Rather than being a black box, it is, with a few exceptions, largely transparent. Rather than being closed, it is decidedly open. Rather than hiding from the user, Mac OS X's underpinnings are very near the surface, albeit under a glossy exterior. This remarkable transition fundamentally affects the act of troubleshooting. Rather than a script or a voodoo-style procedure complete with incantations, troubleshooting can now be called a way of thinking. With vastly more data available, the administrator draws vastly better conclusions about the nature of the issue at hand.

In the end, the question has to be asked: "Does troubleshooting matter?" Does the process of troubleshooting matter at all, as long as the outcome ensures that what was once broken is now fixed? I would say it does. Transparent, controlled troubleshooting leads to understanding. And better understanding contributes to architectures and systems that don't need to be fixed. So although understanding for the sake of knowledge is a worthy goal, it's not something we can advocate in a business setting. Understanding in order to foster better-built systems and lowered support costs, is.

This chapter seeks to bring academic rigor to the process of troubleshooting. In it, we'll first examine some generalized methodologies for solving problems in Mac OS X and later move into some specific tools that can be used in various stages of that framework. The goal throughout is to build an increased knowledge of the tools that work together to create the user experience we know as Mac OS X—from the fundamental data structures of the OS to the poof of the Dock.

It's a very strange question to ask an administrator: "How do you solve problems?" Anecdotal evidence suggests that the people who gravitate towards these positions don't have to think too much about it. After all, there's hardly a wide variety of IT-centric academic disciplines, and within these disciplines there aren't many classes or research specialties that center on the process of fixing things. It seems much more likely, especially in industries where IT has not been fully professionalized, that IT staff are drawn to their positions precisely because they are particularly good at fixing things, especially under circumstances of limited knowledge. Since it is this audience I'd like to speak to, it would be presumptuous to suppose that I have all the answers. I'd like to propose instead some formalization to the process of technical analysis—frameworks in which administrators can examine and more efficiently utilize their pre-existing methodologies. Hopefully this will allow administrators, rather than simply going forward based on their natural talent, to specifically hone their already keen abilities.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

It's a very strange question to ask an administrator: "How do you solve problems?" Anecdotal evidence suggests that the people who gravitate towards these positions don't have to think too much about it. After all, there's hardly a wide variety of IT-centric academic disciplines, and within these disciplines there aren't many classes or research specialties that center on the process of fixing things. It seems much more likely, especially in industries where IT has not been fully professionalized, that IT staff are drawn to their positions precisely because they are particularly good at fixing things, especially under circumstances of limited knowledge. Since it is this audience I'd like to speak to, it would be presumptuous to suppose that I have all the answers. I'd like to propose instead some formalization to the process of technical analysis—frameworks in which administrators can examine and more efficiently utilize their pre-existing methodologies. Hopefully this will allow administrators, rather than simply going forward based on their natural talent, to specifically hone their already keen abilities.

All that verbiage probably seems long-winded and academic in the context of our first example, but the example's very simplicity illustrates the appropriateness of its examination in a formalized framework. We're speaking, of course, of quick fixes.

A quick fix, for the purposes of this book, is an action that can be undertaken to resolve an issue without really understanding what's wrong. Additionally, it's common for quick fixes to affect several variables at once—enough variables that individual investigation would be problematic. A good example is Mac OS X's Repair Permissions capability (see Figure 5-1).

Figure 5-1: The Repair permissions interface in the Disk Utility application.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Mac OS X provides a wealth of tools with which to pursue troubleshooting, regardless of how you wish to pursue that goal. In this section, we'll look at some relevant options available with each tool. Although I'd like to offer an exhaustive reference, it would likely be both long and dry, so in the interest of finishing the chapter before the reader's next birthday, I'll be selective.

Many of these tools appear again later throughout the book, sometimes with different or more advanced options than shown here. This is by design. This section introduces you to the tools and provides the basics of their usage. It's my philosophy that once you're comfortable with this basic usage, incremental exposure to more advanced features is a good, comfortable way to learn.

Forensic tools help you determine what is happening, what has happened, or how a particular process works. That's a broad definition and certainly not a formal one, but it is a good way to help classify all of these tools.

Our usage of forensic shouldn't be confused with a formal set of forensic analysis packages like the coroner's toolkit. Although there is some overlap, the study of computer forensics is its own science, and outside the scope of this book.

Usage

    strings filename

Description

The strings command looks for the text in a given file. While this task seems simple, its real utility comes into play when its used with binary files—like executables or binary databases—that are made up of not only of text but also of a lot of data that makes sense to Mac OS X but not to you.

These text strings can yield valuable clues about how the process in question works, including the location of its configuration files, the path to processes it might call, and helpful notes on usage. Note this partial

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As directory domains and centralized management have grown in importance to the IT industry, Apple has slowly but surely developed a robust and standards-based server-side directory services architecture. Panther Server represents a real milestone in that direction, with a Kerberos-LDAPv3-and SASL-based component known alternately as Open Directory, Open Directory 2, and Open Directory Server, depending on whom you ask.

Open Directory itself is a bad case of marketing terms gone crazy—encompassing a whole suite of OS components that collectively provide a directory services architecture to Mac OS X. Open Directory Server generally refers to the server side of those components. Open Directory 2 was probably coined to differentiate Jaguar's directory service offerings (which were heavily reliant on NetInfo) from Panther's, which are more centered around LDAP. Luckily, the technology is more stable than the terminology.

The Appendix documents the client-side of Apple's Directory Services infrastructure—the processes Mac OS X and Mac OS X Server employ in order to make use of identification, authentication and authorization data. This chapter, however, begins the analysis of Mac OS X Server's Directory Service capabilities—both as a directory client and server.

Directory Services are complex. There is no getting around it. The concepts are new to many administrators and sometimes difficult to grasp. In fact, Open Directory Server Services are provided by three separate but interrelated server-side systems. OpenLDAP, an Open Source LDAP server package, is used to house and access data used to identify user, group, and machine accounts, including authorization policies and other configuration data. Password Server, an Apple-specific, standards-based and network-aware authentication authority, is Mac OS X Server's primary means of authentication for both shared and local directory domains. It is used in conjunction with MIT's Kerberos distribution in order to support a more robust, single-sign-on enabled authentication infrastructure.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Managing Open Directory Server—as opposed to managing the accounts and configuration data contained in its databases—is mostly achieved in the user interface of the Server Admin application, its command-line equivalent, serveradmin, and several other utilities that simplify the process of configuring the underlying services. This section of the chapter serves to introduce the reader mostly to the higher-level aspects of that interface. Some more specific configuration options are covered in later Open Directory Server chapters in a more task-oriented fashion.

Open Directory's settings are easy to locate (like all other service-specific preferences); they can be found in Server Admin's service list, as shown in Figure 6-1. This initial selection reveals several other sections available in Server Admin's righthand pane: Overview, Logs, and Settings.

Figure 6-1: To locate the Open Directory settings, select Open Directory from the service list of the server you wish to manage.

The Overview, illustrated in Figure 6-2, yields a high-level look at the processes that comprise Open Directory Server. Which processes are running varies with the server's configuration. Servers that are hosting or accessing shared directory domains typically have more enabled services than those in a standalone configuration.

Figure 6-2: Servers hosting shared Open Directory domains should have all of the available services (lookupd, netinfod, slapd Password Server, and KDC) listed as running.

Absent from this list is the DirectoryService daemon, which is central to Directory Services on Mac OS X. If DirectoryService weren't running, it would be unlikely that you could have logged into Server Admin in the first place—and you'd probably have much larger issues, since it's supposed to be restarted automatically by the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The whole point behind shared directory domains is to store user, group, and other administrative data centrally. It makes sense, then, that servers as well as clients should make use of this data. This could be worthwhile for a number of reasons. MIT, for instance, recommends that as few services as feasible be run on any KDC. Since every Open Directory Master and Replica contains a KDC, it is a good idea to minimize the number of services running on any server supporting either one of these roles. Similarly, you might not want a public-facing web server or other high-visibility host serving as an Open Directory Master. Such a machine, however, should almost certainly participate in the shared domain in order to minimize local maintenance and to make use of domain resources.

Performance is another common impetus for differentiating server roles. LAN-based file servers might experience a tremendous I/O load, which could negatively affect the performance of Open Directory Server services (which can also lead to a fairly high load). Larger enterprises demand more servers in order to supply some base level of service to increasingly large user bases. In theory, all of these servers should participate in an Open Directory domain.

The actual configuration of Mac OS X Server to be an Open Directory Client is fairly trivial. It is, in fact, identical to the configuration of Mac OS X—in both cases, the Directory Access application is used. The one caveat is that Mac OS X Server can, in an out-of-box configuration, be configured remotely, using the connect option in Directory Access's Server menu. The resulting authentication dialog can be seen in Figure 6-13.

Figure 6-13: The authentication dialog from Directory Access's Server menu. As noted in Chapter 3, this operation, which communicates on the server side with the DirectoryService daemon, is protected by a 512-bit Diffie-Hellman exchange.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

LDAP (the lightweight directory access protocol) plays a key role in Open Directory Server, providing identification services and some authorization data to various client-side systems. In keeping with what has become a fairly common trend in Mac OS X Server, it is supported by the Open Source OpenLDAP package. This in itself is not new; Jaguar Server also shipped with an OpenLDAP implementation. Panther, however, brings a much more standardized and securable architecture, storing its data in a fast, programmatic database rather than in NetInfo. This and other fundamental changes give Open Directory Server room to scale to hundreds of thousands of users, groups and other objects.

Jaguar-based Open Directory Masters (which store their data in NetInfo and share it using OpenLDAP) should not have more than 10,000 objects (users, groups, and machines). Additionally note that attributes in NetInfo (such as a group's user list) are limited to 1,024 values.

This chapter begins with a generalized analysis of LDAP as a protocol, progresses into a number of aspects of OpenLDAP configuration, and ends with a look at the kind of data that can be found in most Open Directory shared domains.

LDAP is one of those words that's taken on a lot of baggage in the information technology field. Eager sales people have latched onto it as a sort of silver bullet, using it as a buzzword whenever feasible, promoting its standards-based nature as a solution to an endless array of challenges and issues. In the end, though, LDAP is nothing but a communication protocol; designed, as its name implies, to provide a standardized way to access data, regardless of where or how it is stored. A basic setup is shown in Figure 7-1.

Figure 7-1: LDAP is a communication protocol that provides a standardized way to access data, regardless of where or how it is stored. This illustrates well the idea of abstraction—LDAP clients do not have to understand how to talk about BDB, NetInfo, or Jet—they simply need to know LDAP.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

LDAP is one of those words that's taken on a lot of baggage in the information technology field. Eager sales people have latched onto it as a sort of silver bullet, using it as a buzzword whenever feasible, promoting its standards-based nature as a solution to an endless array of challenges and issues. In the end, though, LDAP is nothing but a communication protocol; designed, as its name implies, to provide a standardized way to access data, regardless of where or how it is stored. A basic setup is shown in Figure 7-1.

Figure 7-1: LDAP is a communication protocol that provides a standardized way to access data, regardless of where or how it is stored. This illustrates well the idea of abstraction—LDAP clients do not have to understand how to talk about BDB, NetInfo, or Jet—they simply need to know LDAP.

If the whole point of LDAP is abstraction, why is there so much excitement about 10.3's adoption of a more standardized data storage method? It boils down to three issues: standardization, performance, and security.

Table of Contents

Section 4.2.1.1: Software update methods