From owner-freebsd-questions@FreeBSD.ORG Sat Sep 16 20:57:44 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D28F16A403 for ; Sat, 16 Sep 2006 20:57:44 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.187.76.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BD3E43D5D for ; Sat, 16 Sep 2006 20:57:42 +0000 (GMT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from [IPv6:::1] (localhost [IPv6:::1]) by smtp.infracaninophile.co.uk (8.13.8/8.13.8) with ESMTP id k8GKvGnV065002; Sat, 16 Sep 2006 21:57:17 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk from=m.seaman@infracaninophile.co.uk; sender-id=softfail; spf=softfail X-SenderID: Sendmail Sender-ID Filter v0.2.14 smtp.infracaninophile.co.uk k8GKvGnV065002 Message-ID: <450C652C.7040700@infracaninophile.co.uk> Date: Sat, 16 Sep 2006 21:57:16 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: "pobox@verysmall.org" References: <450C46A8.3080908@verysmall.org> In-Reply-To: <450C46A8.3080908@verysmall.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig66FDF3409844AE8E228AE80E" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.infracaninophile.co.uk [IPv6:::1]); Sat, 16 Sep 2006 21:57:37 +0100 (BST) X-Virus-Scanned: ClamAV 0.88.4/1887/Sat Sep 16 19:37:01 2006 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_POLICY_TESTING, NO_RELAYS autolearn=ham version=3.1.5 X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on happy-idiot-talk.infracaninophile.co.uk Cc: freebsd-questions@freebsd.org Subject: Re: rebooting into single user mode on a remote server X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2006 20:57:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig66FDF3409844AE8E228AE80E Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable pobox@verysmall.org wrote: > Hello, >=20 > could somebody help me to understand the best way to enter into a singl= e > user mode on a remote server. >=20 > I need it for the moment, during rebuilding world, when I have to reboo= t > into single user mode before 'mergemaster -p'. >=20 > The only solution I found so far is to do 'shutdown -r now' and when th= e > server boots to login with ssh and do 'shutdown now' - which should dro= p > it to single user mode. >=20 > I can ask the support at the hosting location to reboot in single user > mode, but I do not know if I will have ssh then? >=20 > Alternatively I can ask them to do the last few steps. Yep. You've become the latest person to realise this perennial problem. In order to follow the upgrade instructions in the Handbook or /usr/src/UPDATING to the letter, you need console access to the machine being updated. That is no problem when the machine is on your desk, or probably not if it's just down the hall. But when it's in a hosting centre umpty dozen miles away and you can't actually get to it? There are essentially three possibilities. i) You've thought of this approach already: get someone local to the mach= ine to do the bits requiring the console access. That works if the people at= the other site are competent and trustworthy, and you can afford to pay for their time. ii) The next solution, and on the whole, probably the best solution available, is to arrange to get remote console access. That can be expensive if you go down the route of buying a dedicated console server. = Or it can be very cheap indeed if you have another FreeBSD box close by the machine you're trying to update and you can string null modem cables between their serial ports. Then you configure your FreeBSD box requirin= g update to use ttya as its console and use tip(1) to get into it from the other machine. (Actually, you could probably make that approach work fro= m any other unixoid OS or even from Windows so long as you can find the rig= ht serial console emulation software). If you're really lucky, you're running flashy new hardware with IPMI or similar "lights out" management capability and can get into the machine through that. It doesn't work in= anything like the same way as a serial console, but the end result is just as good. iii) Finally, and not to be dismissed without due consideration, is the really quite simple approach of /not/ taking the machine down to single user mode. Most of the time, you can quite happily run 'make installworl= d' or 'make installkernel' or 'mergemaster' while the system is in multiuser= mode. You should shutdown all active services except what you need to get in remotely and you should kick any other users off the machine as we= ll as generally taking steps to ensure the machine is as quiescent as possib= le before trying that. You should also have a 'back to square one' plan for= dealing with the eventuality that the machine does not come back after attempting to reboot into the new kernel -- you really absolutely will require someone quite FreeBSD savvy to get onto the console to unfuck things if so, and that illustrates the big drawback to this approach: if it goes wrong, you are truly left up a gum tree without a paddle. =20 Don't try approach (iii) for an upgrade over too many version numbers at once. Jumping from, say 6.1-RELEASE to 6.1-RELEASE-p6 should be feasible,= as should jumping from 6.0-RELEASE to 6.1-RELEASE. Going from say 5.5-RELEASE to 6.1-RELEASE is only for the brave or the most highly skilled, and anything more than that is only for the foolhardy. Neither = is it a good idea to do method (iii) if you're making any major changes to t= he hardware on the system. Nor does approach (iii) mix at all well with the= use of raised secure levels. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig66FDF3409844AE8E228AE80E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFDGUs8Mjk52CukIwRCN1LAKCKKcWqOABDFfxCqHsvYKDOkfYVFQCfbuv2 QKA3RoUv/242HRwYYBHgd54= =DQ9z -----END PGP SIGNATURE----- --------------enig66FDF3409844AE8E228AE80E--