Re: Need to build some systems this week. Snapshots?
From: Brett Glass (brett_at_lariat.org)
Date: 08/31/03
- Previous message: M. Warner Losh: "Re: POSIX_C_SOURCE"
- In reply to: Colin Percival: "Re: Need to build some systems this week. Snapshots?"
- Next in thread: Colin Percival: "Re: Need to build some systems this week. Snapshots?"
- Reply: Colin Percival: "Re: Need to build some systems this week. Snapshots?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 31 Aug 2003 12:08:59 -0600 To: Colin Percival <colin.percival@wadham.ox.ac.uk>, stable@freebsd.org
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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
- Previous message: M. Warner Losh: "Re: POSIX_C_SOURCE"
- In reply to: Colin Percival: "Re: Need to build some systems this week. Snapshots?"
- Next in thread: Colin Percival: "Re: Need to build some systems this week. Snapshots?"
- Reply: Colin Percival: "Re: Need to build some systems this week. Snapshots?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
