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
pgp00000.pgp
Description: PGP signature
