Received: (qmail 5489 invoked from network); 11 Nov 2009 15:57:29 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by static-ip-85-25-126-90.inaddr.intergenia.de with SMTP; 11 Nov 2009 15:57:25 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 74EA4CBA270; Wed, 11 Nov 2009 16:57:24 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at localhost.localdomain Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4LivF7w2+4o; Wed, 11 Nov 2009 16:57:24 -0500 (EST) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 027AECBA1C1; Wed, 11 Nov 2009 16:56:44 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 11 Nov 2009 16:56:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 57D33CB9ECD for ; Wed, 11 Nov 2009 16:56:03 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFIhIObWbXqi for ; Wed, 11 Nov 2009 16:56:03 -0500 (EST) Received: from nospam5.slac.stanford.edu (nospam5.slac.stanford.edu [134.79.18.83]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 1C60FCB868A for ; Wed, 11 Nov 2009 16:56:02 -0500 (EST) Received: from exch-anon.win.slac.stanford.edu (exch-anon.slac.stanford.edu [172.23.70.42]) by nospam5.slac.stanford.edu (8.14.2/8.14.2) with ESMTP id nABLu1ro011484 for ; Wed, 11 Nov 2009 13:56:02 -0800 (envelope-from ian@slac.stanford.edu) Received: from exch-mail2.win.slac.stanford.edu ([172.23.70.52]) by exch-anon.win.slac.stanford.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 13:55:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Ecartis Subject: RE: uptime Date: Wed, 11 Nov 2009 13:51:02 -0800 Message-ID: <7F24308CD176594B8F14969D10C02C6C024476FF@exch-mail2.win.slac.stanford.edu> In-Reply-To: <4641e08817cba66541e759395ebb18d6.squirrel@society.servebeer.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uptime References: <7F24308CD176594B8F14969D10C02C6C024476FC@exch-mail2.win.slac.stanford.edu> <4641e08817cba66541e759395ebb18d6.squirrel@society.servebeer.com> From: "MacGregor, Ian A." To: "Oracle-L Freelists" X-OriginalArrivalTime: 11 Nov 2009 21:55:11.0755 (UTC) FILETIME=[A46EFDB0:01CA6319] X-archive-position: 22574 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: ian@slac.stanford.edu Precedence: normal Reply-to: ian@slac.stanford.edu List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l Security is not in the eyes of the beholder. A vulnerabilities exist or they do not. Certainly sites need to evaluate whether the vulnerability is applicable and whether they have taken other measures to prevent its exploitation, etc. I am not a system administrator nor a security expert, but RedHat has been rather busy lately with kernel releases to fix security issues. -----Original Message----- From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Rich Jesse Sent: Wednesday, November 11, 2009 8:27 AM To: Oracle-L Freelists Subject: RE: uptime > Impressive! What do you do about security problems with the OS. Does > not the installation of a new kernel require a reboot Security is in the eye of the keyholder -- not everyone needs every security update right away. Once upon a life, we had a dev box that had a 4-digit uptime. It was decided that there would be a controlled reboot if only to make sure that there were no undocumented "fixes" in startup, since there was some personnel changes in the department. Kind of a bummer... And don't get me started on VMS uptimes. Oh, those were the days... :) Rich -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l