Redbrick User management tool
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

275 lines
9.3 KiB

  1. <html>
  2. <head>
  3. <title>Functional Specification: RedBrick Registration System</title>
  4. <link rel="stylesheet" href="doc.css" type="text/css">
  5. </head>
  6. <body>
  7. <h1>Functional Specification:<br>RedBrick Registration System</h1>
  8. <p><i>Cillian Sharkey, CASE3, 50716197</i></p>
  9. <ol>
  10. <li><a href="#intro">Introduction</a>
  11. <ol>
  12. <li><a href="#scope">Scope and purpose of this document</a>
  13. </ol>
  14. <li><a href="#overview">Overview of project</a>
  15. <ol>
  16. <li><a href="#background">Background</a>
  17. <li><a href="#users">Users</a>
  18. <li><a href="#objectives">Objectives</a>
  19. <li><a href="#constraints">Constraints</a>
  20. </ol>
  21. <li><a href="#func">Functional and data description</a>
  22. <ol>
  23. <li><a href="#arch">System architecture</a>
  24. <li><a href="#data">User data</a>
  25. <li><a href="#boundary">Software and Hardware Boundaries</a>
  26. </ol>
  27. <li><a href="#sched">Projected schedule</a>
  28. <li><a href="#refs">References</a>
  29. </ol>
  30. <a name=intro></a><h2>Introduction</h2>
  31. <a name=scope></a><h3>Scope and purpose of this document</h3>
  32. <p>This document is a functional specification for my 3<sup>rd</sup> year
  33. project: a user registration and administration system for use by the DCU
  34. Networking Society (<a href="http://www.redbrick.dcu.ie">RedBrick</a>). It
  35. will attempt to describe the functional aspects of the project: its
  36. objectives, constraints, system architecture, and functional data description
  37. so that there is enough information for the actual implementation of the
  38. project.</p>
  39. <a name=overview></a><h2>Overview of project</h2>
  40. <a name=background></a><h3>Background</h3>
  41. <p>There are just over 1,800 accounts on the RedBrick UNIX system and so the
  42. administration of user accounts forms a large part of the system
  43. administrators' workload. As one of the system administrators for RedBrick
  44. myself, I have first hand experience of the amount of work required in
  45. administrating user accounts and dealing with account requests on an often
  46. daily basis. In addition to this, each year at the clubs &amp; societies day
  47. the registration of new and renewal of existing users takes place. Hundreds
  48. of users are processed on a small isolated network of computers. The goal of
  49. this project is to reduce the workload of system administrators and ease the
  50. administration and registration of users both on a daily basis and for the annual
  51. clubs and societies day.</p>
  52. <a name=users></a><h3>Users</h3>
  53. <p>The users of the system will be restricted to the system administrators
  54. for day to day user administration as it requires root (superuser) access, however
  55. for registration on clubs &amp; societies day it is usual for other members of the
  56. society committee to help out.</p>
  57. <a name=objectives></a><h3>Objectives</h3>
  58. <ul>
  59. <li><p>Provide an automated and consistent (UNIX command line) interface
  60. for performing both common day-to-day and occassional "batch" user
  61. administration operations on the actual accounts (home directories,
  62. mail spools, disk quotas etc.), the UNIX <code>/etc/passwd</code>
  63. "database" and the user database ensuring that all are kept in sync.
  64. Single user account operations would include:</p>
  65. <ul>
  66. <li>adding new accounts,
  67. <li>deleting existing accounts,
  68. <li>renaming existing accounts,
  69. <li>converting existing accounts "usertype",
  70. <li>renewing existing accounts,
  71. <li>reseting accounts with new random password (and emailing password
  72. to user)
  73. <li>retrieving account information for display,
  74. <li>checking the availability of usernames for new accounts,
  75. </ul>
  76. <p>Batch account operations would include:</p>
  77. <ul>
  78. <li>emailing renewal reminders to non-renewed accounts
  79. <li>expiring non-renewed accounts (i.e. disabling login shell)
  80. <li>deleting non-renewed accounts after a grace period
  81. <li>checking for inconsistencies between the user database and the
  82. UNIX <code>/etc/passwd</code> database
  83. <li>interactive update of the user database from the latest copy of
  84. the public DCU student database
  85. </ul>
  86. <li>Provide a web interface to offer a similar set of single user
  87. administration operations for use on the clubs &amp; societies day. The
  88. setup is generally that of a small number of networked computers that are
  89. isolated from the RedBrick servers so changes would be made to a local
  90. (seperate) copy of the user database and at the end of the day all of
  91. these changes (i.e. new, renewed, renamed, converted, etc. accounts) must
  92. be detected and synchronised with the actual accounts and UNIX
  93. <code>/etc/passwd</code> database on the system. This needs to be done
  94. in batch as hundreds of accounts are processed on clubs &amp;
  95. societies day. This would be implemented as one of the command line
  96. interface's batch operations.
  97. <li>Prevent username conflicts with other namespaces on the system
  98. e.g. email aliases, mailing lists.
  99. </ul>
  100. <a name=constraints></a><h3>Constraints</h3>
  101. <ul>
  102. <li>All accounts must have a name (or description) and an alternate
  103. email address for contact purposes (and as such all UNIX accounts must
  104. have a corresponding entry in the user database).
  105. <li>Users may only have one account on the system (i.e. one student ID
  106. per account).
  107. <li>Member, staff and associate accounts must have a valid DCU
  108. student/staff ID associated with them.
  109. <li>Usernames will be limited to what the underlying UNIX OS supports
  110. in terms of acceptable characters, length etc.
  111. </ul>
  112. <a name=func></a><h2>Functional and data description</h2>
  113. <a name=arch></a><h3>System architecture</h3>
  114. <p>The system will be 3 tier in nature:</p>
  115. <p><b>Front end</b></p>
  116. <p>There will be two client applications: a CGI web interface (primarily for
  117. use on the annual clubs &amp; societies day to register new members and renew
  118. existing members) and a UNIX command line interface for day-to-day user
  119. administration.</p>
  120. <p><b>Middle end</b></p>
  121. <p>There will be two modules which the two client applications (and any
  122. potential future applications) will use. One will be for performing database
  123. operations (RBUserDB) and the other for UNIX account operations (RBAccount).
  124. The web interface will not make use of the UNIX account module however, as it
  125. operates on the database only.</p>
  126. <p><b>Back end</b></p>
  127. <p>Database (likely to be PostgreSQL) which will contain tables for the actual
  128. user database and associated information, e.g. local copy of the public DCU
  129. student database, table of valid usertypes, additional reserved usernames,
  130. etc. Will also contain copies of user database from previous years for
  131. reference/archival purposes.</p>
  132. <a name=data></a><h3>User data</h3>
  133. <p>The traditional UNIX <code>/etc/passwd</code> database doesn't contain
  134. enough information for user accounts for RedBrick's needs (nor does it support
  135. complex queries that a database can) hence the need for a user database. The
  136. following additional information will be kept for all UNIX accounts:</p>
  137. <dt>Username</dt>
  138. <dd>Unique UNIX username.</dd>
  139. <dt>Name/Description</dt>
  140. <dd>User's full name or a description for non-user accounts (e.g.
  141. project/system accounts).</dd>
  142. <dt>Usertype</dt>
  143. <dd>Corresponds to both UNIX group and type of user. The following usertypes
  144. will be used: member, staff, associate, project, club, society, committee,
  145. project, guest, system, reserved.</dd>
  146. <dt>Email</dt>
  147. <dd>Alternate contact address (typically DCU email address).</dd>
  148. <dt>Student ID</dt>
  149. <dd>DCU student (or staff) ID number, compulsory for member, staff and
  150. associates.</dd>
  151. <dt>Years paid</dt>
  152. <dd>Number of years paid. (Non-renewed accounts will be zero).</dd>
  153. <dt>Updated by</dt>
  154. <dd>Username of the administrator who last updated the database entry.</dd>
  155. <dt>Updated at</dt>
  156. <dd>Date &amp; time of when the database entry was last updated.</dd>
  157. <dt>Created by</dt>
  158. <dd>Username of the administrator who first created the account.</dd>
  159. <dt>Created at</dt>
  160. <dd>Date &amp; time of when the database entry was first created.</dd>
  161. <a name=boundary></a><h3>Software and Hardware Boundaries</h3>
  162. <p>The project will use the OS native command line tools for performing all
  163. UNIX <code>/etc/passwd</code> operations and the majority of account
  164. operations. The 3rd party utility <code>setquota</code> will be used for
  165. the modification of disk quotas. DCU student information will be retrieved
  166. from the publically accessible LDAP service on <code>atlas.dcu.ie</code>.</p>
  167. <a name=sched></a><h2>Projected schedule</h2>
  168. <dt>Week 1</dt>
  169. <dd>Design database (SQL schema &amp; populating with sample data). Code
  170. middle end database module (addition, retrieval and updation of user
  171. information, user data checking functions).</dd>
  172. <dt>Week 2</dt>
  173. <dd>Code middle end account module (interaction with UNIX account utilities
  174. &amp; filesystem manipulation of user accounts).</dd>
  175. <dt>Week 3</dt>
  176. <dd>Code command line interface (single user operations) in parallel with
  177. 'unit testing' of the various database and account module functions.</dd>
  178. <dt>Week 4</dt>
  179. <dd>Code web interface.</dd>
  180. <dt>Week 5</dt>
  181. <dd>Work on batch operations.</dd>
  182. <dt>Week 6</dt>
  183. <dd>Final testing. Write up documentation: Technical manual, User manual,
  184. Installation manual.</dd>
  185. <a name=refs></a><h2>References</h2>
  186. <h3>UNIX (Solaris) user administration tool manpages</h3>
  187. <ul>
  188. <li><a href="http://www.uwsg.iu.edu/usail/man/solaris/useradd.1.html">useradd</a>
  189. <li><a href="http://www.uwsg.iu.edu/usail/man/solaris/usermod.1.html">usermod</a>
  190. <li><a href="http://www.uwsg.iu.edu/usail/man/solaris/userdel.1.html">userdel</a>
  191. </ul>
  192. <hr>
  193. $Id: func-spec.html,v 1.1 2003/03/28 16:33:07 cns Exp $
  194. </body>
  195. </html>