DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: R T

⟦2395f123d⟧ TextFile

    Length: 4905 (0x1329)
    Types: TextFile
    Names: »READ_ME.upgrading«

Derivation

└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
    └─⟦bfebc70e2⟧ »EurOpenD3/mail/sendmail-5.65b+IDA-1.4.3.tar.Z« 
        └─⟦f9e35cd84⟧ 
            └─⟦this⟧ »sendmail/uk.extras/READ_ME.upgrading« 

TextFile

Notes on Upgrading from Uk-Sendmail
-----------------------------------

When upgrading to the IDA Sendmail you might think that it ought to be
possible to merely create a sendmail binary and .cf file with the
appropriate options, and then to try them under test mode, followed
by a few test mails. The new sendmail could then be installed and used
instead of the Uk-Sendmail - the latter perhaps being kept as a
backup.

Unfortunately, this is slightly simplistic. It is recommended,
although not compulsory, that you use the BIND name server with IDA -
you can, like us, have your own local instance if you are not
connected to the Internet. However, if you are not already using BIND,
this is the upgrade point that will cause the problems.

The basic problem is that many people do not configure their
/etc/hosts files in the "official" manner.  For example, we used to
have entries like:

192.88.115.39  phi phi.ring
130.88.115.29  phi phi.back
192.88.115.34  epsilon

[Before anyone moans, the 192 numbers are unofficial].  When what we
really should have had was:

192.88.115.39  phi.ap.co.umist.ac.uk phi phi.ring
130.88.115.29  phi.ap.co.umist.ac.uk phi phi.back
192.88.115.34  epsilon.ap.co.umist.ac.uk epsilon

[where the first entry on each line is the full host name, including
the domain]. The difference between these is that the second set is
roughly compatible with BIND, as the official names are the same.  In
lists such as /etc/hosts.equiv you need to put the full name rather
than the local abbreviation - actually you can put both names on a
temporary basis. You will need to go around all such places and
duplicate the entries.

One you have done this, strictly speaking, you should convert all the
/etc/hosts entries as shown above. However, in practice, you can get
away with just those commonly used - all local nodes, those in
/etc/hosts.equiv, /etc/hosts.lpd etc, and any other place where full
names are required. Remember that although you will want a backup
/etc/hosts file, this will only contain the basic essentials - you
will probably erase most of it - and it is really this file you are
trying to create. Before doing the actual switch, it is probably a
good idea to give users a few days notice - esp. if they have private
equivalence files. During this time, you could add entries to the
/etc/hosts file like:

192.88.115.39 phi phi.ap.co.umist.ac.uk phi.ring

The second point to notice about moving from /etc/hosts to BIND is
that only very local nodes keep the same name - unless you use the
full ones. For example, our apollo cluster (ap.co.umist.ac.uk) does
many of transactions (mail, news etc) with a sun elsewhere in the
institute (sun.cns.umist.ac.uk).  With /etc/hosts the normal
abbreviation for this was "sun", whereas we now would most likely use
"sun.cns".  This has obvious implications for users - especially when
using telnet etc.  The best thing to do is to add the standard BIND
abbreviation to /etc/hosts file and encourage users to use it during
the transition time. [We use BINDv4.6 at the time of writing. I
understand in later versions it is possible for the resolver to have
its own database, and perhaps this could be used to ease the
migration].

Back to the original point. When you have made the changes suggested
above, you will notice the sendmail goes a bit haywire. It should
still work, but you will notice strange postmarks and, if you are
unlucky, From lines. You need to modify the .cf file to work in the
new /etc/hosts environment and then with BIND - on a temporary basis
at least. It all depends on how you generate these, but basically you
have to go through and change all explicit TCP machine names from
short to long form - making sure they are in /etc/hosts. Eg:

        phi.ether -> phi.ap.co.umist.ac.uk.ether

and you may have to comment out the domain entry DD, as the domain is
now taken from the machine name.  [Try it]. You are, of course,
advised to do this editing before you actually do the switch,
but not try it until aterwards.

Having done these steps, you should be able to get BIND running with
relatively little pain, and then generate sendmail from the IDA kit. If
possible, initially configure the resolver so that it uses a remote
name server before getting named to run on the local machine -
assuming there is one running elsewhere on your local area network.

In conclusion, the tricky bit of the upgrade is the BIND conversion.
If you can, it maybe best to say that service is unreliable for a few
days, and even to disable the mail daemon until you are happy.  If
not, definitely choose a quiet day for the BIND upgrate itself.
Definitely check first through your /etc/rc* and other config files
(rn, mh, elm, X, nfs etc) for any short names that will no longer work - and
replace the initial /etc/ifconfig entries by the numbers.

Good Luck.

John Forrest,
Dept of Computation,
UMIST

Jan 91.