From owner-freebsd-security@FreeBSD.ORG Tue Oct 11 07:52:46 2011 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E7561065674 for ; Tue, 11 Oct 2011 07:52:46 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D69F48FC0A for ; Tue, 11 Oct 2011 07:52:45 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E68121FFC33; Tue, 11 Oct 2011 07:52:44 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D1805846B3; Tue, 11 Oct 2011 09:52:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Brown References: <201110020411.p924BPqn037383@chilled.skew.org> Date: Tue, 11 Oct 2011 09:52:44 +0200 In-Reply-To: <201110020411.p924BPqn037383@chilled.skew.org> (Mike Brown's message of "Sat, 1 Oct 2011 22:11:25 -0600 (MDT)") Message-ID: <86d3e4j777.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: Reasonable expectations of sysadmins X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 07:52:46 -0000 Mike Brown writes: > Also, sometimes things go haywire after a reboot, especially after extend= ed=20 > uptime and updates to the kernel or core libraries, so I'm in the habit o= f=20 > only shutting down when necessary. So if I don't see "and then reboot" in= an=20 > update procedure - and most of the time, security updates don't require i= t -=20 > then I don't do it. Actually, this is an argument in favor of rebooting regularly, or at least after every major change, so you know the server will boot unassisted if something happens (power outage, cleaning staff tripped over the mains cable, etc.) I once spent an entire evening coaxing a mission-critical database server back up after a simple disk replacement because a predecessor had performed an in-place system upgrade without verifying that the new configuration would boot cleanly. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no