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
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-
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:
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
The following should be mandatory requirements for anyone buying email software -
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.
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 -
Back to contents
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 email@example.com