On Thu, Sep 18, 2003 at 01:30:13AM -0700, Voracity.net Administrator wrote:
Anyway, I used cvsup to grab the RELENG_4_8 sources
with the fixes. I'm
now faced with the choice of doing make world (which
I have never
done) or just recompiling ssh and sendmail and
installing them only.
Unless you have remote console access to your machine, you would be
well advised to just reinstall those parts of the system as detailed
in the security advisories.
If you need remote console access, the cheapest way to do it is via a
null-modem serial cable link from a neighbouring machine at your
hosting center. See
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html
and
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-advanced.html
- All of the instructions for make world that I've
read involve
shutting down into single-user mode, am I corrent that
this is not
possible over ssh? Is there a way to accomplish the
install step
remotely? I have already recompiled and successfully
installed a
customized kernel remotely, and that was gut-wrenching
enough waiting
the minute or so while it rebooted with fingers
crossed. :-)
It depends how risk averse you are. Shutting down all of the servers
(except sshd, of course) and kicking off any other users is *almost*
as good as taking the system down to single user mode, and 99 times
out of 100 you can successfully run 'make installworld' from that
state, and then do all of the other stuff required to update the
system before rebooting.
However, avoiding program crashes and so forth is not actually the
principal problem that rebooting to single user mode helps you avoid.
Rebooting into single user mode lets you test that your newly compiled
kernel actually works before you go ahead an install the matching
world. Should your kernel not boot up, it is possible to back out to
the previous kernel from the boot loader screen. Backing out an
installworld like that is basically impossible.
- Assuming that is not possible, I will just recompile
the individual
parts, following the instructions in the bulletin.
However, I still
don't want to fubar sshd and then not be able to
connect to fix it.
When I run kill `cat /var/run/sshd.pid` will that
kill only the
listening daemon (leaving any already-established
sessions open) or will
it kill all connections and everything related to
sshd? I was hoping
that I could kill just the listening sshd, restart the
new one, and test
it by connecting, all without severing the old known
working
connections... at least I'd have an out if something
went wrong. And
likewise, if I wanted to restart sshd (for example,
after changing the
config file) can I safely kill the sshd.pid process
without killing the
current sessions, just in case restarting sshd doesn't
work?
Yes, absolutely. A 'kill -HUP `cat /var/run/sshd.pid`' will restart
the main instance of sshd(8), whilst leaving any sshd's forked to
manage login sessions alone. You should test that you can login
remotely to the updated sshd from a second window before you log out
of the first session.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
pgp0.pgp
Description: PGP signature
