Need to build some systems this week. Snapshots?

[Brett Glass]

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