[net.unix-wizards] Installing new sendmail version

chris@umcp-cs.UUCP (Chris Torek) (07/04/86)

In article <1915@brl-smoke.ARPA> bgrm@MITRE-BEDFORD.arpa (Barbara Graham)
writes:
>... I want to install [a] new version [of sendmail], but since I have
>a sendmail daemon running, I can't just move the new sendmail into place.

Use `install -s -m 6755 -o root -g kmem sendmail /usr/lib/sendmail'.
This installs sendmail in /usr/lib, strips it, and sets its mode
to 6755 (rwsr-sr-x, setuid root, setgid kmem).  The group kmem
stuff is perhaps 4.3 specific: for security, access to /dev/kmem
should be restricted.  The easiest way to do this is to make
/dev/kmem mode 640, owned by root, group `kmem', and make any
program that wishes to read /dev/kmem setgid to group kmem.
(/dev/mem and /dev/drum should be similarly protected; /dev/kUmem
is purely for Unibus hacking and should be even more restricted.)

Once sendmail is installed, be sure to replace the frozen configuration
file, if you use one.  Sendmail is supposed to be smart enough to
ignore a frozen configuration for a different version of itself,
but this has had a history of failing, and a quick `cp /dev/null
/usr/lib/sendmail.fc; /usr/lib/sendmail -bz' will not hurt.

>It seems that if I kill the daemon, I'll hang the socket, so a new
>sendmail daemon won't be able to create the (already existing) socket.

This should not happen: killing the old daemon should free up the
socket.  Sendmail does *not* set SO_REUSEADDR, however, and in some
(many?) kernels there is a bug that leaves old TCP sockets around
on occasion.  Sendmail should not have to set SO_REUSEADDR; but if
you are not into ripping up kernel TCP code, you might try having it
do so.

>Has anybody out there managed to install a new version of sendmail without
>rebooting?

We do it every night.  It works fine, modulo the TCP bug (we keep
squashing it and it keeps returning in a different form with the
next TCP hack).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

bzs%bu-cs.bu.edu@CSNET-RELAY.arpa (Barry Shein) (07/07/86)

From: Barbara Graham <bgrm@MITRE-BEDFORD.ARPA>

>This should be an easy question (for somebody).  I've installed a fix to
>sendmail that was posted to the net some time ago.  Now I want to install the
>new version, but since I have a sendmail daemon running, I can't just move the
>new sendmail into place.  It seems that if I kill the daemon, I'll hang the
>socket, so a new sendmail daemon won't be able to create the (already
>existing) socket.
>
>Has anybody out there managed to install a new version of sendmail without
>rebooting?

I do this all the time (unfortunately.) I am not sure what the problem
is or what version you might be running but it really should work.

The only thing I can think of off-hand is that a child sendmail is
running, try:

	ps agx|grep sendmail

and see if other sendmails are running, if so make sure to kill them
all or wait for quiescence (a sendmail killed in the middle of a
transfer SHOULD recover and resend later, either way, but this
might cause problems, like the message getting sent twice, nothing
catastrophic, I actually wouldn't guarantee it's ever caused a
problem, just a little healthy paranoia.) Another possibility is to
kill the parent (lowest PID probably, the one that 'ps' shows the -bd
arg for) and wait for any children to die off [finish, that is] tho
this will of course put your mail system out of service for incoming
connections until you restart.

This is with 4.2bsd, if you are running something else then this may
not apply. Another thing to do is 'netstat' to see what it is holding
the socket open. It is possible you have a child hung I suppose (maybe
one of those FIN_WAIT_2 problems? netstat should reveal this.)

To just move the sendmail into place RENAME the old sendmail as in
'mv /usr/lib/sendmail /usr/lib/sendmail.old', then move the new one.
Remember that the freeze file (sendmail.fc) has to be rebuilt by
the new sendmail image (-bz) or great indigestion will result. After this
you can just wait till the system goes through a reboot, which will
automatically start the new sendmail (also, all new invocations of
sendmail will refer to the new one.) I don't love this but if the
fix you made is not that critical it should be OK, use your common
sense (is this true folks? I don't see why not but I always just kill
them all off and restart.)

	-Barry Shein, Boston University

rbj@icst-cmr.arpa (07/15/86)

	The only thing I can think of off-hand is that a child sendmail is
	running, try:
	
		ps agx|grep sendmail

Almost. I have seen sendmail's children running with the name `send-mail',
so I always grep for just plain `send'.
	
	This is with 4.2bsd, 

Same here, on a VAX.

	Remember that the freeze file (sendmail.fc) has to be rebuilt by
	the new sendmail image (-bz) or great indigestion will result. 

Barry uses `sendmail -bzs' :-)

	you can just wait till the system goes through a reboot, which will
	automatically start the new sendmail 

Should take about 5 minutes at any university :-)
	
		-Barry Shein, Boston University

	(Root Boy) Jim Cottrell		<rbj@icst-cmr.arpa>
	I represent a sardine!!

P.S. No agreement on that please!