---

Abstract

The Macintosh operating system was designed as a single user environment (i.e. home or office). The users configure the system the way they want it once, and from that point on, they have a customized system that they can grow used to. When Macs are introduced into a laboratory environment, the machines become multiple user machines, and this is where problems begin. The configuration a user has is the configuration left by the previous user. Configurations are not uniform or consistent from computer to computer, and this can add to the confusion of novice users.

This document will show Rutgers' approach in trying to solve the problems inherent in using Power Macintoshes in student computer labs. It will show you a unique system setup that requires minimal Systems Administrator intervention which can be done from a central location, no matter how many computers are involved.

Problem Overview:

If you were to buy a large number of Macs and install them in several different sites using only the system software that they came with, you would have many problems. Here are a few problems:

• There is no way to give your users full access to Finder and still keep your system clean.
  
  
• You would find yourself constantly repairing the system folder against user modifications. In order to upgrade or install new software you would have to go to each individual machine for installation. This would be a very time consuming process. You would have to find some way to protect your system software from user malice as well as some weird system corruption which may prevent the system from booting.
  
  
• We would like to store all existing programs we have on a Locked local hard disk partition but do not want to go to each mac to update them. In other words, we would like to centrally update all System and Application Software.
  There would be no way for you to keep a log of when and who used which machine and without this information, Rutgers Network services will deny any lab full access to the Internet for security reasons. To solve this problem, we will need a way to log access of a machine so we know who accessed the machine at any time. We will also need to make sure that each user has a computer account and we want them to use their existing (e.g. kerberos) username and password.
  
  
• Novice users would have trouble with basic features like Mounting network volumes and choosing printers and saving their work. You will also have a problem setting up a limited access fileserver without having to tell users the password to the server.
  
  
• You would have no way to prevent people from pirating copyrighted software on local drives. You could protect files from being copied on your AppleShare file server, but if you want your software to run quickly it should be stored locally. And, locally stored software is always allowed to be copied by the standard mac system. You also have to worry about how many concurrent running copies of specific software at any time, and make sure that this number does not exceed the licensed limit..
  
  
• On occasion you may want to hold classes in your labs and you would like to give notice to users before the scheduled class. It would be nice to inform users with a message on their screen of when these classes are held. This way they can schedule their commuting time around these classes.
  
  
• If these sites have servers, these servers should be synchronized. These servers also should contain continually changing software to put on the local machines. It would also be nice to have users mount and run networked software transparently.
  
  
• We want to use the network but we don't want Network dependency. Which means we still want access to the macs whenever the network is down.
  
  

The above are some of the problems that require hundreds of man hours to solve. It would take an army of computer support personnel just to keep the configurations similar on all of the machines. At Rutgers, I have created a solution that solves all of these problems gracefully, requiring only one full time support person to oversee its automation.

Rutgers Requirements Overview:

At Rutgers, we have computer laboratories that are open 24 hours. Some location are open without lab consultant to help users with their problems. At sites that have consultants, we can not depend on consultants to solve all problems with our computer hardware and software. This is especially difficult when the lab consists of Macintoshes, PCs, and XTerminals with thousands of programs to support. Because of this situation, we need to make sure that our machines are centrally administered and full automation is applied whenever possible.

To solve the problem above, we must satisfy the requirements as follows:

1. All Macintoshes must look and feel the same no matter what the hard disk size, or mac model. User experience should be the same from Mac to Mac.
   
   
2. Prevent non-Rutgers users from entering the lab and using the equipment via a login screen. aka. user must have an account.
   
   
3. Login program must work with existing user's Unix account.
   
   
4. Restore the system software to a known state after users finish using the Mac.
   
   
5. To speed up software access and reduce network dependency, store all software locally on a locked partition on a machine that has a big enough hard disk. On machines that have a smaller hard disk, software should be accessed from the server transparently.
   
   
6. Allow users to store temporary data on a hard disk.
   
   
7. Automatically and centrally update System Software and Application Software on user Macs and Servers overnight with no user intervention
   
   
8. Make sure that the machine has minimum software-related down time by implementing an Auto Repair feature.
   
   
9. Prevent user from installing new software.
   
   
10. Restore and reset Macintosh hardware Parameter RAM to a know state.
    
    
11. Provide ability for a new user to create a computer account if the user has no account.
    
    
12. Auto Set user's name, email address, server's address for Netscape.
    
    
13. Minimize user's ability to change user name and server address from inside Netscape for security purposes. This is done by hacking on Netscape itself to disable some of the Preferences Menu.
    
    
14. Informative Login screen which tells users the speed, the name, the model .
    
    
15. Ability to mount AppleShare volumes reliably. If the main server is not available, automatically switch to a backup server.
    
    
16. Screen Saver with Rutgers Logo and Live updating Scrolling News
    
    
17. Auto Logout features for user who leaves a Mac for too long a period.
    
    
18. Auto Locking feature for user who want to leave for a few minutes and not worry about loosing his/her access.
    
    
19. Ability to notify user on login if s/he has mail.
    
    
20. Ability to go to backup servers when network problems exist and alleviating network dependency.
    
    
21. Ability to show message of the day when user logs in.
    
    
22. Ability to access and save to users Unix Home directory from a Mac
    
    
23. Automatically notify user during login if the user has logged in more than once for security purposes.
    
    
24. Automatically select a printer residing in the lab and distribute printer load for lab that has more than one printer.
    
    
25. Make sure that we are not violating software copyrights.
    
    
26. Know who uses the computer at any time.
    
    
27. Must have statistics of usage which shows various usage by time/date and percentages.
    
    
28. Support for legally blind students.
    
    
29. Full access to MacOS finder so user can experience the whole mac look and feel.
    
    
30. Ability to set memory usage for specific programs without readjusting manually from Get Info option.
    
    
31. Auto Save feature which ask user to save based on settings for each program.
    
    
32. A Multimedia Help System.
    
    
33. Ability to set and reset AppleTalk Protocol
    
    
34. Ability to synch clock with a central server
    
    
35. Ability to restart on a crash automatically
    
    
36. Problem reporting mechanism to report downed machine or software problem and keeps track of action history.
    

Rutgers Solution Overview:

To solve the above problems, we could not find commercial software that satisfies our need, thus I had to come up with a mix of 3rd party solution and in-house software solution. You will see the list of them later.

We found that maintaining a uniform, consistent system folder on every machine by hand was impossible. We looked into alternatives such as Folder Bolt, but found most of them were clumsy and still did not offer a solution to lowering the amount of time it takes to upgrade all of the machine's system folders. We also look at AtEase, a software solution from Apple, but AtEase restricts user access to the finder.

Although it is not perfect and does not provide all our requirements, we still needed a program that would help us protect the system folder. For this purpose, we chose OnGuard which has more features than other program in its class. We chose OnGuard from PowerOn Software Inc. for its numerous features and flexible options and very good technical support.

OnGuard gives us an ability to protect our Mac System Folder from being damaged or destroyed by users. It has the ability to prevent users from adding system extensions and removing/adding files into the system folder. However, it does not prevent Installer from installing files into the system folder and does not provide us with a way to centrally administrater to our Macs.

We also found that we needed to use a hard disk management utility for Macintosh to keep all our software in synch. We found that RevRdist (pronounced "rev-are-dist"), a freeware from Purdue University, is the perfect program for our needs due to its flexibility.

With OnGuard, RevRdist and our in-house software, we have arrived to a centrally administered Macintosh lab which has almost zero non-hardware related downtime. The minimal down time is due to our implementation of the Auto Repair program, which is a combination of in-house program and the RevRdist program from Purdue University. The Auto Repair program works simply by manipulating the PRAM of the Mac, specifically the startup disk bits.

The solution that I have developed is now being used by all (about 600 of them at the time of this writing) Rutgers Power Macintoshes in every public lab at Rutgers University. This solution, unfortunately, is not hacker proof. The very nature of the personal computer makes it impossible to make any of it hacker proof. The intention of this setup is to ease Systems Administration and to reduce downtime to a minimum, as well as to create a homogeneous and user-oriented environment where the look and feel of the computer is preserved across multiple models of Power Macintoshes.

Rutgers Macintosh Setup

To make things work transparently to users and as effortlessly to me or my student workers, I have designed our macs as follow:

• Each mac has 3 partitions. The Partitions are named Boot Disk (200+MB), Application Disks (800 +MB) and Temporary Disk (100 MB ) . The sizes are not absolute. The most important partition is the Boot Disk partition, which should at least be 100 MB to count for future updates.
  
  
• The Application Disk partition is for storing Application software. For those Macs that have a big hard disk, storing all or commonly used software here is recommended to reduce network dependency and to speed up execution. No matter what the size of this partition is, the user will see the same list of software in this disk. To make this partition look as if it has all the necessary software, aliases to the server are necessary to small partition. The aliases must be created in a special way so that it is not server dependent to prevent the situation where the server is down and a backup server is mounted locally.
  
• 
  The Boot disk contains all the necessary system software. The Application disk contains keyed version (via Key server from Sassafras) of every software we have licensed plus almost a complete mirror of Boot Disk and Auto Repair system software. The Temporary Disk is to be used by users to store their files temporarily. This temporary partition can be set to any size that is appropriate for the size.
  
  
• Each Mac is connected to the Internet and is set to Bootp or DHCP to minimize IP number administration. Configuring each Mac to its IP address is time consuming and makes no sense in a lab environment. By using bootp or DHCP, all IP address, Name servers, gateway and subnet information are handled by the DHCP/bootp server which normally are Unix or Windows NT machine. The administration of the IP settings is done once at the beginning and occasionally edited when an Ethernet card are replaced to reflect the changes of the ethernet hardware address.
  
  
• Each lab has an average of 40 Macs and 1 AppleShare server or Novell Server running AppleTalk services and 2 printers. The setup is intentionally done this way because we wanted no network dependency outside the subnet.
  
  
• Every Macs is connected to RUNet. Each lab is in a subnet. In every subnet there is a AppleShare server or Novel Netware Server running AppleTalk services, SUN Server acting as the the local Login Server, Name server and Bootp/DHCP server.
  
  
• The Mac will also connect to a kerberos server during authentication, to Make Account server during account creation and to the local Unix server for account verification, logging, news fetch and software update information. etc. See Mac connectivity figure.

Before a Mac is placed in a lab, a manual setup has to be done. Fortunately, this only has to be done once and takes about 10 minutes or less. With the way the Mac is setup, future updates are done centrally and requires no manual setup on each Mac. This requirement is very important especially in a lab environment where it would be impossible to keep any setup the same without some kind of central administration.

Due to the number of computers and limited number of System Administrators involve, the Mac setup has to be easy and fast. To speed up the installation process, Build Disk was created. The Build Disk is a CD or a ZIP which consist of standard system software, some Apple Scripts and Utilities Application. To setup an out of box Macs, the following has to be done:

• Boot the new Mac with a Build Disk. The Build Disk contains standard Apple System Software with additional program called: Mount Local Server and Rename & Build.
• Get the Ethernet Hardware Address from the TCP IP Control Panel and enter it to a Bootp table on the Bootp server.
• Partition the hard disk to 3 parts.
• Execute the Mount Local Server program.
• Execute the Rename & Build program. At the end of this execution, the Mac will restart and go to Auto Repair mode.
• Force the Mac to update by pressing a special key combination to make sure that the Application Disk partition is synchronized with the Application Server.

The above process should take no more than 10 minutes to do. The last step will take from 2 minutes to 3 hours depending on the number of software being transferred to the Application Disk. There is no need to wait for this process to end. When the Mac is finished, it will restart with the login window and ready to be used.

When a user tries to use our Macs, they will be presented with a login screen above. The login screen comes with a few choices that the user has to select or entered in order to use the Mac. The essential requirements are Username, Password and their status. The Status menu groups the users into Student, Faculty/Staff, CS Students, CS Faculty, etc. The Mac will verify the user information, based on the status menu selection. If the user selects Student as his status, the Mac will verify the user information with the Students Account server.

Making an Account

It is important to note that all of our students, faculty and staff are eligible for a computer account. The computer account is basically an account to a SUN Computer running Unix OS named Solaris. Account creation is done by the user himself. Since every user is required to login before s/he can use an account, the user must have an account.

To create an account the user simply clicks on the Status menu and clicks the Make Account button. A window will open with details instruction and asks the user a few personal questions. Once the user answers all the questions, an account will be created at that instant. The user would then use that newly created account to login to the computer.

Logging in

Once a user enters his or her Username, Password, select a status and click enter, the Mac will check with the account server to verify if the user actually has an account. If so, the Mac will then contacts the authentication server to verify the user name and password -- at Rutgers University, we use kerberos server for authentication. Once the username and password info are validated, the Mac will:

• Inform the user that the access is granted,
  
  
• Record access to a log server,
  
  
• Notify user if he or she is logged more than once,
  
  
• Display message of the day if one exist,
  
  
• Check and notify for any new mail the user may have
  
  
• Depending on what options the user chooses, the Mac may connect to the user's Unix account and mount the user's home directory or mount a Course Material server. The ability to mount the Unix home directory gives the user a choice to save to or access data from the Unix Account Server.
  
  
• Depending on the model of the Macintosh, an Application Server may be mounted automatically.
  
  
• Sets Netscape Preferences file according to the user personal info.
  
  
• Then the Mac will choose a default printer for the user and present the user with the Macintosh Finder.
  See Choosing a Printer and Balancing Printer load section.
  
  

After the login process is done, user can run whatever program he or she like.

To run a program, users have to open the Application Disk and select the specific software package that he or she would like to run. See the Application Disk picture below. On a Mac that has a small hard disk, some of the icons shown in the Application Disk could be an alias to a folder stored on a Server. When the user clicks on this alias, the server is automatically accessed and the folder will open as if it is stored locally. Server Access is transparent to user and barely noticeable. The alias is important to keep the look and feel across Mac models the same from lab to lab.

When a program is run, the Key Server is contacted to see if there is enough licenses to run the software. See Preventing Software Piracy and Flexible Software Administration section. If there are enough license remains for the particular program, it will run without any problem. Otherwise, the Mac will tell the user that :

• there is no more key available to run the program.
• presents the user with options so the user can be notified when the key is available
• return the user back to the Finder.

In some circumstances, a document fails to open because memory allocated to the Application is not big enough to load the document. In a normal situation, a user is asked by the MacOS to resize the memory allocation using the Get Info menu. Unfortunately because the program is stored in a locked partition or on the server, the user does not have the ability to change the memory allocation of the program and prevented from opening the document. On Rutgers Macs, this is not an issue. All the user has to do is to rerun the program while holding the CMD key and a window will open with options that allow the user to change the memory allocation at the instance. See How to set Memory Allocation for Programs

In the lab environment, keeping the look and feel the same across all Mac model is important because of the number of users involved. Because users move from one lab to another and machine to machine, keeping the look and feel of the Macs is very important to avoid confusion.

With Rutgers Power Macintoshes, all programs are accessed from inside the Application Disk partition. However, because not every Mac models come with the same size of hard disk, we can not store the same number of applications locally. This means we have a problem keeping the look and feel the same across all Mac models. For a Mac with a big hard disk space, we stored all programs locally in the Application disk partition. On a Mac that has smaller hard disk, we store aliases to program that reside in the server.

When a user clicks on the program icon, the program will be run independent of its location. If the user happens to click on an alias, the program will run transparently from the server. Although there will be a noticeable slowness, the user will not be confused because the look and feel is the same on all Macs.

The key to keeping the look and feel the same across all Macs is RevRdist. The setup on every Macs is based on a master server. The server contains all the necessary software that each mac should have. Via RevRdist, a mirror image of the server is copied on to the Application Disk partition. On a Mac that has a smaller hard disk, only alias to the application folder is copied locally. This alias is created in such a way that it is independent of any server to anticipate the situation where the default server is unavailable and backup server is mounted. See. How does the Automated Software Distribution Work ? section.

When the user is done using the Mac, the user is expected to log out. The purpose of log out in user perspective is to make sure that the next users do not get their hands on your files or send email as you. In system administration perspective, log out is used to restore the System Software to a known state so that every time a user logs in it is always in the same known state.

There are two ways that log out could happen on Rutgers Multi user Power Macintosh System. The first log out is done manually by going to the Special Menu on the Finder and select Log out. The second log out option is an auto logout feature which happens 15 minutes after a user leaves a Mac without logging out. Autologout is added to prevent the user from locking the Mac and do other things while we have a lab full of users waiting to use the Mac.

At logout many things happen. The Clean & Save Init which is the core of this Multi user PowerMac system makes sure that the Mac is restored to a know state. At Log out the following happens. The Mac

• quits all running Application.
  
  
• cleans up the Temporary Disk.
  
  
• unmounts any mounted network volumes and ejectable volumes.
  
  
• writes a log to the log server that the user is logged out
  
  
• notifies that the user is logged out
  
  
• changes the state of OnGuard to Manager so that changes can be applied to System Software in the Boot Disk.
  
  
• executes a special RevRdist setup called SynchIt which will then refresh the copy of the System Software in the Boot Disk partition to a known state based on the Master System files stored in the Locked Application Disk partition.
  
  
• changes the state of OnGuard to Guest to lock the System Software in the Boot Disk.
  
  
• shows the login screen for the next user to login.

After a user logs out or after the Mac is started or when it is idle, the Mac shows a login window. This login window will stays on the screen for about 5 minutes.

If there is a user using the Mac at the time, the login window puts the name of the user in the User name field but prevent users from changing the name. The locking of the user name is to prevent other user from using the Mac. The Mac shows a message on the screen noting that it was locked by the user and that it will automatically unlocked after 15 minutes.

After about 5 minutes of showing the login screen and if there is still no user, the Mac will go into a screen saver mode. At this state, the mac will connect to the news server every 30 minutes beginning at the start of the sleep time to obtain updates of the news feed. During this screen saver mode, the news is displayed as scrolling text in the bottom of the screen with a floating Rutgers logo.

The screen saver mode is turned off when someone moves or clicks the mouse or presses a key on the keyboard at which time the Mac presents the user with the same login screen.

To maintain the System Software and Application Software in a personal computer is not an easy job especially if the computer is used by many users in a 24 hours period. To maintain a lab full or University wide personal computers would be almost a near impossibility even with an army of people. To centrally manage this computer by one person would be a dream come true.

At Rutgers University such a dream has come true on our Macintosh Computers. It has come to a reality with the help of a combination of great software such as RevRdist from Purdue University, OnGuard from PowerON Software and home made software called Clean & Save, Auto Repair and a lot of simple but effective tricks.

Lab Server to Lab Macs Distribution

The Mac Software Distribution system at Rutgers is set to work nightly between 4am-5am in the morning. During this update time, the Mac will check with a Unix server to see if it needs to update the system software by checking at the latest Master software version. The Mac will compare its local software version and the version it received from the Unix server. If the version number is different, the following will happen:

• The Mac will automatically mount the Application Server.
  
  
• The Mac will unlock the local Application Disk
  
  
• The Mac will find the specific Update program based on the model of the mac.
  
  
• A specially setup RevRdist called Update.6500 (for PowerMac 6500) will get executed. This updater will update the Application Disk using the Application Server as the master image. Only the changes is basically updated.
  
  
• When the Update process to the Application Disk is completed, the Application Disk is locked.
  
  
• The Mac then tells OnGuard to switch to Manager mode so changes can be made to the Boot Disk.
  
  
• The Mac then executes a special RevRdist setup called SynchIt which will then refresh the copy of the System Software in the Boot Disk partition and restores the Boot Disk to a known state.
  
  
• The Mac then tells OnGuard to switch to User mode and Restart the Mac.
  
  

Central Server to Local Server Distribution

At Rutgers, we have local servers at almost every lab to ease network traffic and to speed up access for those Macs that need software access from the server. These servers become the master server for the Macs in the lab. These server are also used as backup servers for other labs in case the local server at the lab goes down. The transition from local server to backup server is handled by the Clean &Save program during login time and are transparent to users. Because these local servers are used as a master server for the local macs, they also need to be updated. In a university environment where there could be 10 to 20 labs, updating the server one by one is not practical and this is where we need a special set that handle servers update.

At Rutgers the servers are set to update automatically from a Central master server. Changes that needs to be applied to all Macs in the University Computer labs are done on the Central Master Server and these changes will propagate to the local Macs overnight. To make sure the changes are propagated to the local Macs, Server updates are done a few hours before the mac update time.

There are two ways we do our server updates. Both ways involve RevRdist. The first method is a PULL method where the Local servers connect to the Central Master Server and start the mirroring process. This can only be done if all servers are Mac servers. In this case RevRdist is configured at specific time to connect to the Central Server and synchronize its software. This method is the fastest of the two because all local servers can connect to the master server and synchronize themselves at the same time

The second method is a PUSH method where the Central Master Server actually pushes the data to the Local Servers. This process typically happens where the Central Server is a Mac and the Local Server is a non Mac server such as SUN, Novell or NT servers running AppleShare compatible software. In this case RevRdist is configured at specific time to connect to the Local Server and synchronize its software. This method is slower because the server can only connect and distribute software to one local server at the time.

One of the most important factors in setting up computers in a laboratory environment is printing. To print to a printer on a MacOS, one has to choose a printer via Chooser. The Chooser Apple menu is a multipurpose utility mostly use for choosing printer drivers and network servers. The MacOS user interface for Choosing a Printer has not been updated since its inception.The Chooser user interface is a bit awkward if not confusing to most novice users.

Our experience in the lab shows that almost every new user is confused about printing. The issue is really due to choosing a printer. Once the user understand what they have to do, things would normally work just fine until a printer problem occurs. With the number of problems we have due to choosing a printer, program called Local Printer was created which sole function is to choose a printer automatically when a user login.

The program will basically choose a printer automatically based on the IP number of the Mac. If there are 2 printers in the lab, Mac 1 will get printer 1, Mac 2 will get Printer 2 and Mac 3 will get printer 1 etc. In the lab with 40 Macs, that means each printer has 20 macs that will print to it and in effect balances the load of the printer. At the same time, the user will never have to choose a printer again. In the event that a printer is down, the Local Printer program is smart enough to know that the printer is not available and distributes the load evenly to the remaining printer.

The Local Printer program currently works with LaserWriter 7.x software and is not yet compatible with LaserWriter 8. LaserWriter 8 is not RevRdist friendly and therefore we do not use it as our default driver. For those users who must use LaserWriter 8, they have to choose the driver and printer manually.

From time to time the MacOS Computer will crash. This is mostly due to poorly written programs and the lack of memory protection on a Mac Operating System. Sometimes the crash also damages the System file itself which put a Mac into a question mark state. At this state, the Mac fails to find a system software and continues to look for it until a bootable system is found. In other words, if no system software is found, the Mac will not start and become unusable until the problem is fixed. This kind of problem can be time consuming and can lead to high down time to many Macintosh computer in the lab. When you have 6,000+ users and 600 Macs, down time is not something you can afford because it could lead to waiting lists especially during peak time. To minimize down time caused by a software problem, a simple solution which is called Auto Repair was created. This Auto Repair feature is based on a simple mechanism. It heavily dependent on RevRdist, PRAM setting and an In house program called Auto Repair init. The way it works is as below:

• When the Mac boot from the system software resides in the Boot Disk partition, the Mac startup disk PRAM setting is set to the Application Disk partition which contains the Auto Repair System software.
  
  
• The Application disk contains a special Auto Repair system, a combination of the Auto Repair init, an alias to a specially setup RevRdist software and an Apple Script program called Bless (which sole function is to Bless the newly repair System software).
  
  
• At the end of boot time before the login window is displayed, the Mac startup disk PRAM setting is set back to the Boot Disk partition.
  
  
• In the event that the Mac fails to boot completely from the Boot Disk partition, the Application disk partition is automatically used as the startup disk and the AutoRepair system will be used as the default system.
  
  
• When the Auto repair system is loaded, it would automatically execute the RevRdist alias called Auto Repair which will recopy all the system software to the Boot Disk partition from a mirror copy stored in the Application Disk.
  
  
• After the system files are restored, Auto Repair init will execute an AppleScript program called Bless which blesses the newly restored system folder in the Boot Disk partition and close all the windows.
  
• Next, the Auto Repair init will reset the PRAM setting for the Mac startup disk back to the Boot Disk partition and reboot the mac.
  

The auto repair software also works in certain situations where part of the system software such as INIT or Control panel were corrupted, and the mac never fully booted and crashed. This works because at boot time the Mac startup disk PRAM setting is set to the Application Disk partition. After the crash, the Mac will automatically boot from the Auto repair system software of the Application Disk partition and Auto repair init will start the process of repairing immediately.

As you can tell, the purpose of the AutoRepair INIT is for software execution scheduling. It basically tells the finder to execute RevRdist alias called Auto repair, Bless the newly created System Folder, Set the PRAM setting for the Startup disk and reboot the Mac in the right order one after another. The combination of RevRdist, Auto repair init and Bless script are the keys to this to Auto Repair system.

It is important to note that this solution only solves software related problem. It does not solve hardware related problems. With this in mind, our evaluation on this Auto Repair setup is considered as Excellent. Since its implementation, this Auto Repair feature has reduced the Macintosh downtime caused by System Software problem to barely negligible amount of time. The system has worked perfectly, routinely without any problem and dutifully repair any damaged system software in the Boot Disk partition without any user intervention seconds after the problem existed.

Protecting Copyrighted software was a very difficult and time consuming effort and was not 100% effective. Software piracy was a common daily activities among students. They came to the lab, copied whatever software they needed and brought it home to use in their own home computer.

The arrival of a program called Key Server from Sassafras Software has help eliminated problem with software piracy completely in our labs if not at Rutgers University. Key Server is a software metering which allow us to keep track of concurrent running copies of software. With Key Server we can keep track of Application usage as well as manage software licenses efficiently.

Software management is done centrally and only once. Before any program is released or installed on a Mac, the program is first keyed using the Key Configure, a program that comes with Key server package. The key Configure basically creates a new copy of the program and adds a few code resources in the new keyed program. Once the program is keyed, it is ready to be released. It can be released to as many Macs or servers we like without worrying about the license issue. The keyed program will not run unless it can find the key server which decides if a program is allowed to run. To manage software licenses, one only has to connect to the Key server and change the number of concurrent license allowed centrally.

Auto Save is one of the most useful features that people like and dislike. It is a feature that helps users save their data every so often after a specified number of minutes, clicks or key downs. Because of the variety of likes and dislikes from users, we had to come out with very flexible Auto Save features which allows the user to control Auto save settings program by program. Most existing Auto Save software are globally set which means their settings are set independent of what applications are running at the time.

To set the Auto Save for each program, the user simply clicks on the 's' labeled green square box at the top right corner of the screen. See figure in Rutgers Macintosh setup section above. Once clicked, the dialog box above will open showing all the current Auto save settings for the running application. See figure above. The user simply clicks on what options that need to be changed and click the OK button to enable it. All Auto save settings are saved in the Auto Save Preferences file and can be distributed to all Macs if there is a need to make sure that all Macs Auto Save setting the same. Changes to Auto Save on a local mac is temporary. Once a user logs out, the setting will revert back to the default setting.

Rutgers Auto Save program also has some additional functions. Because of the similarity in function, the Auto Save program also sets Volume level and Synchronize the Mac clock. When the user switches from program to program, the Volume level and Auto Save settings are set and Mac's Clock is synchronized.

The Clock Synchronization feature was created to make sure that the Mac clock is in synch with a Unix time server. The configuration for the time server is very flexible and fault tolerant. During Clock Synchronization, the mac will look at a time server on its subnet and if it failed to find a working time server, it will then go to a list of backup time server. The ability to look for a local server then backup servers is essential to contain most of the network traffic local to the subnet as well as to make sure that the mac will still function when its subnet is totally cut off the network. This Clock Synchronization feature has totally eliminated the need to adjust mac clocks twice a year for enabling/disabling Daylight Savings Time. The mac clock is always in synch with our Unix time server and there no need to ever worry about the Mac clock not being accurate.

When a Mac software is launched, it allocates a certain amount of memory. The size of this memory block is set by the programmer of the specific program. It basically tell the operating system that this particular program needs the certain amount of memory before it can run and no one else can access this chunk of memory. This setting can be changed by users before the program is launched by going to a GetInfo file menu on specific program.

Because the way Rutgers the Power Macs are set up, all Application programs are mostly stored on a Locked Local hard disk. It could be very time consuming to change the amount of memory allocation for a specific program. One would have to go to each PowerMac, boot it with a special System Disk, unlock the Application Disk partition, find the Application that needs its memory allocation adjusted, GetInfo on the program and set the memory block. Certainly one can set this memory allocation first before distributing the program to all the macs, however, our experience shows that sometimes there is a need to change the memory block after the program are distributed. This is where we need to figure out a way to centralize this particular solution.

The solution to this problem is with our developed program called Memsizer. This program addresses the above problem effectively. With the Memsizer loaded at boot time, the user can adjust the memory allocated to a program even if the program is stored in a locked hard disk. The changes can then be distributed to all Macs without actually changing the program itself, instead the changes are done by distributing the a small Memsizer Preferences file.

To change the Memory Allocation of a program, all one has to do is double click on the program icon while holding down the CMD (Apple) key. A Dialog Box will appear showing the user the current setup. Once the new memory size is set, the user has option to Save it. Clicking OK will continue the launching process and the program will run at the new memory size.

This same program also has a hidden feature which prevents user from installing new software on the Macs. It simply rendered any known installer unexecutable.

Even with the current setup, there are times when a visit to a Mac is required in order to fix the problem. Fortunately these visits are limited to special issues that requires human intervention. Such issues occur when the hardware itself breaks, the hard disk partitions get damaged, intentional destruction by the user or software bugs cause certain unexpected behavior. Other than the above problems, our Multi user system has worked wonderfully.

Updating Application Software, System Software and miscellaneous changes can now be done centrally on the Central Application Server. These changes are propagated to the lab's Application Server and distributed to the lab Macs during its update period. These changes normally takes place overnight unless there is a user on the Mac during the update period. In such case, the Mac will retry to update in about 32 minutes. If the user is still using the Mac, no update will occur on this Mac until the next update period.

When updating the Central Application Server, caution is advised because mistakes done on the Central Application Server will propagate to the lab Macs overnight. In a situation where important parts of the system are changed, multiple tests should be done to make sure that the new system software will work well. The same care should also be done when changing any files related to the Update, Auto Repair and Sync function of the system. In the event where mistakes are done to the important files, a visit to each machine may be necessary to fix the problem. This is why special care is advised to make sure that such mistakes do not happen when updating or changing any part of the System software.

The combination of home grown software, public domain and commercial software play a crucial role in getting this Multi user Power Macintosh setup to become a reality.

The setup enables us to make a personal computer into a multi user computer with the ease of systems administration. It is a centralized solution which requires a very minimum amount of systems administration. It is relatively secured and it provides a complete Macintosh experience to the user via Mac OS Finder. It enables us to gather live statistics as well as track user's usage pattern in term of software and hardware. It keeps us from violating software copyrights as well as enables us to manage our application licenses efficiently.

The Auto repair feature reduces a lot of unnecessary downtime to the Power Macs and eliminate the necessary requirement for the System administrator to visit and repair each down machine personally. The Synchronize feature cleans up each machine to a known state and the Login screen makes sure that each user are authorized to use the machine as well as track who uses what machine and when.

Overall, the setup we have at Rutgers has saved Rutgers a lot time and money. It virtually eliminates unnecessary visit to each mac whenever any software needs to be installed. In fact, the system works so well and that it does not require more than one person to handle all Rutgers Macs.With this setup, the number of Macs does not really matter at all because to manage 1 or 1000 Macs, it would take about the same amount of time. The most time consuming process of all is the original setup which take about 10 minutes for each Mac. Unlike the promise of the non existence thin client Network Computing platform, this is truely a low maintenance Central Administration System that has reduced the cost of ownership of the Macintosh computer at Rutgers University. It is based on a personal computer instead of a thin client which means it has the flexibility and power of a personal computer with the ease and cost savings of Network Computer devices.

By the nature of the Personal computer, it is impossible to make this setup 100% secure. In fact, any user who has some knowledge of Macintosh OS can easily break the setup. This problem is partly due to the fact that Power Macintoshes do not require Password for users to change is Parameter RAM and the fact that there is no way to prevent users from booting of other than specified Hard Disk. Apple never cares about these features. It is ironic that Apple biggest customers are from education and yet the needs of education Systems administrators are not being met, in fact, it is mostly ignored especially in the area of Systems Administration. With this in mind, it is possible that users who have the intention to by pass the setup can do so just with a little knowledge on how the MacOS system works.

The following list shows the list of software used in order to get the whole system to work. Some of the software is running on the local Mac and some are running on a Unix Server or a PC. The Mac end consists of Extensions, Apple Scripts and RevRdist Applications. The Unix end consists of Unix daemons, standalone applications and CGIs (common gateway interface) for WWW access. The PC, not required, is running as a AppleShare compatible server.

The software consist of freeware software, home made software and commercial software. When this system was first conceived, every efforts was made to make sure that freeware software were used. Wherever it is possible, a homemade software is developed and it is preferred over commercial software. These efforts helps cut down the cost of the setup.

Rutgers Developed Software at the Mac end

Auto Save (System Extension)

Designed by Hanz Makmur
Programmed by Hanz Makmur & Theodore Wu
Part of Clock setting routines - Copyrights 1992 by University Michigan - Robert J. Churchill - Authman Project

• Auto save can invoke a save command after a specified time, clicks and characters typed.
• Allows different settings for different applications. Settings include auto save by time, key press, and mouse click.
• Allows you to set the volume differently for every application in memory.
• Get and Set system time and date from a networked time server. No more worry of daylight savings time.
• This program is accessed via top-right corner of the screen. It shows as a green box with a letter 's'.

Designed by Hanz Makmur
Programmed by Theodore Wu & Hanz Makmur

• lets you set the amount of allocated memory for program without going to get info and set it there.
• Prevent users from running installers by telling users that such program can not be found.

Designed & Programmed by Hanz Makmur
Part of PRAM code is Copyrights 1993 oleg@ponder.csci.unt.edu (Kiselyov Oleg)

• Software execution scheduling.
• Set the PRAM setting for the Startup disk

Designed & Programmed by Hanz Makmur
Part of TCP/IP routines are Copyrights 1992 by Steven Falkenburg - TCP Library

• Sets chooser name to IP name of the machine
• Sets Boot disk name to IP name of the machine. This feature is not used for Rutgers Macs any more.

Designed by Hanz Makmur
Programmed by Hanz Makmur with help from Theodore Wu.

Part of codes for Kerberos Section are
- Copyrights 1991 by Massachussette Institute of Technology
- Copyrights 1992 by University Michigan - Robert J. Churchill - Authman Project
Part of TCP/IP routines are Copyrights 1992 by Steven Falkenburg - TCP Library
Screen Saver code is Copyrights 1991 by Christopher Tate of Pennsylvania State University
OnGuard Service is Copyrights 1997 by PowerOn Software, Inc - John Wallace
Part of PRAM code is Copyrights 1993 oleg@ponder.csci.unt.edu (Kiselyov Oleg)

• Force access to a Mac thru a Login window.
• Online Video Help, and text help
• Has access to White pages server
• Has access to MakeAcct server which lets the user create an account if they don't have one.
• Has access to Rutgers WWW Server lynk interface.
• Built in Screen saver
• Allows user to Lock screen temporarily
• Has Autologout feature
• Built in Temporary Disk Cleaning service.
• Built in Ability to Set Netscape prefs to reflect user setups.
• Built in Message of the day functions.
• Informs users if they have new mail
• Auto Update feature which update macs every night via RevRdist
• Auto Synch feature which cleanup Boot disk after each user logout via RevRdist
• Auto set to auto repair mode when mac fail on boot.
• Auto Repair feature which replace the content of Boot disk in the event of failure to boot or essential software are missing.
• Logs computer access to a Unix machine.
• Talks to Kerberos servers for Password authentication.
• Talks to Unix machine for user access verification
• Bult in Auto Lock/Unlock of hard disk partition which are used during Synch.
• Built in OnGuard Services for switching OnGuard services
• Set and Reset PRAM to a known state
• Multiple configuration option for different model of Macs.
• Auto Mount multiple AppleShare network volumes from multiple servers.
• Auto connect to backup servers if default server failed (AppleShare, Unix, Kerberos)
• Subnet specific configuration to allow mac to function when the network fails.

Designed by Hanz Makmur & Steve Ledzian
Programmed by Steve Ledzian

• Online help for beginners
• Multimedia format

Designed & Programmed by Hanz Makmur

• let you tell Netscape to open pre configure URL. This small program contains URL and shows up as an application.

Original code from Apple Develop CD. (Surfer)
modified by Hanz Makmur & Theodore Wu

• A small terminal program that connect users to make account server.
  

Original code from Apple Develop CD. (Surfer)
modified by Hanz Makmur & Theodore Wu

• A small terminal program that connects the user to White pages server.
  

Original code Rich Williams - Bare bone Player.
modified by Hanz Makmur

• A small program that plays Video help System.

Designed & Programmed by Hanz Makmur
Part of TCP/IP routines are Copyrights 1992 by Steven Falkenburg - TCP Library

• Smart program designed to Auto Select an appropriate printer based on the IP number of the mac.
• Built in backup features that chooses backup printers when default printer is down.
• balance printer load by assigning equal number of macs to each printers.

Designed & Programmed by Hanz Makmur

• Small Apple script Application used to Bless the newly built and repaired System Folder.
• Used whenever System Software is updated, synchronized for copied the first time.

Designed & Programmed by Hanz Makmur

• Small Apple script Application used to setup a new Macintosh.
• This program is used only once on each Mac during setup after the Mac hard disk is partitioned.
• It renames the partition and copies the necessary initial software needed to start a mac and reboot.

Designed & Programmed by Hanz Makmur

• Smart program designed to Auto Mount a Local AppleShare Server.
• Built in backup features that chooses backup server when default server is down.
• Used when setting up the Mac for the first time.

Rutgers Developed Software at the Unix end

in.maclogin

Designed & Programmed by Hanz Makmur
Maintained by Steve Ledzian

• A Unix Daemon program
• Keeps track of Mac usage.
• Notify MOTD when user login to the mac.
• Inform user when it finds out that user login on multiple machine.
• Synchronized logs between multiple in.maclogin daemons.

Designed & Programmed by Hanz Makmur
Maintained by Steve Ledzian

• A Unix Daemon program
• Translates user name to Rutgers Unique IID which is used by kerberos server.

Designed & Programmed by Hanz Makmur & Steve Ledzian

• A small Unix program, executed by CRON.
• Tallies usage stats

Designed & Programmed by Steve Ledzian & Hanz Makmur

• A small Unix program, executed by CRON on a local server.
• Synchronized login/logout tokens with central in.maclogin server.

Designed & Programmed by Steve Ledzian

A small Unix program, executed by CRON.
computes usage stats into graphable data

Designed & Programmed by Hanz Makmur & Steve Ledzian

A small Unix program, executed by CRON.
Warns users via email when they logout improperly
Removes IP entries of machines that have crashed or been logged out improperly

---

World Wide Web Software

--currently many of these CGI are no longer being used due toand privacy issue--Fall 1999

In order to integrate our Macs to the new development in the internet, we established our own home page. Included in the home pages are CGIs which allows us to monitor Mac access, Mac usage stats etc... and provides online documentation such as this one.

• A small Unix program, executed thru WWW access.
• Connect to login server to get a list of active users and list users currently using a computer

• A small Unix program, executed thru WWW access
• search usage archive
• generates usage graphs to be view thru a WEB page using data gathered by countem and makepercent program.

• A small Unix program, executed thru WWW access
• Looks for user information using Rutgers White pages database

• A small Unix program, executed thru WWW access
• searchs to see when a user was last logged in
• searchs to see when user last used a particular machine

• A small Unix program, executed thru WWW access
• reads recently changed news group announcements and display on a web page.

• A Filemaker database front end to the WWW using Lasso
• A mechanism that is used for a user to report equipment problem and track a problem status
• Notifies related party about the status of the problem.
• Searchable and modifiable by site manager.
• Direct link to inventory database.

Columbia AppleTalk

• implements the AppleTalk protocol stack on a variety of UNIX machines.
• provide an AppleShare 2.1 compatible server (aufs),
• provide a LaserWriter Spooler (lwsrv)
• provide a program to print to LaserWriters (papif).

By Purdue University

• restores individual hard disks to a configuration specified
• copies files from the server to the client as needed based on a preset setup.
• Fast and Free.!

By PowerOn Software

• Control access to System Folders
• Control finder features but gives users experience the real Macintosh interface.
• many more. See http://www.poweronsw.com/html/on_guard.html

By Sassafras Software, a Software License Metering

• It allows the systems administrator to track of concurrent license and prevent software copyrights violation.
• centralizes software license server and not server specific.
• Provide usage statistics.
• Has backup servers to prevent total lockout.
• many more. See http://www.sassafras.com/

By Blue Globe Software

• It allows the systems administrator to lock the keyboard, mouse, disk drive.
• For Rutgers, it is used to lock the mac servers from unwanted hands.

By Karl Pottie <karlp@macbel.be>

• Control Panel/system extension which will restart your Macintosh after a System Error (bomb) or a Freeze-Up has occurred.
• AutoBoot ensures maximal availability of unattended Macs

By Apple Computer Inc

• Function as an Application Server

By Novell Inc

• Function as an Application Server for the macs when AppleTalk support is enabled.
• Used only an a certain lab that consist of PCs and Macs.

By Microsoft

• Function as an Application Server when AppleTalk support is enabled.
• Used only an a certain lab that consist of PCs and Macs.

Hanz Makmur is a Systems Programmer at Rutgers University - Laboratory for Computer Science Research Computing Facility. He has worked for Rutgers University since 1985. He started as a part time Micro Computer consultant and a Lab Manager and then in 1990 became a full time Rutgers employee as a Systems Programmer for Computing Services. He graduated from Rutgers in 1989 with a BS degree in Electrical Engineering. He works with Sun Workstation running Sun OS and variety of microcomputers running MacOS and Windows 3, Windows95 and WindowsNT but he prefers Macintosh OS above all other OSes.

Because a lot of the software above are designed for Rutgers University specific environment, it will be difficult to release the software to the public. The Rutgers developed software on the Mac were designed without Mac GUI because they only need to be configured once and require that the Systems Administrator to configure them using Resedit. Releasing such software to the public will flood me with lots of questions that I am not prepared to handle. However, if some educational organizations want to use this Multi user system, I would consider spending time on consulting basis to adapt the software above to your environment and provide you with the software free of charge.

The sources for the above software are not available publicly.