Carnegie Mellon University Website Home Page
 
Skip navigation and jump directly to page content
Documentation Index
Contributed Documentation
Deploying Mac OS X in Clusters
10.2 Deployment Plans
Accounts
Network, Phone & TV
Software
Email & Calendar
Secure Your Computer
Clusters & Printing
Web Services
Classroom & Event Support
Training & Education
Technical Support & Services
Campus Partners
Information Security Office (ISO)
Contributed Documentation
This document is NOT supported by Computing Services.
DO NOT contact the Help Center with questions on this document.
 
Carnegie Mellon

10.2 Deployment Plans

This document describes our plans for deploying Mac OS X 10.2 in the student computing clusters for the fall 2003 semester. It will be updated as we finalize issues and make adjustments.

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. By the spring of 2002, third-party vendors had largely completed their transition and it became feasible to move to Mac OS X for most of our labs. With version 10.2, the OS and applications are even more mature so we expect to move all our labs to that version. That includes our specialized labs with music and video hardware and applications.

In March of 2003, the project team began assembling a plan to move to Mac OS X 10.2 in our clusters. Cyert Hall 100 was selected as the first room to be transistioned, just as it was for the 2002 upgrades. Assuming Cyert Hall 100 is successful, the rest of the clusters will be transitioned by the start of classes for fall 2003.

Licensing the Software

The plan begins with licensing the operating system and applications that we want to deploy. The details of our licensing are not included in this document, but please be sure to include this step in any transition plans you create. The cost of upgrading the OS and applications for 10.1 was significantly more than our typical yearly upgrades for software.

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. In our initial move to Mac OS X 10.1, we used Classic to provide access to a small number of 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 Open 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 Open 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 to Library in AFS home directory
  • Can make it hard to repair broken prefs
  • Causes havoc for Dock prefs because the selection of applications and their locations are not the same in SCS and Architecture labs
  • Need a tool to fix up Dock prefs at every login

The LoginHook

  • Performs many important tasks to set up both new and existing users
  • Creates home directory on local disk and links Library and MyAFS into central AFS file space
  • Installs any preferences that need to be manually copied into user's space
  • [Link to the script]

Security

Firmware security

  • In use for Solaris and Linux
  • In use for Windows
  • Last year, we began using it for all Mac OS X computers

Crypted passwd security

  • Root user is kept in /etc/passwd
  • Password is selected to be resistant to dictionary attacks
  • Might not be good enough anymore
  • Will investigate shadow password features in 10.2

Keying software

  • Most applications have been keyed for KeyServer
  • Used for copy protection as well as usage statistics
  • We had trouble keying some items last year, but I think it's better now
  • Sassafras will key Mach-O applications for us in the worst case

Installation and Maintenance Tools

Initial Install

  • NetBoot plus ASR
  • Booting into Mac OS X 10.2 over the network using the NetInstall variation of NetBoot
  • Likely to use NetRestore to automate and add graphic interface to command-line Apple Software Restore (asr)
  • Starting with a single NetBoot server but will add a second server in a load-balancing configuration for mid-summer 2003

Disk Maintenance

  • Using Radmind instead of RsyncX
  • Done configuring our use of Radmind, but still need to document it and add more applications