Proposal to Improve the Student Activity Server
Spring 1999
Submitted to:
Al Williams
Director, Distributed Systems Group
Center for Academic Computing
Jim Kerlin
Deputy Director
Center of Academic Computing
Stan Latta
Director
Unions and Student Activities
March 29, 1999
Table of Contents
Introduction
Issue 1 - Physical Access to Server
Issue 2 - Hardware and Software Upgrades
Issue 3 - System Security
Issue 4 - Backups
Issue 5 - Kerberos
Issue 6 - AFS/DFS file sharing
Issue 7 - Organizational Status
Summary
Introduction
The Student Activity Server (SAS) currently provides a home on the Internet to over 350 student
groups at many Penn State campuses. Since its beginning in 1996 with a donation from the Center for
Academic Computing, it has grown to be the default choice for web service for Penn State student
organizations, currently housing an estimated 75% of all organizations.
This service is invaluable for many reasons. First, it allows more than one user to maintain a group's
web page. This lets groups design better and more elaborate sites, and it also reduces the temptation for
users to share passwords. It also has a larger, more flexible disk quota than the personal server. Lastly, it
allows student organizations to keep their web site located at one authoritative reference for as long as the
group exists as opposed to moving it between personal accounts.
In the three years since the server has been running, its hardware and software have become
insufficient to meet the growing demands of our users. The loss of console access to the machine for the past
year due to security concerns in the computer room has made our jobs much more difficult and prevented
much-needed hardware and software upgrades. This includes the installation of patches for known security
vulnerabilities in the operating system and Internet server software.
Our efforts have allowed us to perform basic account and system maintenance using our limited
remote administration tools. These tools are very unstable, though, and frequently require a server reboot to
use. Sometimes a common software failure prevents us from rebooting the server remotely, and we are
forced to rely on CAC's assistance to remedy the situation. This means prolonged downtime for our users,
and wasted time of CAC personnel. We are fortunate now to have close ties with CAC to provide this in the
meantime because some of us work for CAC, but it is bad practice to rely on for the benefit of future SAS
staff. Some software failures are as extreme as denial of service for our 1,000+ ftp users, and we have been
anticipating the likelihood of complete server crashing and rebooting.
The committee is unsatisfied with the current level of service we are providing to student
organizations. To improve our quality of service, we need the help of the CAC. We have put together the
following list of requests. We have designed this proposal to be modular, so that the possible failure or delay
of any project may not directly affect the success or completion of any other project.
Issue 1 - Physical Access to Server
Problem
The server is currently located in 134 Computer Building. For the past year, the student
administrators have not been allowed to access the server console. Because the server software was not
prepared for remote administration, we have had difficulty maintaining it.
We have been unable to install updates to the operating system or web server software. This opens
us up to security vulnerabilities that have been fixed in newer Service Pack releases. The hard disk also
needs to be reconfigured to avoid perpetual problems with disk space. Most notably, the C: drive where the
OS and user databases are held is within kilobytes of maximum, and virtual memory reaches full in a matter
of hours after reboot. Without console access, we cannot even provide an immediate fix of expanding the C:
drive into the now unused D: partition, and reconfigure the swap storage.
It is also impossible to fix broken services such as ODBC and FrontPage Extensions. We would also
like to offer other services such as mailing lists and newsgroups to our members. All of this will require
access to the console of the machine at some point.
Proposed Solution
CAC's security concerns for the computer room are quite valid. Since our server currently runs an
operating system that requires console access for anything more than trivial account and file maintenance,
we would like to move the server to a more accessible location. An upstairs room in the Computer Building
would be ideal for this. The server would still be in a physically secure location, because the rooms are not
generally accessible to the public. During regular business hours, though, the student administrators would
be able to access the console to perform needed maintenance.
Moving the server will necessarily require some server downtime. The machine will of course have
to be unplugged, and its IP address may even have to change. We would like to minimize this downtime, by
coordinating an effort with network administrators and other personnel involved. We would prefer to
participate in the move if possible.
Issue 2 - Hardware and Software Upgrades
Problem
The server's hardware and software are outdated. Our biggest problem is memory: 32 MB of RAM
is not nearly enough to run a Windows NT web server. Over 70 MB of swap space is in use on average.
This makes the server very slow when it is under heavy load or when we try to do anything with it other than
serve web pages. This includes using the telnet server and accessing files via SMB, our two main methods of
remote administration.
As the machine is already at capacity, we cannot offer new services to groups such as distributed
filesystems, mailing lists, and newsgroups. Also, when Windows 2000 (NT 5.0) is released, it will most
likely require significantly more resources than NT 4.0.
The server is currently running Microsoft Internet Information Server 3.0 without any encryption
services installed. All ftp and web administration passwords are sent in the clear. While it may not be
practical to encrypt all ftp transactions without wide spread client support, we feel that all administrative
transactions should be protected, perhaps via an SSL module or digital certificates (see Item #3).
Proposed Solution
We would like to have a new machine that we can install, configure, and bring online before the
current server becomes overwhelmed. The necessary configuration of the new machine could take place
while the existing server remains online, thus minimizing downtime. Once the new server is ready to "go
live" we could simply transfer the user database and web sites from the old server and change the DNS
servers to point to the new machine. This new machine would ideally be of Pentium II class or similar
generation Intel based hardware, with at least 128 MB of RAM and a larger hard disk.
We would also wish to preserve the current machine for our own uses. We would also like to keep it
for use as a test server, to evaluate new software and updates before installing them on the main server. The
old machine would also be of use as a backup server and as a backup web server.
We are also interested in using extra DNS entries for our two hosts. One example we had in mind
was labeling the original server as interface1.cac.psu.edu, and the new server as interface2.cac.psu.edu using
"A" (IP address) resource records. The server we wish to be running at any point could be assigned the
"official" DNS of interface.cac.psu.edu, changing only that one "A" record to match the IP address of the
running server. The two nicknames, www.clubs.psu.edu and ftp.clubs.psu.edu, would follow the "official"
canonical name without any additional configuration.
In considering the means of a budget to sponsor our requests, I have found favorable response in
CAC helping us once again. If we need more funds beyond what CAC is ready to supply now, we may also
query with the University Park Allocation Committee (UPAC) for assistance.
Issue 3 - Security
Problem
The current configuration for the server is inadequate for effective administration or security. We
have resorted to partial solutions such as the NT Wed Admin tool and the NT telnet server to perform
administrative tasks. These use no encryption and are unstable. Newer versions of the software address
these problems, but installation is difficult without console access (see above).
Without console access, we are unable to perform complete administration. Many services we have
provided in the past such as ODBC, FrontPage, and new ones such as SSL, and Kerberos can not be
functional without console development. We also cannot upgrade the web server software, adjust the disk
space usage or any other hardware upgrade, or apply security patches.
Account management and passwords also pose their own problems. Users are provided a password
to use for the server over email. This not only travels in clear-text, but may also sit for extended periods of
time in insecure places such as mail spools and shared media. It is unclear to many users that this password
is for individual use only. This confusion leads to password sharing, which is common among our uses. The
extended duration of time it takes to request a new account due to our hardcopy application s also
compounds the problem by making password sharing even more appealing.
Even those users who understand that their password is for personal use only do not feel
compromised if their password is discovered, since it is only for the club space, and not for additional
services such as personal email. Further confusion occurs because this password is different from their
Access Account password, since users have the same userid on the clubs server as their Access ID.
The hardcopy forms we use for account requests are too slow for all parties involved. It takes much
too long for us to process the forms, interpret handwriting, and email for more information when
discrepancies are found. It is also discouraging for applying account holders since they do not get immediate
results when they submit form (as is provided, for example, by the account management services on
www.work.psu.edu). Forms take an average of two to three weeks to process, while the personal service
request requires merely two to three business days to be set up.
Proposed Solution
We would like to attend to these needs as stated with a move of the console (Issue #1), hardware
upgrade (Issue #2), change of authentication system (Issue #5), and increased automation of the application
process. Many of these needs such as the installation of SSL, new scripts and hard disk setup can be done
after console access is re-acquired. We also would like an authoritative digital certificate for SSL use, if
possible. Using a certificate which bears CAC's name and digital identity may be ideal. If not, we may use
our own certificate.
Issue 4 - Backups
Problem
The server currently has no backups of the operating system or users' data. If the server's disks were
to fail, the server would be down for days or weeks until it could be completely reinstalled. While users
should be keeping copies of their pages, some groups undoubtedly do not.
Proposed Solution
Since the CAC already provides network-based backup services, this service would be the most
natural choice for backup. The most important data is currently the operating system and server
configuration. This would make restoring the server after a disk c rash much easier. If possible, we would
like to have the web documents backed up as well to further minimize the disruption caused by a disk
failure.
If network backup from the CAC is not possible, we would like to purchase a tape drive for the
machine. This will be less convenient, though, because someone will have to change the tape in the drive on
a regular basis. Use of a tape backup will also require our physical access to the server as discussed above.
Issue 5 - User authentication
Problem
The server currently maintains its own accounts and passwords for users. This means that users must
remember a separate password for our service than for the rest of their Penn State accounts. Also, we have
no easy way of determining when an account should be deleted. Users who are no longer associated with the
University currently do not get their accounts removed.
Proposed Solution
We would like to use the University's Kerberos capabilities for user authentication and a local
database for authorization to resources on the clubs server. This would provide us with the maximum
flexibility in user management, in that it would address the password problems discussed above (Item 3) but
not open the clubs server up to anyone with a valid Access ID. We would still add users to our system, so it
would not be open to just anyone with an Access Account. This would let users have only one pass word,
and would automatically deny access to users who no longer had an Access Account.
We realize that Kerberos may not work well with Windows NT 4.0. If we are able to acquire a new
server in the near future, we could install a Unix-based operating system (such as Solaris x86) on the old
machine and use it as an authentication server if Unix based Kerberos is easier.
We will need a good deal of help from CAC personnel to make this work. While some members of
the committee are familiar with Kerberos, we are certainly not experts.
Issue 6 - Distributed Filesystems
Problem
The CAC currently has a site license for AFS and DFS from Transarc Corporation. These
distributed filesystems can provide us and our users with more flexibility in maintaining their files. It will
also be more secure than transmitting passwords in the clear via FTP.
Proposed Solution
We would like to explore the possibility of making the server's files available via AFS or DFS. This
will provide our users and administrators with an alternative to ftp and SMB sharing for file access. Again,
this will require help from CAC personnel.
Issue 7 - Organizational Status
Problem
Originally, the server was run by Interface, which was an official student organization under the
auspices of USG. During the summer of 1998, Interface's official status was revoked due to a lack of
members. At that time our mailbox in the HUB Desk was also removed.
After the demise of Interface, no one was processing applications for the server. The current
members of the committee have become involved out of personal motivation and a commitment to keep the
clubs server online.
We were approached by USG last spring about the closing of Interface, and the idea of building the
Student Activity Server Committee under their ownership. The USG Supreme Court had ratified us as
becoming the Committee, however new leadership and word of the new HUB networks had prevented the
plan from finishing by Fall of 1998.
The Student Activity Server Committee currently has no official parent organization. We currently
have no mailbox for accepting applications and no budget. Most importantly, we have no official
authorization to exist. If our current contacts in the CAC were lost, someone could pull the plug on the
server and we would have no one to turn to for support.
Proposed Solution
We would like to become a part of an official organization on campus. The two logical choices for
this are the CAC and USG. The CAC provided the initial hardware for the service, provides the network
connectivity, and provided technical assistance through out the past three years. USG is the umbrella
organization for the student groups we serve. The Office of Student Activities may also be a choice for us.
They may have better control over student organizations than USG and especially CAC.
We would also wish to request help in finding a new mailbox before the need for hardcopy
applications is eliminated in favor of electronic submittal methods. One alternative is the accounts office, or
an "honorary" mailbox with the HUB. We would prefer a more secure location than the HUB for we have
lost several applications there. It is also imperative that we find a new mailbox by the semester's end since
applications are currently handled through the SAS coordinator's personal mailbox.
Summary
We realize that many challenges confront us in the near future. The policy to have students work on
the server versus not, who will take ownership of the committee and/or server administration, and the details
of future projects all need to be discussed. Yet we of the Committee are committed to pursuing the best
service possible to the University and wish to improve the service in the very necessary ways we can to the
best of our ability in the near future. We wish that the agents we call upon may help us first proceed with
the time critical objectives, such as hardware access and upgrades, and a mailbox before the semester ends.
We also wish to continue our efforts to streamline the service to the benefit of the student organizations, and
the ease of the administrators with the conscious effort of improved security in the following year. We ask
each of you to speak what you and your organization can provide for us and what your plans are to help.
The key to our success is coordination.
Thank you for your time and consideration.
The Student Activity Server Committee - ActivityServer@psu.edu
Proposal authors:
Jeff D'Angelo <dangelo@cse.psu.edu> - Coordinator
James Juran <jrj120@psu.edu>
Derek Morr <dvm105@psu.edu>
Contributors and SAS staff:
Rob Bender <rgb@worldofcheese.org>
Jason Nichols <jwn114@psu.edu>
Paul Rentschler <prentschler@talon.net>
Benjamin R. Hauger <redevil@psu.edu>
Rich Underwood <rxu105@psu.edu>
Buck Thompson <buck-thompson@psu.edu>
Bob Meier <bmeier@psu.edu>
Jeff Schlanger <jds222@hotmail.com>
Eric Prescott <prescott@cse.psu.edu>
Randy Ward <jrw186@psu.edu>