Annual Report of the GAUnix Group

Christopher Fraser (chrisf@nospam.sour.sw.oz.au)
Fri, 11 Mar 1994 21:05:21 +1100 (EST)

Annual Report of the GAUnix Group
=================================
Compiled by the Group leaders of the GAUnix Group.
President : Andrew Davison
E-Mail : andy@nospam.yoyo.cc.monash.edu.au

Contents

Section 1 : System overview
Section 2 : Summary of activities for 1992
Section 3 : Conclusion

Appendix a : Annual Report of the Menu Administration Group
Appendix b : Annual Report of the Network Administration Group
Appendix c : Annual Report of the Security Group
Appendix d : Annual Report of the Games Administration Group
Appendix e : Annual Report of the Account Administration Group
Appendix f : Annual Report of the Help Administration Group
Appendix g : Annual report of the FTP Administration Group
Appendix h : Annual Report of the IRC Administration Group
Appendix i : Annual Report of the Technical Administration Group.

Section 1 : System Overview

Yoyo is a Decstation 2100 which has been made available to the wider
Monash University community as a machine on which computer-related activities
may be pursued. These activities include many which are not permitted on
Computer Center machines for various reasons.

GAUnix exists as a group to provide this service in an atmosphere which
promotes YoYo as a machine which is easy for novices to use effectively, and
encourages users to become more aware of the facilities which are available to
them as members of an academic community through computers and the Internet.

The system presently has over 850 accounts, 739 of which have been used
in the last 7 weeks. It is estimated that 80% of accounts are used regularly
(i.e. at least once a week). The machine can expect a large influx of users
in the coming year as first-year students arrive and the existence of the
machine is more widely publicised.

Section 2 : Summary of activities for 1992

1992 has been an exciting year for the members of the GAUnix group
and for the users of Yoyo. It has seen the establishment of the first
widely accessible Unix computer system with full Internet access. To cope with
the large amount of work involved in maintaining a high quality of service, we
have created a number of groups which administer various aspects of the machine.
This is a summary of the activities carried out by these groups. If further
details are required, please refer to the full reports in Appendices a-i.

A menu shell is available for novice users which has been successful
in providing access to facilities like e-mail and news. Some of these users are
becoming Unix-aware via the Learn and Unix Manuals which are accessible from the
menu, and these users are migrating from the menu shell to a full shell account.
The menu program itself is continuously being upgraded and optimised to
maintain the high standard of service to menu users despite the increasing demands
imposed on the machine.

Much of the high load on YoYo can be attributed to network transmission,
much of which is due to interactive connections. Users have been asked to refrain
from Aarnet use during the day and have responded well to this. We intend to
provide a service which will obtain files on a batch basis (i.e. overnight) for
users, which should further decrease the amount of day-time traffic. The group
responsible for administering the Network usage also makes a point of being
aware of network "holes" and making the GAUnix group aware of these.

Security on YoYo is fairly high, due to the relative ease with with accounts are obtained.
Network tracking capabilities have been improved to permit tracing of system
abuse. Cases of abuse have been dealt with in proportion to the severity of the
offense via a 3-warning system. Most offenses result in a single warning, and
each user is permitted 3 warnings before their account is closed. Another issue
is that some sites have specifically asked that they be blocked (e.g.
RMIT machines), while some others are blocked because they are known to
harbor crackers.

YoYo also promotes the use of computers for entertainment by allowing
users to play games on the system. This usage is restricted by a regulator which
monitors the system load. If it senses that the load is too high, access to games
is discontinued until the load returns to a level at which games can be sustained
without degrading system performance too heavily for other users.

Since it is acknowledged that many of YoYo's users are novices, an
efficient help mechanism is vital. This is provided through a program written
by the Help administration group which informs GAUnix members of help requests
as they log in. Furthermore bulletins are provided and brought to the attention of all
users as they log into the machine, informing them of what is/has been happening on the machine.
Investigation into the provision of a "live" tutoring service is continuing.

One of the major advantages to users of YoYo is the availability of
software via anonymous FTP. YoYo currently mirrors often used programs via it's
own anonymous site. This service provides only 2 non-monash logins in order to
keep the system load to a minimum.

Another common use is Interactive chat, or IRC. This provides an
interactive chat medium for users to communicate with people all over the world.
Since we realise that this is a network-intensive activity, its use is restricted
to between the hours of 6.00 pm and 9.00 am. Users have generally respected this
service.

On the technical side, our system administrators have contributed a lot of time and
effort to making the operating system kernel smaller and faster, as well as
creating daemons to cache information which is used frequently by system calls
and utilities. Of particular interest has been the diskspace daemon which
keeps a log of which users are using excessive disk space without crippling the
machine like old scripts did.

Section 3 : Conclusion

YoYo is performing extremely well considering the number of accounts
and the number of users it concurrently supports ( averaging about 40, and
peaking at 100). In the near future we anticipate that this usage will increase
dramatically, and that system and software optimisation will no longer be a
feasible means of maintaining the quality of service YoYo provides to a
large number of Monash students and staff.

Appendix a

Annual Report of the Menu Administration Group
==============================================
Leader : Stephen McNamara
E-mail : brumby@nospam.yoyo.cc.monash.edu.au

The menushell environment has proven to be very successful in
introducing novice computer users to the facilities available
under Unix. At the time of writing ( 21 September ) there are
311 menu user accounts, a little more than one third of all user
accounts on the system. In addition to this, a number of shell
users use the menu to gain access to games and other programs
which are either not in the standard binary directories or which
have a large number of command line options.

The menu currently provides access to email, USEnet news,
games and communication utilities such as talk and IRC. A screen
oriented file manager is provided and the Unix tcsh command line
is also available for access to functions not yet available on
the menu. For most of these options a choice of programs is
available.

In keeping with the educational goals of yoyo the Unix manual
and the learn command are also available. As a result of this, a
small but steady stream of users apply to have their accounts
transferred from the menushell to the tcsh. At present I am in
discussion with a recently transferred user on ways of having the
menu explain the commands being run without intruding on users
who have no wish to learn the details of the underlying system.

Due to the considerable load on yoyo during the day, a great
deal of time has been spent on optimising the menu to improve
both its running speed and memory usage. Despite this the start
up time on the menu during the middle of the day is considerable.
I am looking into ways of improving this without reducing the
current reliability of the menu.

Future plans for the menu include the previously mentioned
optimisations and the extension of the educational aspect. There
remains a large amount of software to be made available to menu
users through properly defined options. Access to network
services beyond yoyo, such as the library catalogues at Monash
and other Universities and the Archie software archive will also
be investigated and made available through a suitable interface.

The menu system is expected to become steadily more important
as the advantages of computer and network access become more
widely known throughout Monash. As such the menu will be
expanded to make computing resources available to those who have
little or no previous exposure to computers.

Appendix b

Annual Report of the Network Group
==================================
Leader : Anthony Baxter
E-mail : anthony@nospam.yoyo.cc.monash.edu.au

Yoyo is putting out an enormous number of packets - this is causing
considerable load on the system. Unfortunately, not much can be done about
this. Statistics gathered show that about 45% of all data to and from yoyo
is from interactive connections. Another 10% of data is from ftp (file
transfer protocol) connections. 2% is from mail, the rest is from a variety
of other network protocols.

Requests to the user population to refrain from using the network outside
Monash during the day have proved very successful - very few people are
using AARNet during the day.

It is hoped in the future to offer a facility by which users can request a
file to be transferred, and a batch processing system will then retrieve
that file from the closest possible site that night.

It was decided early on to install a front end to the networking interface
that would allow us to limit access to yoyo. Some of the uses for this have
been
o To stop people from connecting to yoyo from high performance PC's in the
computer center lab,
o To increase security by blocking access from 'problem sites', that is,
sites that we have found to have security problems.
o To restrict people logging in over modems excessively, and reducing the
supply of modems available for people doing real work.

Yoyo offers, amongst other things, USENet access to its users. This is
achieved by directly accessing the news disk on the news server, MONU6. This
produces a much smaller load on MONU6 than would be produced if each user
were to connect independently.

Many of the networking programs provided by the vendor have been modified,
or replaced outright, to provide either enhanced functionality or better
performance.

In addition, many of the administrators of yoyo have been watching out for
problems at other sites (for example, incorrectly configured software that
allows security breaches) and notifying the responsible people (either the
site administrator or CERT).

Appendix c

Annual Report of the Security Group
===================================
Leader : Jason Pong
E-mail : jason@nospam.yoyo.cc.monash.edu.au

1) We have added banners to telnet and ftp requesting users to be responsible
when using those resources and not to abuse it. The idea behind this is
to inform the users that who doesn't know such things as external MUDS
are against AARNET policy.

2) We have improved logging of network usage that allows us better tracking
of abuses.

3) Installed tools for the security group to help them look after the system
(namely the programs such as cops, secure, audit_tool).

4) "Wrapper" program was installed to prevent logins from sites that are
known to harbor crackers or sites which requested to be blocked (such
as some of the RMIT machines).

5) Warning system has been developed for people who were abusing the system.
Warning #1 is to explain the problem and why it is so. Warning #2 gets
the account disabled and the person whom the account belongs to has to
have a personal chat with a system administrator before the account is
re-enabled. Warning #3 is when the user is barred from the system.

6) Transfers of disallowed material (copyright software and X-GIFs [in the
past]) to the machine were detected and the perpetrators were dealt with.

7) There were formal reports from RMIT reporting breaking attempts from some
of YoYO's users. The appropriate accounts were closed off.

8) Password program has been changed to ensure that users choose
hard-to-guess passwords. This has been very successful, particularly
with first-time users who are unaware of the issues involved in choosing
a good password.

9) Regular checks of network usage.

Appendix d

Annual Report of the Games Group
================================
Leader : Andrew Humphrey
E-mail : humpy@nospam.yoyo.cc.monash.edu.au

Introduction.

As one of the initial goals of the general access unix group
(hereafter referred to as gaunix) was to provide a computing environment
that engendered all forms of legal computer activity it was envisioned
that games would be a not insignificant part of that usage (which has
not however been the case). Thus a subgroup of gaunix was formed to deal
with the installation and maintenance of games.

Goals.

To try and encourage the perception that computers are more than
just a tool for work and to keep wholly recreational usage of
resources to a reasonable limit.

History.

Initially games access on the system was completely unregulated
and unrestricted, they resided in a public directory with no access
restrictions upon it. The original theory being to leave the use of
resources solely up to users common sense. This worked fine for the
short time that the gaunix machine was closed to the general student
community. Approximately one month after the machine went 'public' it
became apparent that the machine was going to be extremely heavily
loaded. A decision was taken by the games subgroup leader, in
consultation with the rest of the gaunix group, to limit access to games
during peak load times in an effort to somewhat prioritise the processes
on the machine.

Initially this was achieved by the simple expedient of
removing general access to the directory during the times of 1:00PM and
3:00PM. This however proved to be a less than ideal solution, it
exacerbated the problem of people compiling their own copies of games
and playing them, instead of the shared copies. This was a monumental
waste of limited resources and another solution was sought.

The next method used to regulate the load placed on the machine
by games was to implement some sort of system load based limitation upon
their use. Initially this method was implemented by the use of a daemon that
monitored the five minute load average maintained by the system and
removed access to the games directory when a threshold was reached.
This reduced the problems experienced with people compiling private
copies of programs as when the load daemon shut the directory the system
response time was so slow as to render most interactive programs, such
as games, very annoying in the extreme. People soon learned that even
if you compiled a private copy of a program it wouldn't run any faster
so they stopped doing it.

A problems was identified with this system. The system
made no discrimination between programs. A program with a negligible system
load effect was blocked right alongside of its more resource hungry
siblings. The solution to this was to implement the load daemon on a
file by file basis instead of the whole directory. For a more thorough
description of this daemon see the technical discussion below.

The next problem to present itself was that users would start
five or six copies of a program while the system was allowing access
and and then keep using these already started processes after the system
started blocking access requests. Again another waste of resources.

The final solution found to the general problem of process
prioritisation, from a recreational program, point of view was
discovered in a package called gr, or the games regulator, written by
Michael A Cooper of the University of Southern California. This
package allows individual thresholds, based on various system attributes
(See technical discussion for a more thorough description) to be set for
each individual program. This package has been modified to suit the
local conditions, by various members of the gaunix group.

Technical discussion of implementation details.

The first system used was a short C program that ran with the effective
user id of the owner of the games directory. Basically all this system
did was slept, awakening at given times (initially 1:00PM and 4:00PM) to
toggle the permissions on the /usr/games directory between modes 0755
and 0700.

The next system used was another C program running with the
effective user id of the owner of the games directory, this one was much
like the the first system in that it toggled the permissions of given
files between 0755 and 0700 except this one maintained a database of
which programs should be shut when. The database was built by hand
through the tried and tested method of 'that looks right' by the games
administrator.

The current solution to the problem, gr, works by providing a
wrapper around each individual program. It does this by having a link
made to the games regulator with the name of the program to be
regulated and the actual program being moved into a directory with owner
and group only access ( mode 0750 ). The games regulator then runs
set-group-id as 'games' the nominal owner of the games directory. Thus
access to the shared games can only happen though the games regulator
and to people in the games group ( the games administrators). The games
regulator reads on startup a configuration file and is capable of
setting thresholds based on:
o system load averages.
o free ttys.
o time. (which isn't utilised)
o number of users logged in.
It also checks for a NO_GAMES file which then blocks all games access
requests. The games regulator can also set the priority of the games
processes individually ( as specified in it's startup file ). The games
regulator checks the system parameters periodically while the programs
under it's control run. Hence it has the ability to automatically
terminate, after warnings have been given, processes should the system
parameter thresholds be exceeded.

Recently the games regulator has been modified to use a system
information daemon that had been written for the gaunix machine by Rik Harris.
This daemon stores the system parameters in a world readable shared
memory segment. This allows gr to quickly read the parameters, instead
of having to seek through kernel memory ( for the load averages ) and
read the utmp file (for free ttys and number of users) which is much
more efficient.

The games suite at present consists of:
Ularn b banner bcd boggle bs bt canfield conquer cribbage
dungeon fish fortune go gothic greed hunt jargon mille monop
moria nethack omega othello rain robots sail snake trek tt
tttt umoria wanderer worms wump

Conclusion:

The games regulator mechanism has effectively solved all the
problems that have arisen about the administering of games on a heavily
loaded machine. In the foreseeable future the games regulator will be
modified to allow a threshold to be set on free core memory as this has
been found to be one of the major performance limitations on the gaunix machine.

Appendix e

Annual Report of the Account Administration Group
=================================================
Leader : Roddi Walker
E-mail : roddi@nospam.yoyo.cc.monash.edu.au

The Admin group's primary purpose is to provide an efficient mechanism for
creating new accounts for interested members of the Monash staff/student
body. The group's success in this aim is best shown by the large amount
of accounts (over 850) created in the relatively short time Yoyo has been
operating.

The following people are involved in account creation:

Clayton campus: Andrew Davison, Glen Pringle, Tim MacKenzie, Kevin Lentin.
Caulfield campus: Jason Pong, Rik Harris, Simon Cocking.
Frankston campus: Matthew Glover, Keith Soon.

The number of people at each campus reflect that campus' demand for new
accounts. For this reason, no official account creation mechanism exists at
the Gippsland campus, where demand has been very weak. This situation
is being examined, with the aim of stimulating demand at Gippsland.

------------------------------------------------------------------------------

The other main activity of the group is moving users from menu accounts
to UNIX shell accounts as they gain experience. Before this is done,
the user must demonstrate to a member of the group that s/he knows enough
about the UNIX operating system to use it effectively, by answering
several simple questions about UNIX.

For convenience, this is done by using an existing mechanism of proven
efficiency - the above people involved in account creation also handle
menu to shell requests.

------------------------------------------------------------------------------

In summary, the main activities of the Admin group are:

o Account creation.
o Moving users from menu to shell accounts.

Appendix f

Annual Report of the Help Group
===============================
Leader : Aaron Wigley
E-mail : wigs@nospam.yoyo.cc.monash.edu.au

Brief

To provide a help system to users which will allow users of all levels
to efficiently obtain the help they need and to allow those with
experience who wish to help to contact those who require help.

Activities

- The "panic" program was developed to give users speedy access to
expert advice. For urgent questions it allows a gaunix expert to be
directly hailed, or for less urgent questions mail is sent out which
any gaunix member can respond to if they are able. It has surprisingly
been little-used. For some reason users seem more inclined to keep
quiet than ask questions. Some thought is being given to ways to
improve this situation.

- The "bulletin" program was developed to keep users informed of
important news about the system, without cluttering the text
displayed on each login.

- The "help" program was developed to give a user-friendly interface
to on-line help. The program is finished but currently requires much
work on the manual pages themselves. It is capable of providing help
around the university, not just on the one system.

- There is an ongoing investigation into a tutoring service, whereby
GAUNIX experts will be made available to people for assistance.

Appendix g

Annual Report of the FTP Group
===============================
Leader : Aaron Wigley
E-mail : wigs@nospam.yoyo.cc.monash.edu.au

Brief

To offer a local archive of useful software for the Monash population.

Activities

- An anonymous ftp site has been installed at yoyo, to cater for the
students and staff of Monash by making available mirrors of often
used programs and files. Currently, there is a limit of 2 non-Monash
logins, to reduce load.

- The following datum is made available, amongst others:
Weather maps of Australia and the world.
Anti-virus software for the pc's, Mac's and amiga machines.
UNIX software written by the GAUNIX Group.

- Experience has been learned in managing an ftp site, in mirroring
software, and deciding what to cater for.

- An ftp application has been implemented that will not allow various
files to be down/uploaded, such as GIF's. This has not been installed
yet, as there is an obvious way to circumvent it - install your own
ftp program. A way to limit this is being looked into, possibly
involving modification of the ftp daemon.

Appendix h

Annual Report of the IRC Administration Group
=============================================
Leader : Pratap Patnaikuni
E-Mail : pratap@nospam.yoyo.cc.monash.edu.au

The IRC group is involved in managing and helping users with the chat
program IRC - Internet Relay Chat; which allows users to use a multi-way
talk with people from around the internet.

IRC on yoyo was initially installed a couple of weeks after Easter.
Several suggestions were followed on the usage of the program:

* That there would be time restrictions
* That there be no modem access at that stage
* There be a limit on the number of users on IRC at a time

The IRC client on yoyo has undergone several updates - we are trying to keep
as current as possible as far as the international irc client/server versions
are going.

One of the first things that was discussed was a time limit system - as
yoyo is only a small machine, and considering the number of possible users
it was decided that irc would only be available from before 9am and after
5pm, when the load factors would be less, and also it would prevent people
from taking up resources such as pc's in labs merely for irc and preventing
others wanting to do work from doing so.

Later on, the 5pm start time was changed to 6pm after suggestions from
several users, and considering the load factors at the time.

One thing that we have found on yoyo is that irc can run fairly slowly when
many people are logged into the machine - so as many speedup ideas were
followed in each compilation of the server and client - such as not using
clocks in status lines and such.

So far, there have been no real problems with users, however at one stage
a couple of people were using the server off the mings machines, so we
set up passwords in the server to prevent them from using it any more. One
stipulation we have is that each IRC'er be accountable to a yoyo account. So
far there have been no problems with abusive users and such.

Reactions from users have been generally good; although a lot of mail which
comes in asks things such as "why can't we use it during the day" (to which
we explain why) and "when is modem access going to be allowed", to which
we can't really answer apart from a 'no idea'.

Other than that, most mail from users have been of the "How do I do <this>
on irc" which is responded to as soon as one of the 4 group members gets
to it.

Appendix i

Annual Technical Report
=======================

System administrators : Tim MacKenzie (tym@nospam.yoyo.cc.monash.edu.au)
Cameron Blackwood (korg@nospam.yoyo.cc.monash.edu.au)

The following summary was compiled on 11 September 1992.

739 people have logged in in the past 7 weeks.
At this time there are 816 accounts on the system. (13 currently disabled)
[On 1 October 1992 there are approximately 860 accounts]

***** Active User Profile ******

Here we log the number of different users who have used the system in the last
1,2,4 days, 1,2,4,7 weeks.

Time period Number of users Percentage of total users
1 day 394 48%
2 days 478 59%
3 days 567 69%
1 week 615 75%
2 weeks 660 81%
4 weeks 717 88%
7 weeks 738 90%

***** Per User Usage Statistics *****
Some statistics on how many times a person logs in in a single day:
Number of times How many times this occurred
1 3799 (31%)
2 2451 (20%)
3 1566 (13%)
4 1105 ( 9%)
5 774 ( 6%)
6 599 ( 5%)
7 400 ( 3%)
8 330 ( 3%)
9 263 ( 2%)
10-12 442 ( 4%)
13-16 189 ( 2%)
16-20 119 ( 1%)
>21 56 ( 1%)

Here is the average number of times per week that they log in:
Times per week. Number of people
1 261
2 106
3 134
4 81
5 89
6 45
7 23
---------------------------------
Average:2.1545 Total: 739

***** Daily Machine Profile *****

During the day, Yoyo usually has in excess of 60 users. Above this number of
users, performance degrades rapidly. We have had up to 96 users on the machine
at one time. The load average will sometimes exceed 80 for short periods
during peak times (between 12:30 and 14:00), although over recent weeks the
peak load has been decreasing due to the rewriting of several resource-hungry
programs.

On a "good" day, yoyo's load average will fluctuate between 10 and 20, although
the load average may sometimes remain above 30 for extended periods of time
(2-3 hours). The system administrators regularly check the process list for
runaway processes to try and keep the unnecessary load to a minimum.

****** System Modifications ******
Yoyo's kernel is probably the smallest and fastest Ultrix kernel in the
University. All unnecessary components have been stripped out and the current
size is 1.34 M. Several parameters have been tweaked to give better performance
under extreme load.

Many utilities have been rewritten to give better performance:

The 'kinfod' kernel information daemon collects statistics from the kernel
(such as machine load and number of users) and makes these available via
a shared memory segment. This is used by a number of programs which can then
change their behavior when the system becomes loaded. The uptime(1) and
load(1) utilities also use kinfo, and are up to 20 times faster as a result.

The 'dspaced' disk spaced monitor daemon performs the same task as the
'diskspace' script run on computer center machines. Unlike the 'diskspace'
script, it runs continuously and will pause whenever the load exceeds a certain
threshold. It runs at least 3 times faster than the script since it caches
information between checks of the file system.

The 'secure' program allows users or groups to run particular programs
with root privileges. This is used along with the 'gogroup' program to
allow non-root users to perform certain administrative tasks.

-- 
Christopher Fraser   ``smiley-faced guys in brightly coloured space suits''
chrisf@nospam.sw.oz.au