Chapter 12: NERC and the WAN
 
Wide Area Networking

All NERC sites have a connection to JANET (Joint Academic NETwork) and with very few exceptions ( for security reasons, generally) all workstations are on the Internet and registered in the Domain Name Service (see below). This means they can all be reached from anywhere in the world.

Back to contents

Firewalls

This open access introduces its own problems and restrictions have already been introduced on the kind of traffic which can be carried on across the WAN. In the network routers on each site various ports and services are blocked, so that certain low-level insecure traffic cannot get into the site from outside. For example, SUN rpc is no longer allowed, which put paid to the NERC-wide use of SUN calendar manager! Further restriction by using firewall machines to sort traffic more finely is in now in progress.

Domain Name Service

This is the name service for the Internet. It is not a single central database (the Internet presently has approximately 1.5 million hosts and is growing at 30% per annum) but is distributed to name servers all over the world.

It uses a hierarchical naming scheme. Consider the Wallingford comms server wlcomms; its DNS name is wlcomms.nerc-wallingford.ac.uk. Here "wlcomms" is the hostname. "nerc-wallingford.ac.uk" is the domain. This is a different use of the word domain from NIS (or YP) domain which is a purely local construction for administrative purposes; there can be many NIS domains in one DNS domain. Also "nerc-wallingford" is a sub-domain of "ac.uk" and "ac" (academic community) is a sub-domain of the uk domain. For reasons of backwards compatibility, we also have defined sets of alternative short-form domain names such as "nwl.ac.uk". This is managed by a system of delegated authorities - e.g. the JANET authorities are responsible for the ac.uk domain but have delegated responsibility for subdomains within ac.uk. In particular, NCS have responsibility for the domains at all NERC sites and are responsible for maintaining appropriate name servers. Note that these name servers provide a service for the entire, world-wide Internet. If someone wants to find out about a NERC host, their query will be directed to one of our name servers.

All entities which you expect people outside your site to call into should be registered in the DNS. This normally includes all UNIX systems. It might not include PCs as these can only make calls and not be called. However be aware that certain Internet information servers do a name query on the calling host's IP number and if a PC, say, is not DNS-registered, they will not speak to it.

The primary name server for all NERC sites is kept at Swindon and there are also secondary name servers on the larger sites. Changes must be made (by Network Support Group), to the primary name server and should be automatically propagated to the secondary servers within hours. Queries will be directed to your local name server which, if it does not have the necessary data in its cache, will recursively refer up to a higher level name server. There is, of course, a protocol which the name servers use to communicate with each other.

The daemon which provides the name service is called /usr/etc/in.named and the data base is stored anywhere convenient, usually under /local<n>/named. The daemon is started by the standard vendor startup if a file called /etc/named.boot is present. If a system is to be a name server, this will have been created by Systems Group. I should also mention the nslookup command which can be used to look up DNS entries manually. See its man page.

Back to contents

Local Name Services on UNIX

There are two other sources of name information on UNIX systems-

  • /etc/hosts file
  • NIS hosts map
The /etc/hosts file was the original repository for name definitions. Nowadays it only needs to contain the workstation's own name and IP number and is only used at boot time. Thereafter, all name lookups are referred to NIS (Chapter 27) and the NIS hosts map completely replaces the /etc/hosts file. We normally include all local workstations , PCs, printers and so on in the NIS hosts map. They should be unqualified names - no domain names or indeed "."s in the name fields. Also it should contain various aliases. (A machine can have several names.) In particular, "mailhost" should be defined here. The relationship between the NIS hosts map and DNS name lookups is variable between vendors. SunOS, in particular, is rather unusual. However, your system should be configured to look first in NIS hosts and, if a name is not found there, to go to the DNS. This is usually set in /etc/resolv.conf (/usr/etc/resolv.conf on Silicon Graphics). For details of a particular vendor, see the man file.

Local Support Responsibilities for DNS

In keeping with the "delegated responsibility" strategy of the Internet, the computing support staff on each site have responsibility for allocating and maintaining IP numbers on their site(s). Host numbers (for Class C networks) range from 0 to 255 but 0 and 240-255 are reserved for network equipment such as routers and the like, so use 1 to 239 for hosts. Normally, the IP number for a UNIX system should be entered in three places:

Connection to JIPS

Nearly all NERC sites with UNIX workstations are now connected to JIPS which is the UK Academic Community part of the world-wide Internet. This is achieved by having a Router (installed and supported by NSG) which forms one end of a link to the nearest main JIPS hub. IP traffic goes to the hub and then on to the world. The command traceroute will show you where your calls go on the way to their destinations.

Back to contents

Electronic Mail

The following should be mandatory requirements for anyone buying email software -

  • TCP/IP - required of any system connected to the Internet
  • SMTP - the exclusive Internet mail protocol
  •  MIME - specification for sending compound documents (attachments) in email messages. These can include binary files as well as multi-media files.
  • IMAP4 - message retrieval protocol. This is how the client machine (desktop or nomadic) communicates with the email server. This is a follow-on protocol from POP-3
  • The new one is IMAP4. This is going to be very significant in the next few years.
    There are three models for accessing mail - offline. Messages are delivered to the server and downloaded to the client. This is the only model supported by POP.

    online. Messages remain on the server. This is the model used on a desktop system attached to the network.

    disconnected. Selected messages (maybe only parts of messages) are downloaded. One works on these and resynchronises the client message cache with the server at a later time.

    IMAP4 supports all three models. One can determine message structure (MIME attachments) without downloading. One can selectively fetch individual MIME parts. There is server-based searching and selection. This is all to minimise data transfer - particularly important for nomadic users with low-speed lines. One can work with multiple mail folders on multiple servers. There is support for shared mail folders (simultaneous update and discovery) so that it can be used in a help-desk environment where several people are replying to messages.

    Netscape Navigator mail, being designed for both PC and UNIX use, can run in online or offline modes. V4.03 and above now support IMAP mail serving; using this method the messages are left on the mail server and only the headers downloaded. This means that the same mail spool area can be accessed from UNIX or a PC, at the same time. This requires a modern IMAP server on the
    mail host, which Systems Group can provide for Solaris or IRIX.

    UNIX mail software

    Email software, these days, is invariably divided into two parts - a delivery agent, respsonsible for onward routing, and finally delivery, of messages and a user agent which provides a user-friendly interface for the user to interact with. The delivery agent on UNIX is the /usr/lib/sendmail program and its configuration file - /etc/sendmail.cf. (Directories vary slightly between vendors but not greatly.) Sendmail programs on different computers communicate using the TCP/IP mail protocol - Simple Mail Transfer Protocol (SMTP). It is possible (for test purposes) to send mail using the sendmail program but this is not normally done. Mailboxes (where incoming messages are stored) reside in /var/spool/mail (on SunOS, /var/mail or /usr/mail on Solaris 2 or Silicon Graphics) and outgoing, queued, messages in /var/spool/mqueue or its equivalent.

    User agents fall into two groups - command line programs and GUI tools running under X Windows. We recomemnd using the GUI tools both locally and when reading mail remotely, providing the network bandwidth is adequate (greater than 64 kbaud?). These are -

    • /usr/openwin/bin/mailtool on SunOS 4.1.x and Solaris 2.x
    • /usr/dt/bin/dtmail when using CDE
    • /usr/bin/X11/zmail -gui (or -motif) on Silicon Graphics
     
    There are two command line user agent programs on almost all modern UNIX systems. These are the mail programs written originally by Bell Labs and by Berkeley. Unfortunately, both were called mail so at least one had to change name when the UNIX flavours were merged. We strongly recommend using the Berkeley program rather than the Bell Labs program. This is called -
     
    • /usr/ucb/mail or /usr/ucb/Mail on SunOS 4.1.x
    • /usr/bin/mailx or /usr/ucb/Mail on Solaris 2.x
    • /usr/sbin/mailx or /usr/sbin/Mail on IRIX 5.x and 6.x

    •  
    So, on modern UNIX flavours use mailx or Mail and not mail !

    Back to contents

    NERC details

    All NERC sites with a UNIX network have a " mailhub". This machine has an alias of "mailhost" in the NIS hosts map. The mail directory on this machine (/var/spool/mail on a SunOS system , /var/mail on a Solaris or Silicon Graphics) is exported and NFS-mounted on all the other UNIX machines so that incoming mail messages can be read on any UNIX machine. The other machines (often referred to as "subsidiary" machines) have a very simple sendmail.cf which simply forwards mail to the mailhub's sendmail, (using SMTP over the LAN) which then is responsible for onward routing or delivering the message. Our intention here is to concentrate the complications (and problems) in the mailhub software. Note also that the mailhubs stamp their name in the From: field of the mail header so that mail from any machine on the site appears to originate from the mail hub and respondents should reply to this address. Effectively the whole UNIX network is a single mail destination, though mail can be sent and received on any machine. Experience at many sites, inside and outside NERC, is that this is a more convenient and more resilient model than having mailboxes on individual workstations. Also it is not desirable for users to have to remember which workstation they have to send mail to if they want to mail a colleague.

    For details of the current sendmail setup see our Mail Setup Instructions.

    The subsidiary /etc/sendmail.cf for Solaris can be found under /nerc/scripts/systems/incp.5.6/etc/sendmail.cf.sample. and similarly for other architectures. You have to edit one line in this to replace "nerc-wallingford.ac.uk" with your local DNS domain name and rename it to sendmail.cf.

    All our mailhubs use SMTP to contact remote as well as local sites.

    Desktop systems, such as PCs and MACs, can send and receive email using POP or IMAP4 - we can supply servers for both of these. Client software is available both from commercial and 'freely available' sources. Examples are Eudora, Netscape Navigator and Pegasus, all of which use POP to communicate with an SMTP server, such as one of our mailhubs and are available for MS Windows and Macs.

    The DNS names of UNIX mailhubs are almost always ( surprise, surprise) mail.<domain> as some of the supplied sendmail.cfs expected this for SMTP mail. This need not however be the name by which its friends know the machine - aliases are in most cases acceptable to sendmail.

    Before leaving sendmail, we should caution that it is a notoriously complicated, if very powerful, piece of software. Systems Group have had long and bloody battles with it before the SMTP mail hubs now in production could be got to work. This is definitely not an area to "tinker" with! We do not normally expect local Support staff to set up or understand the details of a mailhub.

    Back to contents


    This page last updated February 18th 1998 by rfcr@itss.nerc.ac.uk