

Mac OS X Server On the Right Track
June 14, 1999
Brush Up on Unix Security
Mac OS X Server implements a complete BSD 4.4 layer on top of the Mac kernel, which can leave your system vulnerable to all the standard Unix security concerns. Apple has turned off most services by default. But, if you plan to enable them, you must stay up to date with security bulletins and patches. You also can add a few pieces of free software to tighten up the default security.
In our initial configuration of Mac OS X Server, we were asked whether remote access should be granted. In Unix-speak, this means enabling shell and execution services, such as telnet, rlogin, rsh and rexec, as well as ftp. Don't enable these unless you plan to monitor security. Adding a control and logging package, such as TCP wrappers (ftp://ftp.porcupine.org/pub/security/ index.html), is a great idea. With TCP wrappers installed, we were able to keep track of all remote logins.
If you plan to administer your machines via telnet (or other remote login), you should strongly consider adding an encrypted terminal program, such as SSH (Secure Shell, which you can find at www.cs.hut.fi/ssh/). This keeps your passwords and other sensitive information shielded from prying eyes. We downloaded a binary copy from the Peak Archives and installed it on our server. Within a few minutes we were logging into the server remotely, using an encrypted session.
In addition to the problems that can be wrought upon your server by mischievous users, enabling the e-mail (Sendmail) service can also open your server to e-mail abuse and spam relaying. Be sure to familiarize yourself with the anti-spam features of Sendmail 8.9.1, which ships with Mac OS X Server, at www.sendmail.org.
Look Ma, No Disk!
Did you ever say, "I wish those damn computers didn't have a local hard drive that users can mess with!" Well, your wish is Apple's command. With a Mac OS X Server, booting new G3s and iMacs is as easy as holding down the "N" key during boot. However, be prepared to bring your network infrastructure up to date: NetBooting is a bandwidth hog, loading about 25 MB across the wire during each boot in our tests.
We were disappointed to find that our server was allowed to serve only one boot image at a time, which means every Macintosh that's booted off that server must use the exact same System Folder configuration. So, when you purchase machines that run a more recent OS than your NetBoot images, you will be forced to upgrade all machines or exclude the new machines in your NetBoot scenario. We were told that a multiple boot scenario is possible, but unsupported.
The underlying technology for NetBooting is not new to computers or even to Macs. However, Apple's implementation is a bit more manageable and automated than the norm. NetBoot clients use standard BOOTP for their IP address configuration but, using extensions to the BOOTP protocol, will only accept replies from a NetBoot server. The NetBoot server responds only to NetBoot client requests and, on first request, dynamically allocates an IP from its assigned pool.
Making updates to the network boot (System Folder) and applications volumes is a time-consuming task, involving a total of three reboots to the server and NetBoot clients. We decided to upgrade Netscape Navigator from the default 4.0.5 to 4.0.8. Using the NetBoot Desktop Admin utility we made temporary copies of the boot and application volumes from which to boot and update, which took around 10 minutes. Once booted off the temporary images, we installed Navigator and then used the same utility to replace the master images with our new "temporary" images. When the new image becomes the master, each NetBoot client must reboot to take advantage of the new software.
When deciding on the specifications for your server disk space, be mindful of how many NetBoot clients you intend to serve. Each client makes a shadow copy of the network boot volumes for its own use. In our lab, this amounted to two clients, each with a 230-MB shadow image. We could have trimmed that image, since the clients were only using about 150 MB of the space. (The applications volume is shared among all clients.)
During testing, we found a bug in our iMac's ability to NetBoot. During the BOOTP/TFTP part of the boot, everything worked great. However, after that the Macintosh tried to establish an Apple Filing Protocol (AFP) session with the NetBoot server and mount the network boot volume. During the physical network negotiation with an NWAY 10/100 switch, the iMac failed intermittently. We were able to fix this by locking the switch port to half duplex. Apple has since issued a Technical Information Library Article covering this topic (til.info.apple.com/techinfo.nsf/artnum/n24887).
|