FreeBSD Documentation: An Interview with Tom Rhodes

An Anonymous Coward writes "FreeBSD has been known for excellent documentation and here is a rare sneak peak behind the scenes of the FreeBSD document project with FreeBSD's very own Tom Rhodes."

Only slightly OT

[numbski]

I have a question for those interested in FreeBSD documentation:

Let's say you have a production environment running FreeBSD 5.x (I know, boo, hiss, only -RELEASE, not -STABLE...blah blah blah), and with the upcoming release of 5.3-STABLE (my understanding anyway), how would you recommend a minimal downtime upgrade?

I have 2 nameservers running the stock Bind8, 2 MX's running stock sendmail. One 'users' box running Sendmail with spamassassin and spamassassin milter, along with apache2 and squirrelmail for webmail.

None of these boxes have the full sources installed, and in the past I've taken the boxes down and done a binary upgrade from CD. Is this the fastest method?

um its pretty good, but not great...

[josepha48]

I have a FreeBSD 4.10 system running off a cdrom.. I had to do some hunting and research on how to get a bootable floppy image for the cdrom and also some info on how to deal with things like ssh, /dev, tmp and memory disks. Basically read the scripts and hack.

Now I am trying to get a bootable 5.2.1 cdrom. I finally found section 16 of the manual, which describes cdboot. It doesnt really say much else in the way of what do I need to put in the loader.rc file, if anything, or do I need one. It doesn't say if I need to have just cdboot or also boot0 and the loader. Doing just what they suggested left me with a none bootable cdrom.

I'd like to know more information on what I need to do to the boot directory to get a working bootable cdrom. Well I should give it some credit, it does boot, but then it stops and says could not find / . Do I need to specify load /kernel in the loader.rc?

I will say one thing, using cd-rw's and bochs has saved me a few cd-r's.

Re:Only slightly OT

[feargal]

I usually upgrade from source. You don't need the current sources to upgrade, just the new ones, so grab them with cvsup.

I do the initial builds offsite and usually well in advance (perhaps leave them to work on a Friday evening).

1. make buildworld
2. make buildkernel

Once onsite, I:
3. make installkernel - takes a few minutes, doesn't count towards downtime.
4. reboot
5. mergemaster -p - takes about a minute
6. make installworld - takes maybe 5 minutes at most
7. mergemaster - this takes the longest - I usually manage it in about ten minutes, as I've become pretty familiar with it, and make the right decision pretty instantly.
8. reboot

I've timed myself, and I end up with 15-20 minutes downtime, depending mostly on the speed of the machine.

Going more off-topic, but I had an idea on how to make this process faster, and to make mergemaster much less scary.

Most of the files that are affected by the mergemaster process are rarely actually changed. On a stock server, you'll probably only ever change files in /etc/mail, /etc/namedb, /etc/ssh, and perhaps one or two other file. All the rest of the files are usually unchanged by the sysadmin. The mergemaster process however asks you if you want to upgrade all the files that have changed in CVS. This takes a lot of time and involves repeating the same keystrokes, and is probably the source of most accidents: shift-G, i, shift-G, i, shift-G, i, "oops, shouldn't have overwritten that one!"

It should be trivial to, pre-upgrade, traverse /etc, extract the version numbers, download their originals from CVS, diff the two, and build an "auto-list" of files which have never been altered.

When mergemaster is run, it can then automagically upgrade all of the files in the auto-list; if nobody saw fit to change /etc/mtree/BSD.usr.dist, chances are the new one will do just fine. Meanwhile, the sysadmin only has to think about that matter to him.

Also, prior to doing the upgrade, he would be able to get a list of files which he *has* changed, so he can figure out what exactly he was thinking when he decided to hack /etc/rc.d/initdiskless to bits.

Any reason this wouldn't/shouldn't work? Obviously mergemaster should give Big Bloody Warnings before using the list. I reckon I'd save at least 25% of my downtime doing this.