Linux Lab Configuration Profile (2002)

This document is no longer being maintained. See the latest document.

Table of Contents

Top

The Linux lab configuration is constrained by:

* The Dual booting environment - Windows & Linux
* The size of the disk on the PC
* Security issues related to the OS and user home directory access

Shared Systems developed the environment under these constraints to
fulfil the teaching requirements of the Faculties.

This document profiles the current Linux lab configuration.

Top

Linux is currently deployed by Altiris Labexpert software. This
software is used by the Microcomputers Team to replicate Windows and
Linux disk partition images across a group of computers in labs.

The imaging of the  DOS and Windows partitions is easy, however other
partitions are imaged as "raw" partitions which are dependent on the
geometry of the disk it was imaged from. Due to not all hard disks
being the same, the success rate is difficult to predict when
attempting to do a geometry dependent partition image to a group of
same model computers at Monash. To work around this, a separate image
has to be built for the other computers. For this reason, Linux is
deployed using a staged installation which is able to be used with the
imaging software. The first stage of the Linux install prepares the
partitions for the second stage of the install, which is explained in
the next section.

The Linux image initially comprises of three blank NTFS (Windows)
partitions, with images of the kernel, initial ramdisk and a bootloader
installed in a hidden primary partition.  This partition also contains
the image management software and the OS boot selector for the dual
environment. In this way, all of the partition images are either DOS or
Windows partitions, as per the explanation in the previous paragraph.

Top

Lab managers have to boot Linux twice after imaging to ensure that each
lab computer completes the second stage of the Linux installation.

The first boot prepares the deployed partitions for Linux. Three
partitions are used, one each for root, swap and cache. The cache
partition is a Linux partition used for keeping copies of the files
used to populate the root directory, and files specific to each
computer.

The second boot initially populates the cache partition from a Linux
lab server with the files required for the root directory. The
transaction currently requires that each workstation downloads about
36MB of files. The files required are compressed into several archives.
Each archive is only downloaded again from the server if the server
version has changed, usually when recommended vendor software upgrades
are applied during semester that affect the files archived. The
checksum for each archive file is compared between the server version
and the copy on the workstation to achieve this.

During the second boot, each workstation will configure its own shared
library cache. The cache is required for normal operation of user
programs. This operation requires access to library files stored on the
lab server, and may take up to 600 seconds to complete per workstation
depending on the number of workstations performing the operation.
Reconfiguring of the library cache during semester is only required if
the local cache is not accessible, or after major shared library
installations. The latter only occurs when urgently needed;
workstations are notified by the lab server.

Top

Required system processes such as the system logger are initialized at
each restart of Linux. The list of processes is customized for use in
the lab environment. In addition, a separate file of jobs to be
performed at boot time is accessed from the lab server. This list is
kept on the lab server for security and ease of updating. It handles a
few tasks such as: installing urgent updates to the boot files (mainly
the initial ramdisk); configuring floppy, CD-ROM and Zip drives;
rebuilding the shared library cache if required; downloading the
XFree86 (X Window System) configuration for the particular lab,
installing user information files for logins; and other miscellaneous
configuration items which are not part of the previous process
initialization.

Currently, the /usr file system which houses the majority of programs
available is accessed on a nearby lab server by each workstation using
the NFS protocol. The nearest lab server is selected during boot and
the file system is configured on the workstation. Other software may
reside on non-ITS servers, these are are provided by faculties, and are
accessed using NFS as required by the user. Due to this configuration,
it is possible to deploy major software packages and updates to the
Linux labs during semester with no need for re-imaging. The
configuration is also more secure due to access to the /usr file system
being read-only and stored separately from the workstations. However,
NFS is network dependent, and network outages or inconsistencies can
cause problems, and occasionally, downtime for the Linux labs. The /usr
file system currently manages about 3.2GB of software.

Top

Linux accounts are processed by CRUX. User information is stored in the
Monash Directory Service, and authentication details like the user's
password are stored in the Kerberos service. While the user may be
known in Kerberos as soon as the CRUX transaction completes
successfully, the account will not be available until the next day. As
well, CRUX manages the creation of a home directory on the central NFS
home directory servers for the user. To reduce the load on the Monash
Directory Service, login information for Linux users is processed into
a file which is replicated among the Linux lab servers, which is
replicated on to each workstation during boot time. The production of
the Linux user information file occurs early each morning; no user
passwords are distributed in the file, all user passwords reside in the
Kerberos service. An exception to this is printing.

At the login prompt, users enter their Unix username and Linux password
to access Linux on the workstation. On success, their home directory is
mounted from the central NFS home directory server and the message of
the day is displayed. On the occasion that NFS home directories are
unavailable, the user is logged into a home directory on the
workstation. Workstation home directories are not persistent, it is
dependent on the user to copy their work elsewhere if desired.

User access is authenticated in two stages, firstly there must be an
entry for the particular user in the local database, which is
replicated from the lab server during the Linux boot. Second, the user
must be in the Kerberos database and must have a valid password to be
authorized. The Kerberos authentication stage also authorizes the
workstation to mount the home directory for the user.

Top

Users of the Linux labs currently print using a workaround which sends
their print job to a Novell server, which forwards the job to the
desired printer queue, deducting printing credit from the user if
required. To print, a user has to record their Novell user name and
password in Linux. The printing utility uses the Novell details to
attempt to complete the job. A valid Novell user name and password is
required, along with adequate printing credit for printers which
require it (most of the general access printers in the labs).

The Linux printing document is currently located at
http://www.its.monash.edu.au/info/itsig/itsig_2c.pdf

Top

The software installed in the labs is managed using two methodologies.
Initially, a base system is configured from the packages provided with
the operating system. The use of precompiled packages makes it easier
to install and manage a large number of individual programs. The
installation is customized to exclude unnecessary software:

* Software to run specialized services
* Programs not supported at Monash
* Programs that will not run in the lab environment


Updates to the packages from the initial installation are provided by
the operating system vendor at any time and, during semester, are
usually installed after business hours to cause the least impact on lab
operation. Outside of the teaching periods, updates may be installed at
any time. Packages may also be updated during teaching hours in urgent
circumstances such as security updates or important bug fixes.

Some vendor packages installed are customized for the labs. Packages
are built at Monash when a vendor or third-party version is not
available, and packaging the software is a trivial operation; in some
cases, packaging instructions are include with the source code. In
addition, some faculty requested software is available as third-party
packages, these are installed after the initial install.

The other methodology for managing installed software in the labs
involves the use of the /usr/local directory, which is used to house
unpackaged but precompiled programs, and programs compiled from source
code. Some software is only available as source code, if constructing a
package from it is non-trivial, it will be compiled and installed in
the /usr/local directory. It may also be the case that the original
software request required a customized compile and install in the
/usr/local directory.

A web page documenting the Standard Operating Environment (SOE) for the
Linux labs has been produced. It follows the Windows and Macintosh
versions in terms of application types in order to help maintain a
standard environment across the range of operating systems available,
and to conform to Monash guidelines. In addition, the Linux SOE defines
a Window System and a Window Manager. The Window Manager was required
to simplify support requirements (for the Helpdesk) by providing a
small, stable, relatively user-friendly program which does not require
constant updating, maintenance and tracking of a multitude of
dependencies on other software packages. The web page is updated as
required. The SOE document is currently located at
http://www.its.monash.edu.au/twp/unix/linux/student-linux-soe.html

An additional web page lists all of the software available in the Linux
labs. The page is mostly produced using a combination of package
management utilities, a custom program and some manual editing to
maintain the list of software available in /usr/local. This page is
updated when software is updated, or when new software is installed.