Slashdot Mirror
Painlessly Update FreeBSD
boarder8925 writes "Over at BSDnews, Steve Wingate has written an article on how to easily update FreeBSD. Wingate begins his article by saying, "One of the greatest advantages that *BSD has over other Unix variants is the cvsup/make world process. Unlike most Linux distributions it isn't necessary to wait months for a new version to be released for you to upgrade your system. The cvsup/make world process allows you to update your system at any time. I'm going to show you how to make the process as painless as possible." The article discusses the following: installing CVSup, choosing a cvsup server, configuring make.conf, and, finally, performing the upgrade. The piece is also available as a .pdf file."
Gentoo has this aswell. There are no distribution versions, a simple 'emerge -uDav world' will update the system.
In case the site's Slashdotted ...
.pdf file
Google cache of article
Google cache of
Keep your eyes to the sky.
Anybody know if cvsup will ever be rewritten in C instead of Modula-2 or whatever the heck that is?
I'm hoping someday Gentoo will use cvsup because it's a bit more efficient (it doesn't have to re-compute all deltas every time like rsync).
I use both FreeBSD and gentoo heavily but portage generally feels a lot slower than BSD ports, syncing as well as the various cache or dependency operations or whatever it does when it sits there spinning at me.
I have never used a linux distribution which lacks a tool for updating software without upgrading to the next official release. Redhat had one, mandrake had one, suse had one..and most importantly, debian has one.
:)
okay, minor lie; linux from scratch had no such tool. on the other hand, linux from scratch had no installer and consisted entirely of a manual explaining how to compile the software.
Wow, BSD is dead?
I just migrated all my Linux server over to FreeBSD because FreeBSD is so much easier to maintain. It seems faster also.
The above is not worth reading.
The article is nice and well written. I would however change one step. /usr/src && make update && make world && make kernel && mergemaster' /usr/src && mergemaster -p && make update && make world && make kernel && mergemaster'
alias rebuild 'cd
to
alias rebuild 'cd
The prebuildworld mode for mergemaster is a life saver. Read man mergemaster.
One thing this paper leaves out is reading UPDATING. You really really should check out the file /usr/src/UPDATING after you sync your tree but before you start building. Of course, the handbook will tell you that you should also be subscribed to the proper mailing list (freebsd-current or freebsd-stable) but at the very least, reading UPDATING is a Good Thing.
The article is actually riskier IMO.
/etc/defaults/make.conf /etc/make.conf /etc/make.conf accordingly (compile options, whether ports openssl/openssh overwrites the base openssl/openssh etc)
/etc and stuff to what your local custom config is like)
/usr/src /usr/
/usr
/etc/make.conf was correct etc.
/usr/ports/blahblah/softwarename
Firstly: he doesn't track the RELENG_4_9 branch, he tracks the STABLE branch (RELENG_4 - e.g. the latest of whatever is considered stable for Release 4) - which is more likely to break working stuff than the RELENG_4_9 branch which is FreeBSD 4.9 that has just the updates for security problems. Yes many ppl don't have problems with RELENG_4, but if your job and reputation is on the line - only use it if RELENG_4_9 doesn't work (hardware, required features etc).
Secondly: He skips the mergemaster -p step.
The way I recommend is what's been in the FreeBSD handbook for years:
Step 1: Synchronize your source Use cvsup. It's better. And track the RELENG branch.
e.g. cvsup mycustomcvsupfile
Where mycustomcvsup is like the stable-supfile but with the following tag instead of RELENG_4:
*default release=cvs tag=RELENG_4_9
Step 2: Building and Installing world
optional step before:
cp
edit
Then
make buildworld
make buildkernel KERNCONF=YOURKERNELNAME
make installkernel KERNCONF=YOURKERNELNAME
reboot and go to single user mode
mergemaster -p
(preliminary mergemaster stuff if things are too different between your config and what the new FreeBSD stuff is)
make installworld
mergemaster
(to merge what's new in
reboot
***multiple machines.
Here's where you might do things differently.
Read this for some background: tracking for multiple machines
Now once you built everything, you don't have to rebuild it on a different machine if you are using a compatible architecture. For example you specify a 686 CPU in your make.conf and kernel config, you can only reuse it on stuff which supports 686 class CPUs.
I didn't bother with the NFS part (not applicable for some situations) - I just did the synchronize of src and ports and did the build on a fast machine with a fast connection.
The default was 4-stable which tracks the current stable source of Release 4. For production machines I recommend tracking RELENG releases and not STABLE.
Then build the kernel and sources.
cd
make buildkernel KERNCONF=kernelformachineA
make buildkernel KERNCONF=kernelformachineB
make buildkernel KERNCONF=kernelformachineC
make buildworld
cd
Then tarball the results: tar -zcvf src.tar.gz src && tar -zcvf obj.tar.gz obj && tar -zcvf ports.tar.gz ports
Then I copied the tarballs (via CDR) to the slow machine which did not have a cvsup connection (not allowed by firewall policy etc)
Then installed the results on the machine.
cd
rm -rf src obj ports
tar -zxvf src.tar.gz && tar -zxvf ports.tar.gz && tar -zxvf obj.tar.gz
Then I ensured that the
Then: make installkernel KERNCONF=therelevantkernel && make installworld.
Note: to save the trouble of building desired ports software on the slow machine you have to make packages on the fast machine.
e.g.
cd
make package
---
You should also check out freebsd-update.
freebsd-update is more like binary updating of stuff affected by security issues.
Redhat is simpler on one hand and more complex on the other- sure you can ftp all the rpms and run a freshen. But it's harder to be sure everything is really consistent
Err. Read your own link? His conclusion frome those benchmarks were that OpenBSD is slow. He says specifically:
Linux 2.6 scales O(1) in all benchmarks. Words fail me on how impressive this is. If you are using Linux 2.4 right now, switch to Linux 2.6 now!
FreeBSD 5.1 has very impressive performance and scalability. I foolishly assumed all BSDs to play in the same league performance-wise, because they all share a lot of code and can incorporate each other's code freely. I was wrong. FreeBSD has by far the best performance of the BSDs and it comes close to Linux 2.6. If you run another BSD on x86, you should switch to FreeBSD!
His only major complaint about FreeBSD was its mmap performance: the system seems to do more work ahead of time than is actually necessary. It's not clear to me that his benchmark is actually relevant, since he measured the cost of mmapping 10000 pages, but only reading one (in which FreeBSD thrashed all the other systems), whereas one generally reads most of the pages mmapped anyway.
In many of the benchmarks, FreeBSD beat Linux 2.6 by a sizeable margin, in particular the "many files" and connections benchmarks.
I hereby place the above post in the public domain.
An update system that offers to overwrite /etc/passwd (and presumably every other security file) hardly seems like a safe or easy upgrade process.
:-( & :-)
I can't say my DoC (SuSE) has it better -- they don't ever seem able to upgrade my system in a sane or coherent manner. Last time around, it upgraded my squid 3.0 to squid2, tried, unsuccessfully to put my named in a basement mail (when it hadn't even been bad), but it was thrown in the basement w/o the root servers file and when the root servers all expired some large amount of time (~3-4 months) later, various TLD's started disappearing. It was bizzare watching large sections of internet just "go away" a few days before it completely consumed itself. Then I found the problem -- it hadn't copied in the root servers file from the previous upgrade (and/or didn't install a new copy). I tried grabbing some updates with their Yast Online solution, but it kept downloading copies of 8.2 binaries when I have 9.0 loaded. I never had 8.2 loaded -- I went straight from 8.1 to 9.0. Later, I found, buried in some paragraph of fine print somewhere that their updates only support updating from the immediately preceding version -- this was after it had removed all unknown packages fro the package database. At this point I had all the 8.1 packages installed, but no longer noted as "installed" in the database over which it automatically upgraded and installed about 10-15 packages out of the 100-150 it should have installed (I guess ~10-15 packages kept some same valid name). I'm always rather afraid to do an upgrade under SuSE as I know it will usually involve lots of pain.
On the flip side -- a fresh install of 9.0 for a never-used-linux user went real smooth -- they were able to navigate their way around after only one or two hiccups -- like buttons weren't where they used to be under Win, but I just told them they'd have to experiment a bit and find out how things were arranged differently. Once they experiemented some, they started finding what they needed surprisingly well.
-l
Yeah, Debian stable is pretty out of date... For Desktop systems.
I use Debian stable on all of my servers; it still gets the security updaes, and stable is... Well, stable. Great for production servers.
Debian testing works great on desktops, though. I'm running testing now, with kernel 2.6.5, and everything is wonderful, and best of all...modern. And pretty stable, too.
If you don't need the fancy gui stuff, testing is the way to go. Most of the server oriented stuff is very up to date in stable.
Funny that my 1TB mail servers at Portugalmail run on ReiserFS and have been quite stable for the last three years, while serving 30k users a day. Go guess...
If at first you don't succeed, skydiving is not for you