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."
in the handbook how?
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.
If cvsup && buildworld && installworld is the easy solution, I wonder what he considers this to be:
freebsd-update fetch
freebsd-update install
Yeah, ok, FreeBSD Update is only about tracking the release branch. But really, this story just covers the standard technique which people have been using for... well, longer than I've been using FreeBSD.
Tarsnap: Online backups for the truly paranoid
Given the amount of software I have on my Linux box, I think a BSD/Gentoo-like build process just wouldn't be practical for me.
The underlying problem is really that C/C++ code has so much information compiled into each object file: even common, minor changes may require huge amounts of recompilation. While we practice abstraction and encapsulation at the source level, at the binary level, it is still mostly lacking.
The choice shouldn't been between huge amounts of recompilation from source (Gentoo, BSD) or laborious hand-packging and version tracking (Debian, RedHat, etc.), this needs to be addressed by changing the underlying software infrastructure. Let's hope we'll move more towards JITs, dynamic binding, dynamic typing, and component-based software. Then we can finally get away from these massive recompilations and version hell.
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.
I was scanning this... Got 1/2 way through and was wondering if he stole it, cause I swore i read it somewhere.
Then I realized: Issue #3?November 9, 2003
How the hell is this news? I love FreeBSD, its all I use. the only thing dead about it is bsd.slashdot.org
Yes APT is great. It's easy to use and requires less effort than the FreeBSD upgrade process but it's too bad Debian stable is so hopelessly out of date. FreeBSD isn't. It's a stable operating system with upto date third party software delivered using the ports system. I've said this before and I'll say it again since this Debian comparison has been brought up.... I hear this argument from Debian advocates a lot: "Do you want a stable server or do you want bleeding edge?" Well with FreeBSD I get stable servers and still have packages that aren't a year or two [or sometimes more] old...... it is possible. And before anyone recommends that I run Debian testing instead please remember that the Debian Security team claim that they don't support anything besides the stable releases. I could use a Debian stable system and then mix match packages from unstable or testing and risk instability in the end or higher maintenance due to no security alerts from one source but then why not use FreeBSD instead in the first place?
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.
Yes APT is great. It's easy to use and requires less effort than the FreeBSD upgrade process but it's too bad Debian stable is so hopelessly out of date.
Three words: "End of Life"
If we are looking at updates, the last extended support release of FreeBSD was 4.8, which was released in April, 2003.
Its end-of-life is March, 2005.
Debian Potato was released August, 2000 and end-of-lifed in June, 2003.
Debian Woody was released in July 2002, and, assuming that tradition holds, will be supported til at least May 2005. [ Debian seems to keep security updates going for one year after the date of the next release. ]
Its rather nice not to change software in 3 years or so. ["Change" as in "new software version" -- debian does security patches, but they are backported to the version that ships with the release to minimize breakage. ]
Ne'ermind that binary upgrades are damn nice.
[ Don't feel bad -- OpenBSD has a lifespan of 1 year on its stuff, and no binary updates, which *really* annoys me -- otherwise its a fine OS which I like to use. ]
Yes, linux has always had software to update software to the latest official release. What he is saying is that with BSD you can update the system to the latest software too, without waiting for the next version.
In other words, on RedHat or Debian, I can update to the latest apache pretty easily with apt or rpm. Same on BSD. But on BSD I can also easily download and install the very latest updates to the kernel and base system straight from the official CVS without having to wait for binary updates to come. In Linux distros, binary updates to core packages in the base system are often not released (unless they are security related of course) until the next version of the distro. On BSD the latest is always available for download.
When I first saw the headline about "painlessly updating", I thought this might be a great article about some new innovative way to update. Its not really anything new or interesting though, the whole article is basically saying: "cd /usr/src && make world && make kernel && mergemaster will update you system"
Not wanting to sound rude, but no shit sherlock! Yes, this is a painless way to update your system. It is also the way to update your system, as is very well spelled out in the excellent FreeBSD Handbook so I'm not sure why it warrants an article....
Maybe its just me but I think an article about portupgrade or something would have been more useful.
>Its rather nice not to change software in 3 years or so.
Sure, if you like using 4 or 5 year old hardware. If you want to use newer hardware, you have to run a "testing" kernel. Case in point: a 160GB hard disk attached to an ATA/133 card... gotta have 2.4.20 to handle it. I would have been limited to using 127MB of it, and accessing it thru the mobo's blazingly fast UltraDMA/33 ports, if I was determined to stay with "stable".
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
You can say a lot of good stuff about *BSD, but it currently does not match the quality and quantity of great minds work that is being put into the linux kernel.
If at first you don't succeed, skydiving is not for you
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
Quick summary:
From that, I read a tiny FreeBSD advantage in the socket call (in terms of absolute execution time) and two FreeBSD scalability issues: one rather serious, and one O(n) versus O(1).
Again, one can't be less than astonished by the Linux kernel development over the last two years. Not that one would notice the difference between Linux and FreeBSD on everyday use, or less than stressfull server deployments. They're both in the same league but, as of now, Linux is more polished. Scaling O(1) for almost every algorithm in there is amazing.
If at first you don't succeed, skydiving is not for you
If that's true, then how come every time there's a new linux kernel version, hordes of slashdotters come out querying when it's going to included in their distro. With Linux you either have to wait until someone updates a kernel package (or emerge script), or go grab it and built it yourself manually. It's not going to happen instantaneously.
That's the essence of what the article blurb is saying. No need to get all defensive about it. You chose to use a system that someone else integrated together for you from many different disparate projects. You can't expect that integrator to provide instant updates to every part of the base system you're interested in. For most distros a new kernel version takes a few weeks to make it into an upgrade package.
Don't blame me, I didn't vote for either of them!
Upgrading the base system is great and it works most of the time. I'd only wish cvsup/cvs were able to fetch a consistant source tree, but as long as CVS doesn't provide some kind of ACID semantics, it would be very hard to do so. There's always the risk of updating /usr/src in the midst of a commit.
The ports are actually more painful to upgrade than FreeBSD proper. portupgrade does a great job at this, but it's not a panacea. First of all, portsdb -uU takes a hell of a time to generate a new INDEX.db, then you still have to fix some stale dependencies etc... This is the same problem as with Linux distros, and there is no easy solution to this.
cpghost at Cordula's Web.
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
Your post is disturbing on so many levels man. What ever happened with "best solution for the problem". Do you think your attitude of forcing people to write stuff for a certain system is gonna attract more people to linux? That's just insane. People use BSD because they like it and think it's good. People use linux because the like it and think it's good. I can't understand people who say that a certain system is better. If you think linux is better, use it!! But don't force your opinions on other people. It's one thing to argue that something is good but assuming your point of view is the right and the only way is just arrogant.