From owner-freebsd-questions@FreeBSD.ORG Wed Apr 9 09:09:13 2003 Return-Path: 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 50D5437B401 for ; Wed, 9 Apr 2003 09:09:13 -0700 (PDT) Received: from mired.org (ip68-97-54-220.ok.ok.cox.net [68.97.54.220]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E26643FAF for ; Wed, 9 Apr 2003 09:09:12 -0700 (PDT) (envelope-from mwm-dated-1050336551.0fe36d@mired.org) Received: (qmail 44592 invoked from network); 9 Apr 2003 16:09:11 -0000 Received: from localhost.mired.org (HELO guru.mired.org) (127.0.0.1) by localhost.mired.org with SMTP; 9 Apr 2003 16:09:11 -0000 Received: by guru.mired.org (tmda-inject, from uid 100); Wed, 09 Apr 2003 11:09:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16020.17830.635670.333565@guru.mired.org> Date: Wed, 9 Apr 2003 11:09:10 -0500 To: Chris Miller In-Reply-To: References: X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ From: Mike Meyer X-Delivery-Agent: TMDA/0.73 (Jet Pilot) cc: freebsd-questions@freebsd.org Subject: Re: Questions about patches X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2003 16:09:13 -0000 In , Chris Miller typed: > I intend on running a "build" server to which all other servers will NFS > mount to perform OS upgrades, but I'd prefer not to have to do this for > every advisory. I've scoured the FreeBSD site and other resources for a > couple of days, but I've found no binary way of patching the OS as I'm > accustomed to doing with BSD/OS and RedHat. So my first question is; > Is/will there be a better method of patching the core OS in the future > that addresses only the affected components? This is what rdist is for - though rsync may be preferable these days. Make sure you build everything you need on the build server. Rdist to the test server - unless the build server is the test server - and run your regression tests against it. After everything passes, rdist to the production machines. Rdist can even be configured to run commands after the files are installed. This lets you restart daemons as needed, and add machine-specific tweaks to config files. I'm not sure i'd trust it to reboot with a new kernel, though. Do set 'INSTALL="install -C"' in /etc/make.conf on the build machine. > Now on to the ports and packages. The maintainers of the ports collection > appear to do a good job of quickly patching software in the ports > collection, but rarely is an announcement made to the list (at least to > any of the freebsd lists I subscribe to) which makes it difficult to > determine when something has been in fact patched. New packages are > released soon after in most cases, but often run several releases behind > what is current, ruling out pkg_add as an option. Ports security issues are regularly announced on the freebsd-announce list. They probably show up on the security-notifications list as well, but both lists are low volume. > Unfortunately patching a given port (with dependancies) seems to require > updating the entire ports tree to the latest versions, then compiling and > installing. In some instances we may want to apply a patch to an existing > version of an application rather than update it, but this is not possible > most of the time. From what I can surmise, the proceedure for patching > applications in a multi server environment is to update the ports tree and > to build/install/test these on a build server, and then package them up > and install them remotely via pkg_add. Questions; 1. Is this the best way > to apply patches to applications? 2. Are there any plans to provide a > better notification system when applications are patched similar to what > RedHat has done with Bugzilla? If you're going to be running an rdist to update the OS, you might as well update packages the same way. Rdist allows per-machine selection of components, named component lists, and similar things. The problem with rdist for this is that it makes handling things at the package level difficult. If all your machines are going to be clones from a small set of machines, rdist will work well. If each machine is going to have a different set of packages installed on it, then rdist will be problematical. In the latter case, I'd set PACKAGES in /etc/make.conf to point to a disk that can be exported read-only to the production machines, and use portupgrade - it's a port - to install and upgrade the packages on each machine. portupgrade will take care of cleaning up old ports and keep the dependencies straight. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.