Skip to content | Change text size

ITS home
 

Linux Documentation (historical)

More information on Linux can be found at the official Linux hompage

Current software available on Linux platform at Monash.

Index

  1. Introduction
  2. Implementation

Introduction

A decision was made in mid 1995 to introduce a PC based Unix operating system, to Computer Centre labs. Broadly to provide:
  • Extra X terminals.
  • Alleviate demand of existing Unix stations for introductory course work.
  • Reduce cost in setting up equivalent resource using commercial Unix stations.
  • Make full use of PCs resource with a turnkey dual operating systems capability.
  • Giving more choice of operating system on PCs.
  • Provide a platform for hand on in depth study of Unix.
The project was assigned to the ITS Shared System group with support from Micros, Networks group, with Jack Chorowicz as the project leader.
The Shared System implementation team leader was: Keith Lewis,

Time frame

It is expected that CC will have some 200 PCs in 6 labs across 5 campuses operational by the beginning of 1996 1st term (4th of March). The demand for such capability exceeds our expectation, we are now proceeding with full in field testing, bypassing a planned pilot phase.

On going development

As expected of a tight scheduled project, bugs, setup and utilities are being written and modified as they are being detected. We are slowly enhancing our turnkey system.
So far:
  1. October 95, develop various environment and setup tools.
  2. November-December 95, setup test Linux boxes.
  3. January 96, setup a student Linux lab of PCs for testing. Refining tools and collecting traffic data.i (see result)
  4. Setup 6 labs of 200 PCs accross 5 campuses by the start of 1st semester.
  5. 4 March came and gone smoothly, we now have setup 10 labs ~200PCs accross 2 campuses running Linux.
  6. Developing and implementing Monash campuses wild access to PCs dual booting labs.
  7. Upgrade Linux production 1.2.8 to 1.2.13 for 2nd semester <-- current status
  8. Design a new Linux architecture to resolve overall performance due to nfs performance.<-- current status


Implementation

Linux choice
The team decided on Linux over NetBSD influenced by the popularity of Linux as the flavour of the year. Attracted also to Linux good library of application software. Several aspect of Linux in terms of tools and utilities such as 'loadlin' boot strapping program, convinced the team of building a workable turnkey system.

Issues
Once the first system was set up at the end of November 95, the team then started to address to issues relating to a 'public' and open Linux systems sharing existing Computer Centre network. Three main problems were identified:
  • 1-Security
    How to secure Linux sharing existing centre resource.
  • 2-PC environment
    How to guarantee suitable PC environment for Linux, requiring automated process to overcome problems associated with PC lab eg. disk gets repartitioned, disk gets used up, what VGA and mouse does the PC have etc..
  • 3-Network traffic
    This issue relates to the impact of Linux eg.the bootstrapping of Linux, nfs traffic on existing Novell environment. How to design an acceptable responsive system to meet end users need.
  • Other issues:
It was a challenge in working towards resolving these goals. It is the aim of project to build a generic turnkey Linux system , where any PC can either boot DOS/MSWindows or Linux. However in the initial pilot stage the system is build around a standard PC configuration.

How we implement it?

(How to do it)

Basically, a boot image of Linux is served by a Novell file server on request of a user, instead of MSWindows at a DOS login prompt. Prior to down loading of the image, the PC environment is checked (see 2- PC environment). At this stage of implementation and the danger of RePart.exe deleting user disk the finer control of down loading is achieved by checking for valid authorised PC station name. If a /root image already exists on the hard disk, it will be 'checksumed' for its authenticity ie. no trojan horse, shell swapping etc. A new reload of the /root would of course be the safest way of starting Linux, because the Novell image file is read only.
At the end of the process, control is passed to Linux utility LOADLIN.EXE to down load Linux Kernel (VMLINUZ) and jump straight into Linux.
This can be seen as a system weakness because there is very little one can do to protect end users from 'Trojan horse' scamp. It is easy for any user to compile their own version of Linux kernel and leave it running to purport to be a login prompt. Only a complete reload of the kernel from the start would safeguard against Trojan horse programs.
Other security issues are addressed to by the implementation of Kerberos. Without a kerberos key the Linux system is limited to its own resource.

  1. Security
    Kerberos was adopted as the mechanism to safely allow Linux system share resources with existing system. Kerberos is adopted to resolve issues relating to:
    • Linux PC user gaining root privilege by booting from a stand alone system (eg. via floppies).
    • Unauthorised users using the University resource eg. printing, email.
    an issue of authentication and authorisation, the very objective Kerberos was designed for. The work involved porting Kerberos to Linux and introduce Kerberos widely to other systems.

    Kerberos mechanism safeguards systems from attacks, by validating who the user purport to be without having to pass clear text password over the network which can be 'sniffed' and intercepted by any user on the segment of the network.

    Already we have found a number of PCs in public area having been installed with a Linux system. Anyone can boot Linux from a set (2) of floppies and become root. Without a proper registered Kerberos password, the user will be root to his local system alone, with no access to any other services except of course public read only exported files.

    Should we give students root password?!
    During testing of our setup, it became apparent that the answer to this question is Yes! for several reasons:
    1. Student can become root via booting Linux from floppies, and then modify root password.
    2. 'Crack' the password and hand it out.
    However the password is gotten, there is little reason NOT to to give it out. Beside, this is a platform to teach student to become a SysOp or SysManager of their own box, thus root priviledge is required by students. The abuse I can think of, is user logging as root all the time. But this should be part of educating the student not to use root login.
    Caveat: remote login (telnet, rservices) should be disabled by default. User should be aware of the danger before reenabling it eg. another user remote login into his box as root!(since root password is available).

    With CC Kerberised setup, security can be guaranteed. With remote login disabled, root is localised to any one particular box.

  2. PC environment(Edgar and Pan)
    There are two folds to this problem;
    1. How to guarantee the integrity of PCs? Is there a /root and /swap partitions on local hard disk? How to overcome itchy fingers repartitioning, and loading up the disk?
      To resolve this problem we had to develop a suit of utilities namely: CCCHECK.EXE an environment checker and RePART.EXE a scripted FDISK and QuickFormat utility.(Pan)
    2. How would it possible for Linux to support a diversity of hardware configuration eg. VGA, mouse (Edgar). We have found using existing Intel Express Ethernet card driver needed reworking (Pan) to make it more stable. (get eexpress.c).
      Intel EtherExpress is certainly not a card of choice, we have to make it work because we have labs full of them. SMC/WD or 3Com ethernet cards are preferred.
    3. Network traffic( Ari & Ron)
      The objective of this exercise is to gauge the impact of remote booting of Linux stations, and sizing of nfs traffic over DOS/MSWindows in a typical lab environment. The traffic data is critical in system design in order to guarantee acceptable response time.



    4. New Linux architecture
      The nfs test result shows that the Linux student environment suffers poor performance due to nfs file serving. To resolve this problem we are implementing the architecture:
      1. Minimise hops between nfs filter box and users disks. Which are now moved to be in the filter box, using a PCI SCSI controller; BusLogic BT956C which is a newer model then the BT946C as recommended by Linux documenttaion.
      2. Ethernet bottleneck problem will be resolved by installing a PCI Ethernet card (3Com 3C595TX) in the nfs filter which would improve the throughput.

    Striving for a generic Linux turnkey system

    We aim to work towards designing a system that is safe and secured for any remote PC end user to decide what flavour of operating system he chooses to run. This will involve both educating end users as well as set up an intelligent user friendly system. Since the setting up of Linux involves RePartioning which is of a same degree and danger of Format c:; the process should be well controlled.

    Test result of pilot phase


    From pure MSWindows and Linux traffic; Linux's traffic is less than MSWindows traffic. A PC running MSWindows sustains Novell file server access longer (with DLLs access) than Linux with high peaks in burst mode. Linux has the advantage of being a standalone system, with minimal nfs access to a file server.
    It is now proven that such a turnkey system would work. Some hurdles are being worked on:
    • PC area
      • More emphasis is now being put on in developing utilities to guarantee PC environment eg. Disk compression, directories management, in order to minimise DOS reloading of files due to repartioning of hard disk.
    • Network
      • Network is being upgraded to meet expected increase in traffic with additional use of existing resource.
    • Security
      • Kerberos, nfs "filter/proxy" boxes are being put in place to improve and resolve security issues.
    NFS performance result (Taken from Edgar's test mailed out on May 17 96)
    Below are the results of NFS benchmark tests using iozone, on linux client PC's with different versions of kernels. The figures were taken by NFS writes and reads of sequential files of varying file sizes (1MB,10MB,20MB) and getting the average. As the results would indicate, we get better throughputs if the NFS servers were running linux, instead of other Unix OS, something to the order of 4-5 times more. This is regardless of what linux kernel version we are running.

    Testing From | To | Via | Write / Read (KB/sec)| comment
    • Linux 386 pc | local disk | scsi | 150 /
    • Linux 386 pc(russell) | Linux 486 pc(lewigi) | NFS | 7 | Same subnet
    • Linux 386 pc | DECstn(mosel) | NFS | 7 | diff subnets
    • Linux 386 pc | DECstn | NFS | via NFS-filter | 7 | diff subnet
    • DECstn 5000/200 | DECstn 5000/125 | NFS | 68
    • DECstn 5000/125 | DECstn 5000/125 | NFS | 56
    • Alpha | DECstn 5000/125 | NFS | 66 /
    • DECstn (mukluk) | DECstn at Caulfield (nella)| NFS | 72 /
    • mukluk (clay) | rhea (caul) (486 freebsd) | NFS | 100 /
    • DECstn | DECstn | NFS via NFS-filter | 7 /
    • DECstn | Alpha | NFS | 128 /
    • Alpha | Alpha | NFS | 600 /
    • Linux 1.3.95 486 pc | Linux 1.2.13 486 PC | NFS | 57 / 90 |same subnet
    • Linux 1.2.13 486 pc | Linux 1.2.13 486 pc | NFS | 55 / 88 | same subnet
    • Linux 1.2.13 486 pc | Linux 1.2.13 486 pc | NFS | 47 / 65 | Diff subnet
    • Linux 1.2.8 486 pc | Linux 1.2.13 486 PC | NFS | 57 / 92 | same subnet
    • Linux 1.2.13 486 pc | DECstn 5000/125 | NFS | 9.8 / 45 | diff. subnets
    • Linux 1.2.13 486 pc | 2100 Alpha | NFS | 4.6 / 7.2 | via nfs filter diff. subnets
    • Linux 1.3.95 486 pc | DECstn 5000/125 | NFS | 8 / 45 |diff. subnets
    • Linux 1.2.8 486 pc | DECstn 5000/125 | NFS | 10 / 131 | diff. subnets


    Standard Linux PC configuration

    This a recommended configuration for the Computer Centre 1st stage of implementation of Linux on PCs in student labs
    • 486 system with a 1.44 floppy drive, minimum 8 megabytes of RAM, 400 megabyte of IDE hardisk, Microsoft mouse.
    • S3 SVGA display card with multi scanned VGA monitor capable of handling 1024x768 256 colours resolution.
    • The 1st stage of implementation supports Intel express Ethernet cards that already exist in labs. They however are not recommended due to unsatisfactory performance.
    • Preferred Ethernet cards:
      1. 3Com cards eg.EtherLink 3(3C509, 3C509B)
      2. SMC cards eg.Elite 16 (WD8013 chip)
      Although other Ethernet cards are supported by Linux, these cards are preferred.
    • Student satellite station using "Repart" requires 175 MB hard disk.

    Detail step by step how to setup similar labs.

    WARNING! AutoIDE.exe, CCCheck.exe and RePart.exe will modify system setup and disk WARNING! to the same level of 'Fdisk' and 'Format'. Trial with care!


    Current work on Linux is accessible by ftp to ftp.monash.edu.au in /pub/linux-cc . Monash Linux PC labs have access to CC working directory which is exported from mick:/cc/linux/usr/

    AUTOIDE.EXE will try to match IDE reported geometry with how the CMOS is setup. If the geometry does not match; it will use a BIOS disk entry if it can find one, else just give a big warning. This is to make sure we make the full use of the disk capacity.

    This is just an example of the flow, CCCHECK.EXE and REPART.EXE have many switches and flexibility. We ASSUMED there is one IDE disk C: drive only, and there are 3 partitions (DOS,/root/swap).
    MSWindows environment boot will repopulate appropriate MSWindows files as needed
    . CCCHECK.EXE CC check for specifics:
    (return ERRORLEVEL =0 for success)
    • /C Checksum, test specific Linux files for security checksum check.
    • /D Display, confirm with BOOTP the station name and compare it with valid LABS.... END LABS in CCLINUX.CFG to allow Linux to run.
    • /F Files will read setup from CCLINUX.CFG. CCFILES="....",
      CCDIRS="..." specify files and directories to be preserved, anything else will be selectively wiped ie. kill non CC files. Warning! this is a time consuming exercise, ie. delay in Linux boot. I admit that this will force students to dump their games into eg. windows directory, I am planning to counter this by CCDIRS to have size ie. if it is too big, wipe it. It will be reloaded by MSWindows boot anyway. To speedup Linux boot we might get Linux to repopulate MSWindows partition of its files when it is wiped.
    • /H Help, syntax.
    • /L Check for Linux partitions /root and /swap.
    • /M Check read and writable C: drive.
    • /S signature, check for RePart quick format signature so that DOS can do a full reformat it is needed.
    • /W sWap, calculate Linux Swap size set environment variable SWAP 25 MB minimum, if disk 200-500MB, 3xmemory up to 45MB swap. If disk > 500MB straight 3xmemory SWAP space.


    Example of CCLINUX.CFG:
    ******* search list: L:\LINUX\, F:\LOGIN|LINUX\,V:\SHARESYS\LINUX, local
                                       SYNTAX
         - Data starts on line with IMAGE DIR
         - Use back slash \ to specify subdirectories
         - Data line starts on 1st column.
         - CCFILES list of filename exempt from deletion
                   IF NO CCFILES line defined ie. Delete NO file
                   IF CCFILES "" ie. delete ALL FILES
         - CCDIRS list of subdirectory exempt from deletion
                   IF NO CCDIRS line defined ie. DO NOT delete
                    directories
                   IF CCDIRS "" ie. delete ALL directories
         - LABS:.....END LABS: block is last read ie. end of CFG
                   Labs entries starts at column 1.
--------------------------------------------------------
IMAGE DIR "v:\sharesys\info\linux\image"
CCFILES "\autoexec.bat,\BC.bat,\startnet.bat"
CCDIRS "\WINSTUD,\WINDOWS\*,\boot,\NWCLIENT"
LABS:
maths-g16b
CTL-G14
CC-G16
END LABS:


    Replication and backup procedure

    Replication:
    Replication can be achieved through the use of rdist ( remote file distribution client program) which is a program to maintain identical copies of files over multiple hosts. The rdist version that we have uses rsh command to access each target host. Rdist reads commands from a distfile to update files and/or directories.

    Backup and restore:


    It is proposed that the root or / partition of all servers be backed up on one of the disks on mick on a regular basis. The size of the / partition is about 15MB. Mick in turn gets backed up once a week (incrementals) and a full backup every month. In the absence of the dump and restore command in linux, we will use cpio. Download a PKZIPed programs for total system recovery from catastrophic crash ie. lost of root partitions. This programs will enable minimum boot to restore from mick.cc.monash.edu.au.



    See more detail about Replication & Backup/Restore.

    Issues and problems encountered

    1. Giving out root password to students; as discussed above in "Security" section.
    2. V1.2.8 with reworked Intel EEXPRESS card driver works fine for less networked intensive coursework. However it has been reported that it still suffers with system 'hangup' when doing large ftp with little packet latency eg. ok to ftp to the US for a file, but hangs when doing transfer of the same file between local hosts.
      ACTION: V1.2.8 none, because it requires backward version of gcc,ld etc. Since we are moving to v1.2.13 we will work on the new released version of EEXPRESS and see.
      May-1996.
      The problem with hangups with the eexpress card is inherent to the card because of how the card service incoming packets with the Intel chip requiring acknowledgement from CPU to clear pending tasks. In slow system the slow latency of interrupt servicing would guarantee the i82586 managing itself adequately. In faster CPU system, the more frequent interrupts would cause a lock up due to severe nested interrupts that the i82586 could not recover from.
      The release version is V.02, it has been tested on V1.2.3, to some 80% satisfaction. There has been no problem for Unix introductory coursework. But we know for a fact that it does hang when doing large file transfer.
      ACTION: No more work done on eexpress.c, we will upgrade the labs with another more proven ethernet cards.
    3. Linux woul Kernel Panic all the time, after reload and whatsoever
      DIAGNOSIS:
      After scratching my head, and checked and double checked if we don't have some bad image and corrupted data etc.. all looked ok, beside the same images and program work on the machine next to it. SO, it must be something local to that particular PC. I re-FDISKed the disk to a single volume and DOS re-FORMATted the drive. L:\LINUX\LINUX again and launched Linux , all worked again!...
      CONCLUSION:
      The fault was due to the hard disk developing bad blocks in the Linux partition. Since it is not marked as 'bad', "Repart" will just try to block write over it, but when it comes to try to use it ie. run the Kernel ...PANIC. The DOS re-Format process was the only way to mark the block 'bad' so that the sectors will not get used by "RePart". An alternative would have been to boot linux from floppies and then 'fsck' the Linux partition.
      ACTION:
      I am still thinking about how to avoid this situation. Any suggestion?