This document is NOT supported by Computing Services.
DO NOT contact the Help Center with questions on this document.

10.1 Deployment Plans

This document is an archive of our plans for deploying Mac OS X in the public computing clusters for the fall 2002 semester. It is included here for historical perspective only. For our fall of 2003 plans, see the current Deployment Plans document.

General Goals

Apple released the first version of Mac OS X in March of 2001. Mac OS X was a completely new operating system, not just a derivative of its predecessor. While the initial release showed great promise with its Unix core and improved user interface, most Mac administrators felt it wasn't ready for use in computing labs. By version 10.1, the operating system was ready for broader use but the availability of native applications was still limited. Over the past several months, third-party vendors have largely completed their transition and it has become feasible to consider moving to Mac OS X for our labs.

In March of 2002, the project team began assembling a plan to move to Mac OS X in our clusters. Cyert Hall 100 was selected as the first room to be transistioned. Assuming Cyert Hall 100 is successful, the rest of the clusters will be transitioned by the start of classes for fall 2002. The CFA clusters use very specialized hardware and software that would be difficult to move to Mac OS X, so they will continue to run Mac OS 9 for at least the fall semester.

Classic and Mac OS 9 support

Mac OS X offers support for legacy applications through the Classic environment where a copy of Mac OS 9 is booted as a "virtual computer" running under Mac OS X. We find that Classic works very well and has a very high level of compatibility with older applications. However, we would prefer to not make Classic available in the clusters since that would require us to maintain the Mac OS 9 system folder at the same time as Mac OS X. Also, starting Classic takes around 2 minutes for each user who logs in so the level of satisfaction is likely to be low. Instead, we will offer the complete suite of software as native applications, avoiding the need for Classic.

Update: There are a few critical applications that may sway us into installing Classic in the clusters. These apps are required for courses and aren't available in a Mac OS X native version. A list of these applications is on the 10.1 Questions page.

Infrastructure Integration

Our configuration of Mac OS X will smoothly integrate the existing infrastructure so it "fits in" with what users are accustomed to. Leveraging the infrastructure will also minimize the effort spent on services specific to Mac OS X.

LDAP for User Information

Standard Andrew accounts will be used
Traditional UNIX systems store information on all users in /etc/passwd
- Modern UNIXes, including Mac OS X, can get that info from LDAP instead
- A standard schema is described in RFC 2307, though we are using custom attribute names today
We asked our Directory team to add two attributes to all accounts:
- macosxHomeDir, an alternative to the AFS path in homeDir, set to /Users/<user-id>
- unixGid, set to 10 for all users
Two LDAP servers are configured in case one fails (ldap.andrew and ldap3.andrew)
- Fail-over and recovery worked very well in our tests with two LDAP servers
Rolf has an improved flat file agent but we won't use it
Users defined locally in NetInfo include "admin" and a few standard Unix users

Kerberos Authentication

Standard Andrew passwords will be used
The Kerberos login authenticator module verifies passwords entered in the login window
As a handy side-effect, users obtain a K4 and K5 ticket-granting ticket for the session
"Single sign-on" is achieved for Kerberized apps such as Mulberry and telnet

OpenAFS for User Information

A user's environment will follow them no matter which lab computer is used (see below)
The user's AFS volume will be used to store preferences and potentially documents
The Mac OS X home directory is created on the local disk at login time
"~/Library" points to a "Library" directory created in the user's AFS volume
- All preferences, keychains, etc. stored exclusively in AFS, automatically
"~/MyAFS" points to the top of the user's AFS volume
- It points to what would be their home directory on Andrew Unix machines
- Users will be encouraged to store documents there, subject to the standard quota (75MB or so)

Printing

For first cluster, use AppleTalk printing to existing print queues
KLPR isn't available today
Wait for Jaguar (Mac OS X 10.2) before investing any significant thought
- Jaguar uses CUPS as the printing back-end, based on IETF IPP standard
- Jaguar will probably integrate Unix lpr/lp command-line tools with Mac OS X queues
The long-term plan needs work, as shown on the 10.1 Questions list.

The Nomadic User Experience

In the early 1980's, Carnegie Mellon developed a distributed computing environment called "Andrew" based on Unix desktop computers. One feature of that system was support for "nomadic" computing where a user's settings and documents follow them as they move from one lab computer to the next. To accomplish this goal, each Andrew user was given a personal home directory on a central file server. The Andrew File System, now known as OpenAFS, was developed to house those files. The original Andrew environment continues to exist today in our computing labs that have Linux or Solaris machines. We would like to extend the nomadic user concepts to the Mac labs and Mac OS X gives us that opportunity.

Home Directories

Mac OS X assigns each user a home directory
- It's not optional, like it was with Multiple Users under Mac OS 9
- The system LoginHook gives us a chance to create the home directory on the fly
How much should we put into AFS?
- Balance of user convenience and the risk of problems that come up with a new approach
- We could create a fresh home dir at every login, but then user settings aren't preserved
- We could put home directories directly into AFS, but that has some risks (see below)
Decided to create home dirs on local HFS+ disk but point parts into AFS
- "~/Library" points to a "Library" directory created in the user's AFS volume
  - All preferences, keychains, etc. stored exclusively in AFS, automatically
- "~/MyAFS" points to the top of the user's AFS volume
  - It points to what would be their home directory on Andrew Unix machines
  - Users will be encouraged to store documents there, subject to the standard quota (75MB or so)
Pointing the Mac OS X home directory directly into AFS wasn't the right thing to do:
- If AFS quota is exceeded, it would be difficult to save documents locally
- Many things downloaded on cluster machines don't need to be saved
- The "MyAFS" folder better fits Mac OS 9 model where users work locally then store to Zip disks or personal file servers when finished
- Classic can't see AFS at all (though we hope to not install Classic)
- Existing .login and .logout files might not do the right thing on Mac OS X

Preferences

Link ~/Library or ~/Library/Prefs to AFS home directory
Can make it hard to repair broken prefs

The LoginHook

Want to add a personal LoginHook, but could give root access to users
Create a wrapper application run by Login Items do the same thing?
[Link to the script]

Security

Firmware security

In use for Solaris and Linux
In use for Windows

Crypted passwd security

Root user is kept in /etc/passwd
Password was always dictionary resistant
Might not be good enough anymore

Keying software

Most applications have been keyed for KeyServer
Used for copy protection as well as usage statistics
Trouble keying some items

Installation and Maintenance Tools

Initial Install

NetBoot plus ASR

Disk Maintenance

RsyncX for now