docs/func-spec.html
<html>
<head>
<title>Functional Specification: RedBrick Registration System</title>
<link rel="stylesheet" href="doc.css" type="text/css">
</head>
<body>
<h1>Functional Specification:<br>RedBrick Registration System</h1>
<p><i>Cillian Sharkey, CASE3, 50716197</i></p>
<ol>
<li><a href="#intro">Introduction</a>
<ol>
<li><a href="#scope">Scope and purpose of this document</a>
</ol>
<li><a href="#overview">Overview of project</a>
<ol>
<li><a href="#background">Background</a>
<li><a href="#users">Users</a>
<li><a href="#objectives">Objectives</a>
<li><a href="#constraints">Constraints</a>
</ol>
<li><a href="#func">Functional and data description</a>
<ol>
<li><a href="#arch">System architecture</a>
<li><a href="#data">User data</a>
<li><a href="#boundary">Software and Hardware Boundaries</a>
</ol>
<li><a href="#sched">Projected schedule</a>
<li><a href="#refs">References</a>
</ol>
<a name=intro></a><h2>Introduction</h2>
<a name=scope></a><h3>Scope and purpose of this document</h3>
<p>This document is a functional specification for my 3<sup>rd</sup> year
project: a user registration and administration system for use by the DCU
Networking Society (<a href="http://www.redbrick.dcu.ie">RedBrick</a>). It
will attempt to describe the functional aspects of the project: its
objectives, constraints, system architecture, and functional data description
so that there is enough information for the actual implementation of the
project.</p>
<a name=overview></a><h2>Overview of project</h2>
<a name=background></a><h3>Background</h3>
<p>There are just over 1,800 accounts on the RedBrick UNIX system and so the
administration of user accounts forms a large part of the system
administrators' workload. As one of the system administrators for RedBrick
myself, I have first hand experience of the amount of work required in
administrating user accounts and dealing with account requests on an often
daily basis. In addition to this, each year at the clubs & societies day
the registration of new and renewal of existing users takes place. Hundreds
of users are processed on a small isolated network of computers. The goal of
this project is to reduce the workload of system administrators and ease the
administration and registration of users both on a daily basis and for the annual
clubs and societies day.</p>
<a name=users></a><h3>Users</h3>
<p>The users of the system will be restricted to the system administrators
for day to day user administration as it requires root (superuser) access, however
for registration on clubs & societies day it is usual for other members of the
society committee to help out.</p>
<a name=objectives></a><h3>Objectives</h3>
<ul>
<li><p>Provide an automated and consistent (UNIX command line) interface
for performing both common day-to-day and occassional "batch" user
administration operations on the actual accounts (home directories,
mail spools, disk quotas etc.), the UNIX <code>/etc/passwd</code>
"database" and the user database ensuring that all are kept in sync.
Single user account operations would include:</p>
<ul>
<li>adding new accounts,
<li>deleting existing accounts,
<li>renaming existing accounts,
<li>converting existing accounts "usertype",
<li>renewing existing accounts,
<li>reseting accounts with new random password (and emailing password
to user)
<li>retrieving account information for display,
<li>checking the availability of usernames for new accounts,
</ul>
<p>Batch account operations would include:</p>
<ul>
<li>emailing renewal reminders to non-renewed accounts
<li>expiring non-renewed accounts (i.e. disabling login shell)
<li>deleting non-renewed accounts after a grace period
<li>checking for inconsistencies between the user database and the
UNIX <code>/etc/passwd</code> database
<li>interactive update of the user database from the latest copy of
the public DCU student database
</ul>
<li>Provide a web interface to offer a similar set of single user
administration operations for use on the clubs & societies day. The
setup is generally that of a small number of networked computers that are
isolated from the RedBrick servers so changes would be made to a local
(seperate) copy of the user database and at the end of the day all of
these changes (i.e. new, renewed, renamed, converted, etc. accounts) must
be detected and synchronised with the actual accounts and UNIX
<code>/etc/passwd</code> database on the system. This needs to be done
in batch as hundreds of accounts are processed on clubs &
societies day. This would be implemented as one of the command line
interface's batch operations.
<li>Prevent username conflicts with other namespaces on the system
e.g. email aliases, mailing lists.
</ul>
<a name=constraints></a><h3>Constraints</h3>
<ul>
<li>All accounts must have a name (or description) and an alternate
email address for contact purposes (and as such all UNIX accounts must
have a corresponding entry in the user database).
<li>Users may only have one account on the system (i.e. one student ID
per account).
<li>Member, staff and associate accounts must have a valid DCU
student/staff ID associated with them.
<li>Usernames will be limited to what the underlying UNIX OS supports
in terms of acceptable characters, length etc.
</ul>
<a name=func></a><h2>Functional and data description</h2>
<a name=arch></a><h3>System architecture</h3>
<p>The system will be 3 tier in nature:</p>
<p><b>Front end</b></p>
<p>There will be two client applications: a CGI web interface (primarily for
use on the annual clubs & societies day to register new members and renew
existing members) and a UNIX command line interface for day-to-day user
administration.</p>
<p><b>Middle end</b></p>
<p>There will be two modules which the two client applications (and any
potential future applications) will use. One will be for performing database
operations (RBUserDB) and the other for UNIX account operations (RBAccount).
The web interface will not make use of the UNIX account module however, as it
operates on the database only.</p>
<p><b>Back end</b></p>
<p>Database (likely to be PostgreSQL) which will contain tables for the actual
user database and associated information, e.g. local copy of the public DCU
student database, table of valid usertypes, additional reserved usernames,
etc. Will also contain copies of user database from previous years for
reference/archival purposes.</p>
<a name=data></a><h3>User data</h3>
<p>The traditional UNIX <code>/etc/passwd</code> database doesn't contain
enough information for user accounts for RedBrick's needs (nor does it support
complex queries that a database can) hence the need for a user database. The
following additional information will be kept for all UNIX accounts:</p>
<dt>Username</dt>
<dd>Unique UNIX username.</dd>
<dt>Name/Description</dt>
<dd>User's full name or a description for non-user accounts (e.g.
project/system accounts).</dd>
<dt>Usertype</dt>
<dd>Corresponds to both UNIX group and type of user. The following usertypes
will be used: member, staff, associate, project, club, society, committee,
project, guest, system, reserved.</dd>
<dt>Email</dt>
<dd>Alternate contact address (typically DCU email address).</dd>
<dt>Student ID</dt>
<dd>DCU student (or staff) ID number, compulsory for member, staff and
associates.</dd>
<dt>Years paid</dt>
<dd>Number of years paid. (Non-renewed accounts will be zero).</dd>
<dt>Updated by</dt>
<dd>Username of the administrator who last updated the database entry.</dd>
<dt>Updated at</dt>
<dd>Date & time of when the database entry was last updated.</dd>
<dt>Created by</dt>
<dd>Username of the administrator who first created the account.</dd>
<dt>Created at</dt>
<dd>Date & time of when the database entry was first created.</dd>
<a name=boundary></a><h3>Software and Hardware Boundaries</h3>
<p>The project will use the OS native command line tools for performing all
UNIX <code>/etc/passwd</code> operations and the majority of account
operations. The 3rd party utility <code>setquota</code> will be used for
the modification of disk quotas. DCU student information will be retrieved
from the publically accessible LDAP service on <code>atlas.dcu.ie</code>.</p>
<a name=sched></a><h2>Projected schedule</h2>
<dt>Week 1</dt>
<dd>Design database (SQL schema & populating with sample data). Code
middle end database module (addition, retrieval and updation of user
information, user data checking functions).</dd>
<dt>Week 2</dt>
<dd>Code middle end account module (interaction with UNIX account utilities
& filesystem manipulation of user accounts).</dd>
<dt>Week 3</dt>
<dd>Code command line interface (single user operations) in parallel with
'unit testing' of the various database and account module functions.</dd>
<dt>Week 4</dt>
<dd>Code web interface.</dd>
<dt>Week 5</dt>
<dd>Work on batch operations.</dd>
<dt>Week 6</dt>
<dd>Final testing. Write up documentation: Technical manual, User manual,
Installation manual.</dd>
<a name=refs></a><h2>References</h2>
<h3>UNIX (Solaris) user administration tool manpages</h3>
<ul>
<li><a href="http://www.uwsg.iu.edu/usail/man/solaris/useradd.1.html">useradd</a>
<li><a href="http://www.uwsg.iu.edu/usail/man/solaris/usermod.1.html">usermod</a>
<li><a href="http://www.uwsg.iu.edu/usail/man/solaris/userdel.1.html">userdel</a>
</ul>
<hr>
$Id: func-spec.html,v 1.1 2003/03/28 16:33:07 cns Exp $
</body>
</html>