| cunix | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| mail, news | CourseWorks | ColumbiaNet | files | timeshares | authentication & authorization | administrative | ||||||||||||||||||
|
|
|
|
|
|
|
||||||||||||||||||
Mail Servers
$ ourhosts -mail
maillist1 mhoro blueberry cranberry elderberry hello manheru merdeka
moni morjens raspberry strawberry tere xinchao zravo apakabar kachifo
menyapa
$ ourhosts -popimap
$ ourhosts -cubmail
$ ourhosts -maildeliver
When a user reads
mail, the mail user agent (e.g. Netscape, Outlook) contacts a
daemon on the popimap machines to retrieve their messages. While pine
on the timeshare hosts accesses mail directly (over
NFS), POP and IMAP requests can come from any machine on the
network. Hosts should be configured to connect to
imap.columbia.edu or pop.columbia.edu.
Cubmail, a convenient, secure, web email client, is increasingly popular with students. The cubmail front-end hosts connect to a database backend to track session information and address entries. Currently, the cubmail hosts use a separate pool of IMAP servers, which may eventually be joined with the rest of the POP/IMAP servers.
The sendmail hosts are further in the background -- they receive incoming mail addressed to user@columbia.edu, and deliver it to the user's mail spool or relay it to other hosts at Columbia. They also expand mailing lists.
In 1999 we made plans (available internally) to consolidate, upgrade, and simplify our mail system. Except for the usual problems keeping up with demand, those plans have mostly been accomplished.
News Servers
$ ourhosts -news
newsmaster
AcIS currently has one host handling
netnews -- news.cc.columbia.edu or news. It is the
host news readers connect to, and should also be used for posting
news. The same host acts as our newsmaster; it is the host
contacted by non-Columbia sites that are passing news to us. The
newsmaster sorts through duplicate messages from multiple feeds and
organizes them all into a single collection for Columbia hosts.
Given that netnews is the single largest consumer of campus network
bandwidth, the system is surprisingly stable. Other Universities have
given up maintaining their own news systems in favor of commercial
providers.
Recently, the main secure web
server was merged into the same pool as the regular web servers. Merging the
two simplified maintenance and increased redundancy for the secure web
(which had previously been dependent on just one (older) host). The
combined cluster provides most of our authenticated services, like bulletin
boards and internal
documentation. Some of the authenticated services, like the
backend of our account
maintenance system run on other secure servers.
Another important web service is our various search engines, which
require large indexing jobs to privide up-to-date answers. Currently,
they all run on one host.
We also have a Certificates on Demand (cod) server, an authentication
broker (wdamb)
and a commercial server for the restricted portions of Earthscape.
Here
are some more details, slightly dated, of the web hosts, their
functions, and the plans for upgrading them.
The information contained in ColumbiaNet is gradually being moved to
the Web, but some services still remain available via ColumbiaNet.
For the most part, these are text-based alternatives to services
available on the web, some of which are better or more stable than the
web versions.
Many of the services on ColumbiaNet include database lookups and user
authentication. These take place on the ColumbiaNet back-end.
The ColumbiaNet front-end and back-end servers are still running
SunOS. Fortunately, they are fairly stable and we rarely have to do
anything to keep them running.
Still, we have resigned ourselves to the fact that ColumbiaNet will
not be vanishing soon, and have finally ported core services to a
Solaris host, informally known as "ColumbiaNet Sunset". This will be
deployed shortly.
Similarly, incoming mail (also known as new mail, or mail spool) is
stored on another file server, and Web and EDS data (/www, /wwws, and
/eds) are stored on two more file servers.
Our fileservice is provided by Network
Appliances filers, which the company used to call toasters.
Unlike the general-purpose UNIX boxes we use for our other servers, a
toaster does just one thing, but it does it really well. The NetApp
operating system has been tuned for excellent file service.
The toasters are almost named for greetings, like our other machines,
but we started with a greeting ("cheers!") which is also a toast, and
continued naming subsequent filers after toasts as well.
The timeshares have been expanded many times since their initial
deployment in 1993. At first, the cluster contained four SPARCstation
2s. In 1994, we had five SPARCstation 10s. In January 1998, we
expanded from twelve SPARCstation 20s to six Sun Ultra 2s (each at
over 3 times the capacity). Currently, we only have five Ultra 2s.
Plans call for upgrading the operating system but not the hardware.
We are counting on decreased demand as more users do their work
offline (e.g. pine users moving to IMAP clients).
Currently, we have two types of CPU servers, the new Solaris 2.7 one,
not fully deployed, and the old Solaris 2.5.1 ones. Among other
things, the newer one runs java, SAS and SPSS. The older ones run
lisp, mathematica, and matlab (as controlled by
/opt/local/etc/spty.conf).
Newer Solaris 2.7 hosts, as well as authenticateed web services,
depend on LDAP to get the user information, but LDAP ultimately gets
the information from the ID system. The ID system is most visible at
our Computing Support Center, where people go for help creating or
renewing their accounts, but is constantly active keeping passwords up
to date, and creating new accounts on demand.
We also have some databases in DB2, with a backup server on the way.
DB2 is primarily used for databases of web information.
Additionally, our Remedy tracking system uses Sybase, and our
CourseWorks system uses Oracle. And postgresql for the CubMail
database.
Please check with hostmaster@columbia.edu if
you need to know what address to use for resolving hostnames.
Last modified Oct 2 2001CourseWorks
$ ourhosts -cmsent
gooseberry huckleberry loganberry
CourseWorks@Columbia, a Course Management System using Prometheus, is not yet in
production. Internal planning documentation is available here. It will
have two front-end webservers and a backend
database.
Web Hosts
$ ourhosts -cuweb
alhan howsit bomdia gutentag kalimera moningtru zivijo osiyou yasu thalia
$ ourhosts -www
$ ourhosts -http
$ ourhosts -https
The web hosts provide a number of specialized functions.ColumbiaNet hosts
$ ourhosts -cnet
$ ourhosts -cnetsunset
The original campus-wide information system was written with (or like)
gopher and was text-based. ColumbiaNet terminals on serial lines were
placed in various locations around campus for public access.
ColumbiaNet is also available for users to telnet into from both on-
and off- campus. The system involves a number of inter-dependent
programs running on the ColumbiaNet hosts. File Servers
$ ourhosts -toasters
cheers ellohay chinchin prost salud
$ ourhosts -toastersmp
$ ourhosts -toastmaster
Files for cunix users are stored on file servers and accessed
via the Network File System (NFS). Thus, wherever a user ends up,
they see the same home directory. This includes the timeshares, the
Web servers, and even the Mudd Sun lab.Tape Backup Hosts
$ ourhosts -backup
$ ourhosts -veritas
kiaora sawubona
As with all computers, our disks need to be backed up. This includes
the fileservers as well as the other hosts, whose disks contain
important configuration information and system logs. These backups
are done to DLT (Digital Linear) tapes. The tapes are stored in a
large tape jukebox from ADIC, with a robot arm to load the right tape
for unattended backups. The backup hosts take care of loading the
right tapes, and signal each host in turn to run its backups. As many
as 7 or 8 backups can run simultaneously. These generally run
overnight.
Timeshares
$ ourhosts -t
aloha ciao konichiwa sawasdee merhaba
$ ourhosts -timeshare
$ ourhosts -login
To log in to the AcIS machines, users should connect to the hostname
cunix.cc.columbia.edu
(within Columbia, this can usually be called simply cunix). When users connect to cunix,
network software automatically chooses one of the timesharing
machines, and they are connected there. An individual timeshare
machine gives them the login prompt. The timeshares are all
identically configured. CPU Servers
$ ourhosts -cpu
fozimane monire labdien
$ ourhosts -cpusolfhs
$ ourhosts -login
Some users of cunix wish to run CPU- and memory-intensive programs
like SAS and lisp. In order to shield other users of
cunix from the spikes these processes would cause, these programs are
shunted to alternate CPU server hosts. The programs are
configured to run on the CPU servers transparently, as if they were
still on the timeshares.Kerberos
$ ourhosts -kerb
tegur terve
To help combat the problems of plaintext passwords crossing a
possibly-compromised network, MIT wrote a package called Kerberos.
This gives out tickets based on authentication of encrypted strings.
As with other services, AcIS has one main kerberos server and one
backup server. As of late December 1999 we are running Kerberos 5
servers, with some Kerberos 4 compatibility for our many Kerberos 4
clients. While kerberized telnet is being replaced with ssh, sshd
still uses Kerberos to verify the password. Tacacs
$ ourhosts -tacacsrvr
cumulus stratus
$ ourhosts -radius
$ ourhosts -tacacs
To allow users to run SLIP and PPP from our terminal servers, while
still being able to restrict who can do this and track who was on
when, we need to authenticate users on the terminal servers by having
them login. This is done by the terminal servers with the radius and
TACPLUS (and TACACS) protocols, by contacting the corresponding daemon
running on our radius and tacacs hosts (with backup servers on various
other hosts). These servers in turn contact the directory name
servers (for authorization) as well as the kerberos servers (for
authentication).
LDAP
$ ourhosts -ldappool
ave hola yahteh
$ ourhosts -ldap
$ ourhosts -ldapmaster
For user authorization and simply looking up phone numbers, Columbia
provides directory services (i.e. names of people), done with the LDAP
package. We currently have three dedicated LDAP servers, one of which
is the master LDAP server. For better performance, some hosts run
their own LDAP servers for themselves and nearby hosts. The LDAP
authorization service is used by systems like secure web and tacacs
(for dialin IP) to verify a person's eligibility for different
services on campus. For LDAP service, connect to host
ldap.columbia.edu.
ID System
$ ourhosts -sidmaster
dobryden
$ ourhosts -sid
Cunix currently serves over 50,000 users, and maintains information on
over 90,000 people (not counting alumni). In order to allow access
for these users in a timely fashion, we utilize a database of all
Columbia staff, students, and affiliates. This database comes from
various University sources, is merged together, and is then used to
verify potential users. There are then more database records created
with information about each user. These records are then combined
with records referencing over 90 hosts, and user entries are made
available to the right hosts. Database Backends
$ ourhosts -ingres
bienvenue
$ ourhosts -db2
$ ourhosts -acscsun
$ ourhosts -cmsent
Our ID system, as well as our hosts database, class scheduling
software, and a number of other systems, require a large relational
database system. We use Ingres, and for optimal performance the
database runs on a dedicated database backend host. Client programs
run on many other hosts updating their various databases.Name Service
$ ourhosts -named1
diaduit namonamah nihao labdien cunixd
$ ourhosts -named
Hosts on the Internet have a hostname and a number (IP address). With
so many hosts at Columbia and elsewhere, no one host can keep track of
them all, so each domain is responsible for helping other domains
resolve local hostnames. The package used for this is known as DNS.
For Columbia, several hosts are designated to keep track of the local
hostname to number mapping, with four hosts currently being the main
ones along with two or three backup hosts. The name service system
also allows for dynamic mapping of hostnames -- so that subsequent
translations of the name cunix cycle through the various IP
addresses (via a round-robin list), though some of these pools are
being moved to Server Load Balancing (SLB) on the routers.