Center for Academic Computing
Penn State University
University Park, PA 16802
Center for Academic Computing
Penn State University
University Park, Pa 16802
Penn State Lab Environment
In response to student requests for help in the student computing labs, Penn State established five mini-help desks in five central labs in the Fall of 1995. Each mini-help desk had two consultants on duty. The students felt this was inadequate and so with the aid of additional funds, we expanded our coverage to eleven labs in the Spring of 1996. Fall of 1996 has thirteen labs with consulting services available eight hours a day, six days a week. Some labs have 1 consultant, some two on duty depending upon the number of machines in the lab. Since January of 1996, over 13,000 contacts have been logged by the lab consultants. This is a significant service to the students computing in the labs but is an administrative nightmare for User Support and for the lab consultants' supervisor. The number of students needed to cover all of the consulting shifts has grown from about thirty-five in the Fall of 1995 to almost one hundred this Fall.
Managing one hundred part-time student employees can prove to be quite a challenge for the supervisor. Student class schedules, multiple lab locations, personnel turnover, consultant support, payroll, and volatile work schedules are some of the concerns that the supervisor must address.
There must be a way to keep track of all the consultants and their personal information (name, current address, phone, etc.) Some of this information needs to be accessible to all, such as email address and current phone number. Since most of the employees are students, this information can (and does) change frequently. Students move, some leave for a semester, new consultants are hired, and some of them hopefully even graduate and move on to be productive citizens. This information needs to be available for the supervisor and the other consultants so that they can contact each other in case of emergency or perhaps to find a substitute on short notice. Although the main form of communication between all parties is electronic, there are times when we still must rely on good 'ole ma bell to contact people quickly.
Multiple Lab Locations
One of the more difficult problems stems from the fact that there are many lab locations where consultants are working at any given time. It is simply not possible for the supervisor to be in all places at once. We need to ensure that the consultant has reported to the proper location at the proper time. It is not enough to know that someone has worked x hours -- we must be able to record and verify where the person worked. This information is not only useful during the shift (so that the supervisor can see who is where at any given time) but it is also useful for tracking purposes in case there is ever a problem or complaint.
The lab consultants are paid hourly wages. We need to be able to keep track of each consultants' hours as well as be able to generate a payroll file based on that information.
This makes it vitally important that whatever system we use be accurate and dependable. With the number of employees we have, some form of electronic 'time-clock' function is required. This works hand-in-hand with having the knowledge of who is where at any given time. It is crucial that we have accurate information about the hours worked by each consultant. This data can also be further broken down for statistical purposes, such as lab by location or over different time periods.
Another problem that arises from having consultants in multiple locations (and without direct supervision) is how to support them. It is impossible for every consultant to know everything and it is important that they be able to rely on each other for information. If all the consultants were in the same location, it would be simple to forward a question to the appropriate expert, but this is not possible in the lab setting. An on-line conferencing utility is necessary to communicate between consultants and with the supervisor as well when assistance is needed.
Probably the most hectic part of the entire project is scheduling and rescheduling and rescheduling and resched....you get the idea. Students have perpetually changing schedules and constantly need to find replacement workers for their shifts. Also, many workers are on the lookout to pick up extra hours and they need an efficient way to find out who needs to find a substitute worker. It is important that the supervisor be able to know who needs a substitute (and why) and also who has taken over a shift for another worker. It is not only important to know that a substitute has been made, but it must be easy to find out who took the shift and who gave it up. It is necessary that we have a dynamic schedule that is updated on-the-fly and can easily show who has taken any substitute shifts so that we can know exactly who is working at any given time.
In addition to managing the consultants, it is also important to record some statistical data so that we can track our users and their problems. By collecting data from our contacts in the labs, we can better determine where and when to allocate our resources. The information we gather should be easily tracked and limited to information useful in making decisions regarding consulting in the labs. This information can also aid in our training program for new consultants as well as with ongoing training for experienced consultants.
To eliminate some of the problems just discussed, the Lab Manager was designed and coded. Following is a description of the Lab Manager software.
Lab Manager Software
The Lab Manager software is made up of the following pieces:
The next section contains brief descriptions of each item.
Lab Manager Server
The server process executes on a UNIX host, currently a Sun SPARC 10 running SunOS 4.1.3. The server implements the following functions:
The Contact Daemon
The contact daemon executes on the same host as the main server, and is responsible for adding contact records to the contact database. It can accept records from the server, or a CGI program which is executed by the local HTTP daemon. The CGI program is the result of a WWW page, by which the consultants can submit contact records from their favorite WWW browser.
The Telnet Client
The telnet client acts as an intermediate agent between a user's telnet program and the main server. After using telnet to connect to a particular port on the server's host, the consultant is presented with a menu and form based interface to interact with the server. The telnet client performs some rudimentary negotiation with the telnet program, to discover the proper terminal emulation and window size. The ncurses package is used to create the various windows, menus and forms used for conferencing, contact record, time clock, menu and scheduler functions.
The Windows NT Client
Our public labs have all been converted to use Microsoft Windows NT Workstation, so a NT client is under development. The functions are similar to the telnet client, but the presentation is much nicer. The NT client connects directly to the server process on the UNIX host, and communicates via the same protocols as the telnet client. Both clients get the items for the contact record menus from the server.
The Consultants Database
The consultants database is stored on the server host, and contains information including consultant's name, access ID and phone number. The database is indexed by the GNU database manager, using the consultants unique access ID as the storage key.
The Consultant Database Management Tool
The consultant supervisor can perform basic operations (add, delete, edit, list and search) on the consultants database with a WWW based management tool. A WWW page presents the supervisor with a form, which is then submitted to a CGI program to perform the desired operation. When adding a consultant to the database, the CGI program connects to the Penn State PH server to retrieve name and phone number information, based on the consultant's access ID.
The Contact Record Datafile
While working in the lab, the consultants are required to submit a contact record for each person they assist. These records contain student status, college affiliation, system type, problem category, lab name, time allocated to the problem, consultant's access ID and a timestamp. The contact records are stored in a flat file by the contact daemon.
The Contact Report Generator
The consultant supervisor can generate contact record reports by using a WWW based form and CGI program. The supervisor selects records by starting and ending date/time, and can select several different report types. More detailed selection criteria allow records to be selected by their field values, and the supervisor can also view raw data for individual consultants. The actual CGI program is a Perl script.
The Time Clock Record Datafile
Time clock records are stored by the main server as text records in a flat file. Each record contains a timestamp (to the nearest second), access ID, lab name, shift name and operation (in, out or adjustment). The supervisor can submit adjustment records for individual consultants, for special circumstances.
The Time Clock Report Generator
The consultant supervisor can generate time clock reports by using a WWW based form and CGI program, similar to the contact report generator. The supervisor can create a report of total consultant hours for a pay period, and clock in/clock out times for individual consultants. The CGI program is another Perl script.
Safeguards and Security
The Lab Manager software contains many safeguards and security checks, both to ensure that only valid lab consultants can access the software, and that they use it correctly. One of the keys to the whole system is the unique access ID assigned to each student. Penn State maintains a AFS Kerberos server containing all of these access IDs, and the server process authenticates a consultant's password by connecting to the Kerberos server. In order to use either the telnet or Windows NT client, the consultant must provide a valid access ID and password, and be present in the consultants database.
The WWW contact record form requires an different authorization procedure. The HTTP daemon limits access to the form and its CGI program, to users with an entry in the HTTP server's .htpasswd and .htgroup files. When a consultant initially requests the contact form, they are prompted for a user ID and password. The user ID is the same as their access ID, but the password is assigned locally, and need not be the same as their access password. In addition, the CGI program which accepts the form, validates the information provided. The consultant must be in the consultants database, all fields must be present, and the record must be submitted from a valid lab location. The WWW contact form is a holdover from an earlier project, but some consultants prefer to use it, over the other clients.
The report generators also use the HTTP user ID and password authentication mechanism. In addition, access to reports is limited to users in a lab administrators group, and can be limited to specific systems (by name or IP address), as well. At present, access to all WWW sections of the Lab Manager software is restricted to systems registered in DNS at Penn State.
The server process and contact form CGI programs both reference a list of lab names and valid IP address ranges. While a consultant can use either of the client programs to connect to the server process from any system, they can only clock in/clock out from a system in the lab. The same restriction applies to submitting contact records. Also, to ensure that the consultant is actually in the right place, they must clock out from the same lab from which they clocked in.
Consultants can connect to the server, clock in, then disconnect from the server: they need not be connected to the server for the duration of their shift. The server maintains an internal record of clock in times, and updates a copy on disk, as a precaution against abnormal server termination. The server also references shift scheduling information, and can force a consultant to clock out, if they are too far past the end of their shift.
The software was developed on a Sun SPARC 10 under SunOS 4.1.3. These additional software packages were used in program development or production:
The server, contact daemon, telnet client and WWW contact form CGI are written in C. The report generators are written in Perl (no Perl 5 specific features are used). The Windows NT client is written in Visual C++. Some sections of code were based on examples from W. Richard Stevens' books, Advanced Programming in the UNIX Environment and UNIX Network Programming.
 Andrew File System, from Transarc
 Common Gateway Interface
 HyperText Transfer Protocol
 World Wide Web
 RFC (Request for Comments) 854
 CSO phonebook/nameserver, developed by the University of Illinois
 Internet Protocol
 Domain Name System