What Software Should Be on What Machines?

jimc, 2001-08-09

Mathnet/PICnet consists of a lot of machines controlled by various sets of users, who have a variety of needs. The major user sets are:

• Programmers
• Office Staff
• Applied profs and grads
• Pure profs and grads
• NFS grant supported profs and grads
• Statistics (not for long)

From the administrative point of view, we would like to have the machines be as uniform as possible. Each user constituency would like to have the software they need to do their work. We need to balance those needs.

Machine Categories

The machines are differentiated by purpose, and by architecture. Presently we have four incompatible architectures: Sparc (Solaris 5.5 and 5.6), i386-Solaris, i386-Linux (SuSE and Red Hat), and i386-WinNT. For the most part this discussion is about UNIX, but to some extent it applies to Windows also.

By purpose, there are desktop workstations, home directory servers, compute servers, and system servers (e.g. Fern, Arachne). The distinction between these roles is vague for these reasons:

• Desktop machines tend to be newer and hence are more powerful than the homedir servers. If a user has a desktop machine we prefer that he keeps it busy rather than burdening a general department resource. Powerful desktop machines are our best compute servers.
• Many users have X-terminals or hunk-of-junk desktops; hence all functions appropriate to the desktop machine must also be provided from the homedir server.
• If a person can be convinced to run jobs on a compute server (leaving aside the issue of PBS), he will want to do program development there also, read mail, etc. And it's a purely arbitrary decision to try to push such usage elsewhere, and incidental interactive use will be of no consequence to getting compute jobs through, particularly if the compute server is powerful.
• While we're moving toward dedicated system servers, traditionally we have used the servers (Malibu, Julia) as homedir servers as well, and the load caused by either function doesn't have a significant impact on the other. Security is the primary force pushing us toward dedicated system servers.
• In any case, system staff need to be able to login to any machine and do administrative work, using tools they are comfortable with.

The conclusion is that a basic suite of software should be provided on every machine, regardless of architecture or purpose, which will support basic desktop-type work, and which will support compute server types of activity. The key point, though, is what should this basic software include?

Specialized Software

From the opposite direction, we have a large number of software packages which are specialized, large, expensive or used by only a small subset of the users. We have traditionally set these up on one machine and then let all the others NFS mount it. This works well. However, now that we're branching out to i386 Solaris/Linux architectures, there may be some requests for specialized packages there. Here are some principles:

• If the package is related to the mission of the requester's group, and they have a lot of machines of that architecture, make an effort to install the package. Example: pvm or lapack on Neowulf.
• Otherwise, tell the user to use it on Sparc architecture (or whatever it's already installed on). Example: Macaulay. Example: gimp, which would be on Linux, not Sparc. Except apparently we installed it on Sparc as well.

We shall have to deal with several administrative issues connected with packages that are not present on all machines:

• Each package should be installed on at least two fileservers, and perhaps more for high-use packages like TeX. We need an auto failover mechanism for when one server is down. A suitable automount map is recommended: for example, /warez/macaulay might be mapped to /u/bach/m1/Macaulay-94.09 with a fallback to the same directory on Sonia.
• It's important to audit the multiple copies for being identical. We need a more flexible tool than the present rdist scheme.
• Architecture is important. The package links and/or automount map needs to be architecture dependent.
• For most packages we install the whole thing for each architecture. But for many packages, like PBS and TeX, the major portion is data and configuration files, which are architecture independent. We need a standard strategy for using architecture-dependent executable programs and shared data.

Basic Desktop Software

Now as for the basic software to be provided: Most of this is actually already on the Sparc systems, but a few items are prospective. I trust I haven't left out anything :-)

• Authentication. The same loginID and password should identify the user on all Math/PIC systems, whatever the architecture and administrative group. Our user should be able to authenticate himself with high security. As far as the operating systems permit, a user authenticated on one machine should be able to execute on another without giving the password again.
• Connectivity. Our user should be able to initiate a TCP/IP connection to anywhere on the Internet, and we should avoid configuration issues that make ourselves unacceptable to outside partners. Our user when abroad should be able to initiate a connection to a reasonable subset of the Math/PIC machines.

  If at all possible, some compute servers should be outside the firewall so users abroad can go direct to them.

  Office staff require tn3270.

• Security. We should not require, and probably should not allow, authentication through clear-text passwords whether globally or on the local subnet. Our users should be able (and perhaps be required) to use encrypted connections both incoming and outgoing, which shall interoperate with encryption software generally used by our partners.
• Mail. Users should be able to send e-mail and to read their system mailboxes, which our server will maintain for them. We support these mail clients (on Unix): Berkeley mail, Pine, a web mail interface, and an X GUI mail reader. All but Berkeley mail can be, and perhaps should be, configured to work through an IMAP server.

  Presently the web mail interface and X GUI reader are vaporware. But such programs exist and could be installed. Mail readers on Windows are major security problems.

• Data Processing. We support a spreadsheet program and a database client. Users shall have some means to create their own databases (tables) in their own home directories.

  Presently all of this paragraph is vaporware, but I feel it's important for users to have this capability outside of Windows. Star Office is supposed to be able to provide this capability.

• Program Development and Execution. Specifically:
  • Editing files using vi, Micro-Emacs and Gnu Emacs.
  • Compiling in "C", C++, Fortran-77 or Fortran-90. On Sun systems, both Sun and Gnu compilers are provided for each language for which they are available.
  • Libraries of mathematical or computational functions such as BLAS and Lapack, and also statistical packages.
  • Long job execution using a POSIX-compliant queuing system such as PBS.
  • Parallel computation (on compute servers only, but every machine is potentially a compute server.)

  We do not have, and long ago should have installed, a Fortran-90 compiler. I don't know if Fortran-90 is available from Gnu; I believe not.

• Word Processing. Specifically:
  • TeX. Faculty and grad students use this exclusively to prepare theses and math papers. The LyX front end to TeX is said to be good as a pseudo-WYSIWYG tool, but I haven't used it.
  • Simple word processing. The Star Office imitation of Microsoft Word is what I have in mind here, for cases, like correspondence, where TeX is overkill. But word processors tend to suffer from feeping creaturism...
• Printing. From any machine we should be able to print any of these formats, and we should also be able to preview them:
  • Plain text (with ``less'' as the previewer)
  • PostScript (with GhostScript, driven by Ghostview, as the previewer)
  • PDF (by Adobe Acrobat; and we also need to be able to create them)
  • TeX DVI files.
• Web Browsing. A text browser should be available (lynx) as well as a reasonable GUI browser. As much as I hate Netscape, and as much as it's supect from a security point of view, our users will demand it. We should investigate Opera for Sparc, with the possibility of a site license. Other freeware browsers like Amaya and Mozilla could also be checked out.
• Calendar maintenance, including sync with Palm Pilot.

  Presently this is vaporware, though Star Office is said to have a calendar program that syncs with Palm.

• Symbolic Mathematics. It is not practical to provide symbolic math packages on all systems, but these are the most often used application packages, and pan-architecture support will eventually be demanded. The major packages we support are Matlab, Maple and Mathematica, as well as specialized ones such as Macaulay and Russell.
• Graphics and Visualization.