WWW2 upgrade project

Current situation

Www2 is a Sun Sparcstation 20 (55MHz). It currently runs SunOS 4.1.4 modified for Athena and a customized version of the NCSA 1.5a web server. This configuration has many problems: SunOS has a memory leak(?), the web server crashes several times a day. It is also woefully short of local disk space (it is no longer possible to maintain 10 weeks worth of logs (10 weeks = 1 quarter). The web server is outdated and is missing several features (mod_perl, SSL, no FrontPage Extensions).

Here is a look at the disk space used by the web server: usage summary sorted by unit and sorted by size, and broken down by file types sorted by unit and sorted by size,

Desired features

• Reliable delivery of HTML pages and other standard MIME types.
• Server-side includes (SSI) for .shtml pages.
• Secure server (SSL) https.
• Ability to use ~username in URLs.
• Ability to use both ftp and http 1.1 to upload files.
• Cgi-bin scripting in Perl (other languages?).
• Search engine able to index both the local file system and other servers.
• Log analysis tool.
• Authentication (Kerberos and AFS):
  • Access to CATS services database (i.e. Moira). For example: change password, register for ISSP, new accounts, vacation program.
  • Writing into the AFS file system on behalf of a user. For example: set up .forward file, submit homework.
  • Distribute and download software. For example: Eudora Pro, ISK.
• Access restrictions by domain, by IP address, by password.
• Virtual multihosting. This lets the server assume multiple names and IP addresses so that one server can be used to deliver pages under different names if policy dictates. For example, units under units.ucsc.edu/unitname, student/faculty/staff personal pages under people.ucsc.edu/~username,...

Additional features for phase 2

• Running cgi-bin scripts under the UID of the owner of the script, rather than the web server UID: cgiwrap.
• FrontPage Extensions for MS FrontPage users.
• Server-side HTML embedded scripting language (ASP-like pages): e.g. PHP.
• Database access: e.g. Oracle, mySQL, FileMaker?

Proposed hardware upgrade

The current server could be upgraded at minimal cost ($2,500) by doubling its current memory (from 128K to 256K), and by installing a second processor. This is a good stopgap measure until we can better evaluate the impact of the new capabilities and additional users (e.g. NetTrail, Matman,...).

A better longer term solution would be to get an Ultra 10 ($5,000 - $6,000) to have adequate reserve needed by the proposed new capabilities, and new users. The proposal below assumes the latter.

Proposed software upgrade

• Solaris 7 with:
  • CATS/Athena user authentication.
  • AFS authentication with AFS Web Security Pack.
  • /etc/password for ~username redirection.
• Apache 1.3.6 with:
  • SSL patch.
  • Mod_perl.
  • FrontPage Extensions (see Paul Tatarsky's security review).
• Perl 5.005_03 (may not be needed if mod_perl is installed).
• PHP 3 (to get ASP-like capabilities). It is an HTML embedded scripting language which supports a number of RDBMS packages (e.g. MySQL, Oracle, Sybase). (Could be part of phase 2).
• mySQL (to get database capabilities). This could reside on another server. (Could be part of phase 2).

Advantages

• Sun no longer supports SunOS; Solaris is the currently supported OS.
• Hooks to authenticate users, and run under the AFS file system.
• NCSA web server has long been abandoned, and replaced by Apache which, although based on NCSA code, has had all its known bugs fixed, and has new features (e.g. multihosting, SSL, mod_perl), and many optional modules.
• New features:
  • FrontPage Extensions are available for Solaris/Apache.
  • SSL gives us the ability to collect and transmit passwords securely.
  • Mod_perl preloads the Perl interpreter, so that a new Perl instance no longer need to be generated every time a Perl script runs.
  • PHP 3 gives users the ability to customize their pages from the simple (e.g. counter) to the complicated (database access).

Migration path

With a new server, the new server can be configured independently, and placed in production after testing. Once placed in service, including NetTrail, sparky could be configured similarly, and used as a development machine to test new software before being deployed (e.g. phase 2).

Otherwise, if a new server is not available, it might be possible to use sparky for the conversion since www2 cannot be taken down for an extensive time period. Sparky is a Sparstation 5 (110MHz); it already runs Solaris 2.6, AFS, Apache 1.2. It is fairly similar to the current server bombalurina: twice as fast (110 vs. 55 MHz), but with less memory (96K vs. 128K), it should be able to handle the traffic.

1. Upgrade/install sparky/new server to Solaris 7, AFS, Apache 1.3.6 (with SSL, mod_perl), AFS Web Security Pack, Perl 5.
2. Test Perl scripts (weblog, websearch, finger/ldap directories).
3. Test other CATS scripts, NetTrail, ERSYS.
4. Notify unit web administrators to test their pages under sparky/new server (especially those using cgi-bin scripts).
5. Change DNS to make sparky/new server the new www2.
6. Configure bombalurina/sparky as a development system with the same base software: Solaris 7, AFS, Apache 1.3.6 (with SSL, mod_perl), AFS Web Security Pack, Perl 5.

Phase 2

Install FrontPage Extensions, PHP, SQL server.

Time frame

Notify users of plans as soon as possible.

1. Configure sparky/new server after finals in March 2000.
2. Test sparky/new server last 2 weeks of March.
3. Switch www2 to sparky/new server end of March.
4. Configure and test development server in April.

Other issues

Sparky currently runs NetTrail. If sparky is to be used as the new server, we would need to suspend NetTrail for a couple of weeks during the quarter break. With a new server, this issue vanishes since it sparky would not be touched until the conversion has been completed.

At the end of this upgrade, sparky would be configured identically to www2, and could be used as a test bed to introduce new technologies. It could also replace www2 in emergencies by simply changing the DNS tables.