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."

Comments

Re:Only slightly OT

[TheLink]

You can build everything on another box, and then copy /usr/obj and /usr/ports/distfiles over and then shutdown to single user and do the installs from there.
See this for background.

There are many ways to do it depending on whether you want it built from source or just want the binaries.

Re:Only slightly OT

[Bishop]

I have always been a big fan of installing fresh on a new machine and copying the data over. This applies to most OSes. This method gives you a chance to test the new release before going into production. And once in production you can always switch back to the older machine if something goes wrong. Not enough people test an upgrade or have a downgrade procedure.

If you don't have a spare server don't be affraid to use an intermediate temporary server. It involves installing the os and copying data twice, but it is not as big a hassle as it sounds. If possible use fresh harddrives saving the old OS and data as a 'warm' backup.

Unfortunately if you are running a colocated server you probably can't do this. My only advice then is start Tuesday morning. Everyone knows not to start an upgrade Friday afternoon, but so many people still do. If you follow the instructions in the FreeBSD handbook your upgrade should be problem free.

Re:Only slightly OT

[JQuick]

It depends on how you measure quick, and on your risk tolerance.

If by quick you mean the least time start to finish, yes. If you mean as measured in system downtime, no. Each has a different risk profile which depends heavily on how much additional software you have installed.

I too have been running 5.x as a server environment since mid 5.0 days. I have performed 2 source based upgrades in the interim to bring me to 5.2. My preference for source based upgrades is based partly on my desire for quick response time re: security. It is also conditioned by my rather complex setup in which I have multiple jailed environments each running a large number of packages. A binary upgrade is less attractive since I would need to install dozens of different ports and possibly face conflicts or temporarily broken ports.

You have very few ports running, and from your statement they are pretty stock configurations. From this standpoint a binary upgrade should be relative painless. However, it might require more downtime.

If I were you and were running a GENERIC kernel, and was running a late 5.1, or 5.2_RELEASE, I would suggest a source base approach. if you are running an earlier 5.x version I would still do so myself but would counsel you to assess your comfort and knowledge with compiling the code and following /usr/src/UPDATING to the letter. If you are unsure, opt for a binary install.

If you do use a source base approach, I would prepare by installing the cvsup tools from the ports tree to mirror the source code and the ports tree. Then you can compile using buildworld and buildkernel, and even compile and install ports (using and alternate paths for the package db and destroot) to test versions of installed ports which might be newer.

Read UPDATING thoroughly and study any differences which you are unsure of. Then when you are ready, use install* targets and mergemaster to finish.

This is initially a longer, more time consuming approach, you must install sources, and configure cvsup to keep them up to date. Once that is done, however, they are always up to date. At each site which I have maintained FreeBSD, I use cvsup to mirror ports and sources on a single box. In fact, I mirror the cvs trees, enabling each host in the network to choose what particular version to check out. I then check out source trees via cvsup, and run a buildworld and a buildkernel via cron either weekly or monthly.

Thus, I always have a recent binary distribution ready to install when I feel like it. I upgrade rarely, but when I do, I typically have a 10-20 minute downtime. On boxes where I have configured multiple drives with sets of boot, usr, and var partitions, I configure and install to the alternate drive using the DESTROOT variable, and can take care of merging changes while running on the old version. Then downtime, is boot time + time to select the new boot partition.

Re:Only slightly OT

[cperciva]

My preference for source based upgrades is based partly on my desire for quick response time re: security.

Entirely off-topic, but if you're concerned about security, binary updates are a better option than source patches -- both because FreeBSD Update is more secure than the cvsup mirror system, and because I normally have patches available via FreeBSD Update within a few minutes of the code being committed to CVS and the security advisory going out. (I have the advantage of seeing the source patches in advance, thanks to being on the FreeBSD security team.)

Of course, this only applies to tracking the security branches, but if you're concerned about security that's what you should be doing anyway -- we don't issue security advisories for issues which only affect -current.

Re:Tom Rhodes

[Anonymous Coward]

Please ignore this troll. It's the same guy who has been pestering every *bsd (yes, even NetBSD) announcments trying to discredit FreeBSD developers. He usually goes on to say just how FreeBSD devs hate Dragonfly, how they unfairly kicked out Matt, and so on.

Sometimes he links to a message posted by DES on FreeBSD-advocacy in his signiture. If you take the time to see how that thread started, you'll see that the original "quesiont" was quite rude, and follow-up messages from the same person were written in a "I'm a famili member of the former Nigerian royal familiy and want to deposit large sums of money" style. Also if, you follow the thread further, you'll see this reply from a FreeBSD developer:

> BTW, I've spent a lot of time looking at the DragonFly approach, and I met
> with Matt for quite a while at USENIX to talk to him about the approach. I
> have a number of concerns about it -- I think the premise is very
> interesting, but that the results aren't yet there to prove the model. In
> particular, there's a huge volume of code in their system that has not
> been addressed, and a lot of complexity that will need to be handled
> before the SMP primitives they're using have proven that they offer the
> desired performance advantage. We have the opportunity of using a hybrid
> model, and have been exploring some of the ideas present in DFBSD (and,
> one should point out, many other SMP systems).
>
> A lot of other systems have opted to use elements similar to those
> primitives, but in a much more limited way due to the performance costs.
> For example, locking services into particular CPUs prevents the scheduler
> from balancing load between the CPUs in an service-transparent way. In
> the DFBSD model, load balancing must be implemented separately for each
> service, requiring extensive modifications to the services. I.e., the
> model may indeed offer benefits, but the cost of doing the work will be
> high, and the time to complete it long. We'll adopt elements of the
> design as they prove to make sense, as we do with all other open source
> operating systems (and they do with us!).

For your interest, Matt still posts occasionally to -current list, in fact, he even helps out a bit here and there. This troll's problem seems to be with DES, PHK, Bosko, but he is ready to extend his warm words towards anyone, even, it seems, to someone associated with the documentation project. Oh, btw: you'll see the same message by Doug-Furlong Smorgreff on Osnews as well. ~molnarcs

All documentation available online and offline

[phoenix_rizzen]

One of the nicer things about the FreeBSD Documentation Project is that everything is available both online and offline. All the man pages for every release of FreeBSD (going all the back to 1.0), along with OpenBSD, NetBSD, and several Linux distros, are available at http://www.freebsd.org/cgi/man.cgi

And, if you selected the docs distribution during the install, you'll find all the articles, books, and papers under /usr/share/doc, including the Handbook and the Porter's Handbook. If you didn't install the docs during the initial install, they can be fetched (and/or updated) using cvsup. There's a samples docs supfile in /usr/share/examples/cvsup. Just be sure to set DOCS_LANG in /etc/make.conf to the language you want, otherwise you'll get every language availables. :)

Having all the documentation available offline is a boon for those days when you break the network. :)