From owner-freebsd-stable@FreeBSD.ORG Sun Aug 31 11:09:16 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 520A516A4BF for ; Sun, 31 Aug 2003 11:09:16 -0700 (PDT) Received: from lariat.org (lariat.org [63.229.157.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55F0B43F85 for ; Sun, 31 Aug 2003 11:09:15 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp1000.lariat.org@lariat.org [63.229.157.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id MAA01930; Sun, 31 Aug 2003 12:09:05 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <4.3.2.7.2.20030830184324.03a13a50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 31 Aug 2003 12:08:59 -0600 To: Colin Percival , stable@freebsd.org From: Brett Glass In-Reply-To: <5.0.2.1.1.20030828103403.02d683a8@popserver.sfu.ca> References: <200308280638.AAA19221@lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: Need to build some systems this week. Snapshots? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2003 18:09:16 -0000 As mentioned earlier, I needed to create a few FreeBSD systems, with all of the latest security updates, this week. (The effort extended into the weekend, for reasons that I'll explain below.) Here's a somewhat long-winded (but, hopefully, useful) account of how I did it and some of the pitfalls I encountered. The first thing I did was create a 4.8-RELEASE system using the standard install. I then brought in the "freebsd-update" package to update the system, which should (in theory) have nuked all of the known security holes in the base install. Alas, what I didn't realize at first (though I should have) was that the package was going to try to update "immutable" files. It couldn't do this, of course, because I'd installed with the "maximum" security settings, which set "securelevel" to 2. It failed to update those files, but gave no warning that it had failed; it was a good thing I noticed. So, I changed /etc/rc.conf, rebooted, and ran freebsd-update again. Alas, freebsd-update told me that the system was fully updated and did nothing. I had to use the "rollback" option to undo all previous changes, and then reapply them, to update the system. It then occurred to me: What would one do if the freebsd-update package itself had been linked with a buggy library? (The package collection, as I've already mentioned, isn't updated in response to security problems, and the package was dated July.) My goal was, after all, to get all buggy code off of the machine, and updated binary packages aren't available between releases. So, the only way I could see to avoid this potential problem was to remove the freebsd-update package and rebuild it as a port if I wanted to use it again. The pkg_delete command issued a warning, however, complaining that it couldn't delete the directory /usr/local/freebsd-update. So, I nuked the directory by hand. (Will this cause future problems? I guess I'll see.) Next, it was time to bring in ported software. Because updated binary packages weren't available, I had to install ALL the ported software I wanted to bring in as ports, not packages. A much slower and messier procedure. Before I did this, I decided that it would be a good idea to update all of my ports. This, of course, required cvsup. And this created a Catch-22. You see, because no updated binary package was available, and I had to update my ports to build the latest version of cvsup, I needed to start by using the old one. Which raised the question: Should I use the old (potentially buggy) binary package to update my ports? Or build the older port of cvsup, use it to update all of my ports (including itself), uninstall it, and then rebuild it if I wanted to use it again? I decided that since it's never a good idea to try uninstalling a port that's been updated, since the uninstall can fail due to the update. (This is another problem that ports have which packages don't, by the way.) So, I realized that the best course of action wasto install cvsup as a binary package (running a small risk of problems if it had been linked with a buggy library), use it to update the ports, and then delete the old binary package. Which I did. Next, I decided that since I'd be building everything from ports until the next release, one of the ports I'd better build first was the cvsup utility itself. What a mess! The build brought in tons of other stuff (including Modula-3, gmake, and many other dependencies). Worse still, it included megabytes of GPLed source code, of which we don't want ANY on our systems for legal reasons. (We really don't want GPLed binaries, either, but the lack of availability of BSD-licensed alternatives -- and the fact that FreeBSD is utterly dependent upon some of them -- forces us to live with a few of these for now.) I had to clean up, removing the source after the build. I then had to build everything else I wanted to bring in from a port. Also very messy. In the end, I managed to get an updated system going, but it wasn't graceful. And a novice user (or even one who was more advanced but hadn't played with FreeBSD) certainly wasn't going to be able to do it. And it's a good thing I had lots of disk space. (I really DIDN'T have the time to go through the whole procedure, and so had to give up a chunk of my holiday weekend.) Bottom line: Updates to the binary packages are an absolute necessity between releases. Without them, creating a secure system between releases is a nightmare... and a novice or newcomer just plain couldn't do it. --Brett