Cal Poly Pomona Intranet
Beta Implementation Plan

* Hardware Implementation
* Software Implementation
* Hardware and Software Components
* Proposed Budget

Hardware Implementation

The existing Intranet prototype platform consists of:

1 Sun Sparc 20
3 DEC Alpha 3000 (building servers)

In order to accommodate Beta testing by at least 200 people during Winter and Spring 1997, the Intranet platform should be expanded to consist of:

3 Sun Sparc 20
2 DEC Alpha 1000
6 DEC Alpha 3000 (building servers)

The precise roles of these machines and their software installations are detailed in the Intranet Software Components. The expansion can be achieved without purchasing additional machines by migrating some existing services into the Intranet environment. Incorporate the existing kiosk server (a Sun Sparc 20), Web server (a Sun Sparc 20), two unused DEC Alpha 1000s, and 3 additional DEC Alpha 3000 building servers into the existing Intranet platform as follows:

  1. The existing kiosk server (kiosksrv) is a Sun Sparc 20 providing one service--a nonstandard commercial hypertext server for a single client in the Library. Migrate the existing kiosk server installation to any Sun Sparc, clear the machine, and install the Solaris Unix v2.5 operating system and Transarc v1.1 Sec, CDS, DTS and DFS clients. Start a research initiative to investigate use of standard HTTP/HTML-based designs for the kiosk server.

  2. The existing Web server (kellogg) is a Sun Sparc 20 relatively overloaded by providing HTTP service (the Cal Poly Pomona Web), full-feed NNTP service (the University news server), and anonymous FTP service (the University FTP archive). Migrate the Web and FTP sites to the Distributed File Service (DFS), which will have the dual benefit of relieving the load on the current Web server and bringing the fully-integrated access controls of DFS to the Cal Poly Pomona Web and FTP archive. Temporarily migrate the NNTP service to another Sun Sparc 20, clear the machine, install the Solaris Unix v2.5 operating system and Transarc v1.1 Sec, CDS, DTS and DFS clients, and reinstall the NNTP server.

  3. The two existing unused DEC Alpha 1000s were purchased about a year ago as a hardware replacement for two old DECStation 5000s which currently provide DNS and mail gateway service. The current mail gateway design relies on inefficient DNS Hesiod record lookups for mail distribution; the current migration plans preserve this design. Mail gateway service should be redesigned to use efficient dbm database lookups for mail distribution. Install the Digital Unix v4.0 operating system and Digital DCE v2.0 Sec, CDS, DTS and DFS clients on both DEC Alpha 1000s, then install the improved mail gateway service.

  4. There are about thirty existing DEC Alpha 3000s in use as building servers. They are running the OpenVMS operating system and Pathworks networking software. This service has been unpopular in many places, and there are a number of locations where these building servers are essentially unused. Identify three unused DEC Alpha 3000s, install the Digital Unix v4.0 operating system and Digital DCE v2.0 Sec, CDS, DTS and DFS clients.



Software Implementation

A detailed table showing the Intranet computers and the specific versions of installed software is presented in the Intranet Hardware and Software Components. The following describes the installed software and the services they provide.

* Operating System (OS)

Unix is the only operating system available today which can meet all of the requirements published in the Intranet Requirements Analysis and Recommendations submitted to the President's cabinet in March 1996. On Sun Sparc computers, the current Unix OS is Solaris Unix v2.5. On DEC Alpha computers, the current Unix OS is Digital Unix v4.0.

* Security (Sec), Cell Directory Service (CDS) and Distributed Time Service (DTS) Client

A Sec client makes requests to a Sec server which involve the security registry, the most frequent of which will be requests for authorization to access a variety of services. A CDS client makes requests to a CDS server to dynamically bind remote procedure calls (RPCs) to the most appropriate provider. This is the mechanism by which service loads are automatically balanced between available service providers, and secondary servers transparently cover for primary servers. A DTS client insures that a machine's clock is synchronized within acceptable tolerance limits of all other machines. Time synchronization is important for accurately determining obsolescence in DCE.

* Distributed File Service (DFS) Client

A DFS client makes the Distributed File System visible on a machine and maintains a local cache on the client machine of recently used files from DFS servers. Community and building servers will act simultaneously as DFS clients and as Appletalk and SMB servers so that a single unified file space will be distributed to all Macintosh and Windows workstation using their native file sharing protocols.

* Security (Sec) and Cell Directory Service (CDS) Server

A Sec server maintains the Security Registry, which is the operating registry of Cal Poly Pomona Intranet users and groups. The Sec server protocol interoperates with almost every networking protocol requiring user authentication. The Sec server will be integrated with the HTTP, SMTP, POP, Appletalk, SMB, and FTP servers, so that access through any of those protocols is obtained using a single username and password, and respects all DCE access controls. The CDS server maintains the directory of remote procedures providing distributed DCE services and binds client requests to the most appropriate provider.

* Distributed Time Service (DTS) Server

A DTS Server provides accurate time to all DTS clients. DTS servers should be synchronized to an accurate provider of Universal Coordinated Time (UTC) using the Network Time Service (NTS) protocol.

* Distributed File System (DFS) Server

A DFS Server tracks the physical location of file sets and serves 64 kilobyte portions of files to DFS clients, which cache them for subsequent requests. The DFS hierarchy is a unified file space shared by all Intranet users. The DFS hierarchy includes user directories, group directories, software directories for various operating systems, web directories, FTP archives, and e-mail boxes. Common software and configurations should be factored into DFS so as to avoid unnecessary or redundant installation and configuration. Each user and group directory forms a file set which can be transparently migrated to any DFS server without disrupting service.

* Backup (Bak) Server Installation

A Bak server manages two-tiered backups of all files in DFS. A daily differential read-only backup is kept online so users can recover lost or accidently deleted files without technical support assistance. Tape backups are made daily and provide snapshots of all files in DFS at increasing intervals into the past.

* Network News Transfer Protocol (NNTP) Server

An NNTP server accepts a full feed of all Internet newsgroups and also maintains local Cal Poly Pomona newsgroups. User-level authentication is not usually supported in the NNTP protocol, so access to the NNTP server will be allowed only to machines in the csupomona domain (machines with IP numbers 134.71.*.*), rather than by username and password, which would be preferred.

* Domain Name Service (DNS) Server

A DNS server maps Internet Protocol (IP) names to IP numbers. The Intranet DNS design would place a secondary DNS server in every building with an Intranet building server, so that important services provided using well-known and intuitively pleasing IP names (e.g., www.csupomona.edu, mail.csupomona.edu, ftp.csupomona.edu, login.csupomona.edu) would be locally overridden by primary DNS entries which cause that service to be provided by the local building server. Distributing workload to the building servers was the intent of the original network design at Cal Poly Pomona, but they were put into service with incongruous IP names and inadequate services which have discouraged their widespread use. Currently, HTTP, SMTP, POP, SQLNet, FTP and telnet clients throughout the campus storm a few central machines to handle all requests, while the building servers sit relatively idle.

* Software Development Installation

All of the software which we have constructed or acquired and built has been written in C, C++, or Perl. The Free Software Foundation developed and distributes the Gnu C and C++ compiler free of charge, and it has become the de facto standard for developing C programs. The Perl interpreter was developed by Larry Wall and is distributed as part of the Gnu Software Archive. An application programming interface (API) which allows direct calls from Perl to the DCE API was developed by Doug MacEachern of the Open Software Foundation (OSF), and he has provided us with an early version of the source code.

* Integrated Hypertext Transfer Protocol (HTTP) Server

Paul Henson has integrated DCE authentication into the Apache HTTP server, and the result is an HTTP server which can serve any document or execute any CGI in DFS, and the access controls which have been placed on these documents or CGIs is fully respected by the HTTP server. Configuring access control is no longer a function of the HTTP server configuration (over which ordinary users have no control), but is a function of the access controls established by file owners in DFS. This design has been so effective that we advocate serving the entire DFS hierarchy, from the root down, including user and group directories. An integrated HTTP server should be installed on the community server and on every building server, so that Web delivery is distributed.

* Integrated Simple Mail Transfer Protocol (SMTP) Server

An SMTP server consists of two parts--the Mail Transfer Agent (MTA) and the Mail Delivery Agent (MDA). The MTA should be configured to properly resolve e-mail addresses so that mail with unqualified addresses finds its way to the correct Intranet mailbox, if it exists; or the correct existing mailbox, if the user has no Intranet mailbox. The MDA should run with sufficient DCE privileges to store e-mail in users' directories in DFS, so that e-mail can be retrieved by the POP server on any machine which acts as a DFS client, either the community server or any building server. An SMTP server should be installed on every building server and should be accessible using the IP name mail.csupomona.edu, so that mail delivery is distributed.

* Integrated Post Office Protocol (POP) Server

A POP server collects delivered mail from users' mailboxes and feeds it to a POP client (e.g., Eudora or Netscape). A POP server should be installed on every building server and should be accessible using the IP name mail.csupomona.edu, so that mail retrieval is distributed.

* Integrated Appletalk Server

An Appletalk server interacts with MacOS machines and allows them to mount portions of DFS on their desktops. The Columbia Appletalk Protocol (CAP) is a robust freeware Appletalk server implemented at Columbia University which can be integrated with DCE authentication, so that the full access controls of DFS are respected in the MacOS/DFS interaction.

* Integrated Server Message Block (SMB) Server

A SMB server interacts with Windows 3.1, Windows NT and Windows 95 machines and allows them to mount portions of DFS on one of their extended drives. Samba is a robust freeware SMB server implemented at the University of Canberra which is already integrated with DCE authentication, so that the full access controls of DFS are respected in the Windows/DFS interaction.

* Structured Query Language (SQLNet) Client

An SQLNet Client can make Structured Query Language (SQL) queries to the university's Oracle database and retrieve results. If the SQLNet client is invoked as part of a Common Gateway Interface (CGI), then the input for the database queries can be taken from a Web form and the results can be hypertext formatted and returned on demand to the browser. This mechanism facilitates arbitrary queries, such as the list of courses currently offered with open seat information, an instructor's class list, a student's grades, class schedule, or transcripts, and many others. An important research initiative is to investigate the integration of SQL queries with DCE authentication, so the same username and password which provides users access to all other computing services can be used to acquire database information on a need-to-know basis.

* Intranet Common Gateway Interface (CGI)

The Intranet CGIs provide a hypertext control interface to various protocols, so that the Intranet environment can be fully managed through any standard Web browser. Many of the Intranet CGIs require DCE privileges to execute, but these restrictions are enforced by the integrated HTTP server through any Web browser. The prototype Intranet CGIs were authored by Paul Henson.

* Oracle Common Gateway Interface (CGI)

The Oracle CGIs provide a hypertext control interface to the university's Oracle database, so that database information can be easily retrieved and/or supplied through any standard Web browser. Together with the integrated HTTP server, it will not be difficult to deliver or collect sensitive information securely through the Web to or from the intended recipient, e.g., grades, transcripts, class lists, budgets, accounts, etc. The prototype Oracle CGIs were authored by Irene Callaci.


Craig A. Rich -- carich@csupomona.edu