ResNet Online: Difference between revisions
Jump to navigation
Jump to search
(New page: ResNet Online was [http://www.bryant.edu/ Bryant University's] network registration and information site for computers in the university's residence halls. It has since been superseded by ...) |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
ResNet Online was [http://www.bryant.edu/ Bryant University's] network registration and information site for computers in the university's residence halls. It has since been superseded by wireless networking and other computer information tracking mechanisms. | [[Image:ResNet-Login.png|thumb|right|350px|ResNet Online's login page, which directs the user to log in using their email username and password]] ResNet Online was [http://www.bryant.edu/ Bryant University's] network registration and information site for computers in the university's residence halls. It has since been superseded by wireless networking and other computer information tracking mechanisms. | ||
==Motivation== | |||
While I was a junior at Bryant University, I sought to substantially improve the residence hall computer registration process. Previously, registration was a manual process that could take as long as three weeks between the time a student registers a computer and the time that the student's port is enabled. At the end of the Summer of 1999, I designed and implemented an automated process to handle residence hall computer registrations, making the process on-demand for students. My position as a residence hall computer consultant at the university enabled this to happen as I already knew the relevant contacts to make the system official. At the beginning of the Fall semester of 1999, students were able to quickly enable their residence hall Ethernet ports, and the system properly handled the load without failing. | While I was a junior at Bryant University, I sought to substantially improve the residence hall computer registration process. Previously, registration was a manual process that could take as long as three weeks between the time a student registers a computer and the time that the student's port is enabled. At the end of the Summer of 1999, I designed and implemented an automated process to handle residence hall computer registrations, making the process on-demand for students. My position as a residence hall computer consultant at the university enabled this to happen as I already knew the relevant contacts to make the system official. At the beginning of the Fall semester of 1999, students were able to quickly enable their residence hall Ethernet ports, and the system properly handled the load without failing. | ||
| Line 9: | Line 10: | ||
*FTP-based authentication against Bryant University's IRIX sever for logins | *FTP-based authentication against Bryant University's IRIX sever for logins | ||
*Frequently asked questions that linked to each other using a simplified syntax similar to modern wiki software | *Frequently asked questions that linked to each other using a simplified syntax similar to modern wiki software | ||
*Administrative Ethernet port management that used asynchronous communication with the web server to enable and disable ports | *Administrative Ethernet port management that used asynchronous communication with the web server to enable and disable ports. This was years before XMLHttpRequest existed and AJAX was a buzzword | ||
**This was accomplished by communicating with the server by changing the image location of a progress bar to include the commands and the percentage to display in the URL's query parameters. The PHP script on the server enabled or disabled the requested ports and returned an image of the progress bar. If an error occurred, a HTTP error was returned. JavaScript on the client side handled success and error scenarios | **This was accomplished by communicating with the server by changing the image location of a progress bar to include the commands and the percentage to display in the URL's query parameters. The PHP script on the server enabled or disabled the requested ports and returned an image of the progress bar. If an error occurred, a HTTP error was returned. JavaScript on the client side handled success and error scenarios | ||
*Wizards persisted the data entered thus far into a PHPLib session, enabling students to complete a wizard between several sessions without having to re-enter any information during subsequent sessions | *Wizards persisted the data entered thus far into a PHPLib session, enabling students to complete a wizard between several sessions without having to re-enter any information during subsequent sessions | ||
| Line 15: | Line 16: | ||
*Squid proxy server statistics using a customized version of Prostat | *Squid proxy server statistics using a customized version of Prostat | ||
**I customized Prostat to retain its state into a file so that subsequent runs do not need to re-parse the log file parts that the previous run had processed. This substantially increased Prostat's summarization performance as I had it automatically run every 5 minutes for up-to-date statistics | **I customized Prostat to retain its state into a file so that subsequent runs do not need to re-parse the log file parts that the previous run had processed. This substantially increased Prostat's summarization performance as I had it automatically run every 5 minutes for up-to-date statistics | ||
*DialPad proxy status information for the underlying DialPad proxy that I had set up | *[http://en.wikipedia.org/wiki/Yahoo%21_Voice DialPad] proxy status information for the underlying DialPad proxy that I had set up using [http://sovereignit.com/linux2.2/docs/ipmasqadm.man.txt ipmasqadm autofw] | ||
Please feel free to see the above capabilities in action through the screen shots below. | |||
==Port Registration Wizard== | |||
When a student logs in, they are asked to select their hall and register their computer through the following sequence of pages. Students do not need to enter all information in one session; a PHPLib session stored any entered information until it was committed to the main database at the end of the wizard. The flow of the wizard largely reveals the database table relationships in ResNet's normalized MySQL database. | |||
{| | |||
|[[Image:ResNet-HallSelection.png|thumb|center|350px|Before the wizard begins, students are asked to select their residence hall from an image map. Bryant University has since added several new buildings, making this a historical photograph]] | |||
|[[Image:ResNet-Wizard1.png|thumb|center|350px|Students are asked for their identifying information. If their information was publicly visible in the [https://www.moonlightdesign.org/dirlist/ DirList database], most fields were pre-populated to reduce the amount of data entry required]] | |||
|- | |||
|[[Image:ResNet-Wizard2.png|thumb|center|350px|The pre-release version initially asked for the number of computers to register, but it was decided that the wizard should be limited to just one computer per registration in the first release]] | |||
|[[Image:ResNet-Wizard3.png|thumb|center|350px|Students are asked for the number of operating systems and virus scanners on their computer. Similar to computer counts, network card counts were locked to one for the final release]] | |||
|- | |||
|[[Image:ResNet-Wizard4.png|thumb|center|350px|Students are asked for their network card and virus scanner information. ResNet Online had a database table with a long list of all virus scanners that I could find at the time on Google. The data model allowed students to register computers in other residence halls, though this capability was likely not needed. Instructions for obtaining a [http://en.wikipedia.org/wiki/Media_Access_Control media access control (MAC) address] were written for all major operating systems, including [http://en.wikipedia.org/wiki/Red_Hat_Linux RedHat Linux]]] | |||
|[[Image:ResNet-Wizard5.png|thumb|center|350px|In this final step, students were asked for the wall network port that they plugged their computer into. Some residence halls had stickers with long strings of letters and numbers that did not match the example, so I created a client-side JavaScript-based port wizard that asks for that string along with which side they are plugging into (left or right), and the port wizard then automatically selected the appropriate port from the drop-down list from that information]] | |||
|- | |||
|[[Image:ResNet-WizardComplete.png|thumb|center|350px|After the port is activated, the data is committed to the database, and the student is notified. Behind the scenes, this process turned on the port using SNMP and saved the Cisco switch's NVRAM using a quick telnet session]] | |||
|} | |||
==Profile Editing== | |||
In addition to registering computers, students can modify their contact information and where their computers are located. | |||
{| | |||
|[[Image:ResNet-ProfileEditMenu.png|thumb|center|350px|A simple menu asks students what they want to modify]] | |||
|[[Image:ResNet-Move1.png|thumb|center|350px|Students select which hall they are moving to as well as which computers they are moving]] | |||
|- | |||
|[[Image:ResNet-Move2.png|thumb|center|350px|Students select the room and port that each computer is being moved into]] | |||
|[[Image:ResNet-MoveFinished.png|thumb|center|350px|When the wizard completes successfully, the student is notified with this page]] | |||
|- | |||
|[[Image:ResNet-ErrorHandling.png|thumb|center|350px|When errors occur, such as when the switch's NVRAM could not be saved, administrators are notified via email, and the student sees a page such as the one above]] | |||
|} | |||
==Contact Residence Hall Computer Consultant== | |||
Students can easily contact a residence hall computer consultant (RCC) for network and computer related questions. ResNet Online had a database table that contained information about which students are RCCs for each hall. Because a student's registration knows which hall they live in, requests for help were routed to the proper RCC or RCCs. | |||
{| | |||
|[[Image:ResNet-ContactRCC.png|thumb|center|350px|RCC contact form]] | |||
|} | |||
==Port Editing== | |||
{| | |||
|rowspan="2" valign="top"|[[Image:ResNet-Ports.png|thumb|center|350px|]] | |||
|valign="top"|[[Image:ResNet-PortGroup.png|thumb|center|350px|]] | |||
|- | |||
|valign="top"|[[Image:ResNet-PortStack.png|thumb|center|350px|]] | |||
|} | |||
==Frequently Asked Questions== | |||
[[Image:ResNet-SOCKS.png|thumb|center|350px|]] | |||
==Museum== | |||
[[Image:ResNet-Museum.png|thumb|center|350px|]] | |||
==DialPad Status== | |||
[[Image:ResNet-Dialpad.png|thumb|center|350px|]] | |||
==Network Traffic Graphs== | |||
[[Image:ResNet-MRTG.png|thumb|center|350px|]] | |||
==Web Proxy Statistics== | |||
Latest revision as of 02:39, 28 October 2007
ResNet Online was Bryant University's network registration and information site for computers in the university's residence halls. It has since been superseded by wireless networking and other computer information tracking mechanisms.
Motivation
While I was a junior at Bryant University, I sought to substantially improve the residence hall computer registration process. Previously, registration was a manual process that could take as long as three weeks between the time a student registers a computer and the time that the student's port is enabled. At the end of the Summer of 1999, I designed and implemented an automated process to handle residence hall computer registrations, making the process on-demand for students. My position as a residence hall computer consultant at the university enabled this to happen as I already knew the relevant contacts to make the system official. At the beginning of the Fall semester of 1999, students were able to quickly enable their residence hall Ethernet ports, and the system properly handled the load without failing.
In addition to the registration process, ResNet Online included the following features:
- Computer moving wizard
- Student profile update page
- Integration with Bryant University's DirList2 student database to automatically retrieve student names, email addresses, and phone numbers, simplifying data entry for students
- FTP-based authentication against Bryant University's IRIX sever for logins
- Frequently asked questions that linked to each other using a simplified syntax similar to modern wiki software
- Administrative Ethernet port management that used asynchronous communication with the web server to enable and disable ports. This was years before XMLHttpRequest existed and AJAX was a buzzword
- This was accomplished by communicating with the server by changing the image location of a progress bar to include the commands and the percentage to display in the URL's query parameters. The PHP script on the server enabled or disabled the requested ports and returned an image of the progress bar. If an error occurred, a HTTP error was returned. JavaScript on the client side handled success and error scenarios
- Wizards persisted the data entered thus far into a PHPLib session, enabling students to complete a wizard between several sessions without having to re-enter any information during subsequent sessions
- Traffic graphs from the multi-router traffic grapher (MRTG)
- Squid proxy server statistics using a customized version of Prostat
- I customized Prostat to retain its state into a file so that subsequent runs do not need to re-parse the log file parts that the previous run had processed. This substantially increased Prostat's summarization performance as I had it automatically run every 5 minutes for up-to-date statistics
- DialPad proxy status information for the underlying DialPad proxy that I had set up using ipmasqadm autofw
Please feel free to see the above capabilities in action through the screen shots below.
Port Registration Wizard
When a student logs in, they are asked to select their hall and register their computer through the following sequence of pages. Students do not need to enter all information in one session; a PHPLib session stored any entered information until it was committed to the main database at the end of the wizard. The flow of the wizard largely reveals the database table relationships in ResNet's normalized MySQL database.
 Students are asked for their identifying information. If their information was publicly visible in the DirList database, most fields were pre-populated to reduce the amount of data entry required | |
 Students are asked for their network card and virus scanner information. ResNet Online had a database table with a long list of all virus scanners that I could find at the time on Google. The data model allowed students to register computers in other residence halls, though this capability was likely not needed. Instructions for obtaining a media access control (MAC) address were written for all major operating systems, including RedHat Linux |
 In this final step, students were asked for the wall network port that they plugged their computer into. Some residence halls had stickers with long strings of letters and numbers that did not match the example, so I created a client-side JavaScript-based port wizard that asks for that string along with which side they are plugging into (left or right), and the port wizard then automatically selected the appropriate port from the drop-down list from that information |
Profile Editing
In addition to registering computers, students can modify their contact information and where their computers are located.
Contact Residence Hall Computer Consultant
Students can easily contact a residence hall computer consultant (RCC) for network and computer related questions. ResNet Online had a database table that contained information about which students are RCCs for each hall. Because a student's registration knows which hall they live in, requests for help were routed to the proper RCC or RCCs.
