FreeBSD updating

F

franz

Hi everyone, i'm sorry asking a question surely asked multiple times but i've searched a lot and i didn't find any satisfiing aswer.

So here we are i understood that to update freebsd you could check the cvs to update your sources. I also understood that you can update ports separatly (portsnap ...). My question is when do i need to update and how?

If i want to update do i have to check the cvs, then rebuild my kernel (not a problem) and then rebuild my world (worst...)?

I've already made a custom kernel but i would like an advice on how - when update my system.

I also understood that tracking the -STABLE version was in my interrest since i use freebsd on a production server.

I also heard about -RELEASE version, is it more stable? is it the release source (for example 7.0 release sources) with security fixes?

I'm really sorry for annoying you with those *silly* questions but i've got a lot of questions and i can't find any satisfiing aswers so...

Thanks for your attention

François Van Ingelgom
 
As a rule of thumb, you have to rebuild world+kernel if you get new src with cvs. You can rebuild your kernel if you need to change your kernel configuration to add/remove support for hardware and so on.

You should understand that tracking the -STABLE version was NOT in your interrest since you use freebsd on a production server.

STABLE is a developement branch and stable doesn't mean reliable, but that the API are stable.

You should use the RELEASE branch, that is a branch from STABLE at a certain date + all the security fixes.

As often happens, the Handbook gives a lot of answers:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cutting-edge.html
 
hopefully i haven't done anything yet ! Thanks for your aswer!

You said i needed to track the -RELEASE but the handbook doesn't say a word about the -RELEASE cvs tracking.....

I guess it's just a cvs flavor on the config file but i have no idea about what to put in this since
RELENG_7 refers to -STABLE version....

Also another question (again sorry) does it matter if use freebsd-update?

I tried to use it but i read that sshd was updated to >5 (i read this in /usr/src/UPDATING of -STABLE branch) and my version after doing freebsd-update fetch - install is still 4.5p1 which was build in 2006 !

Nevertheless, thanks for your aswer it's really helping me!
 
If you're running a production server, I would not recommend -STABLE. The name is deceiving, and it isn't always "stable".

For a really stable release, use the -RELEASE versions. They are best suited for servers.

You can build the kernel/sources using the CVS method, or you can use freebsd-update (binary updates). Updates to ports are done seperately, and how often is up to you as the administrator.

EDIT: See what happens when you forget to hit the post button for a while.
 
RELENG_7 and RELENG_6 are -STABLE branches.

-RELEASE tags look like RELENG_x_x so you should probably use RELENG_7_0 or RELENG_7_1 (its still RC or something, should be released before the end of this year if no problems will be found).
 
thanks all of you for your replies i'll try this on VM about now.

It's much more clear now!

Just one other question: doing freebsd-update fetch/install or rebuilding world is the same thing? I've understanded that freebsd-update doesn't change anything to the kernel (am i wrong?)...

I'll try to makworld/installworld, even if the mergemater step seems a little bit scary ;-).

Again thanks for your help ^^
 
cajunman4life said:
For a really stable release, use the -RELEASE versions. They are best suited for servers.
Click to expand...

No such thing. It's 'best' to run -stable if you need the fix for the crash your production machine is experiencing, running -RELEASE.
 
freebsd-update does normally update the kernel and everything else, but since you have a custom kernel, freebsd-update will not be able to do the update. Using freebsd-update is more or less the same thing as running build world, but instead of compiling everything from source code, you do binary patching.

I would not recommend using a custom kernel if you don't really have to. It's better to load the required modules with the command called kldload. If you need to load any modules take a look at /etc/rc.conf and /boot/loader.conf to add them permanently.

The most stable release you will find is RELENG_7_0 (or RELENG_6_4), this one is actually more stable than STABLE. It's quite logical isn't it? :p Notice that RELENG_7_0 is not the same as RELENG_7, but that RELENG_7 is the same as STABLE.

Do like Andrius said, choose RELENG_x_x

There is nothing wrong with using an old version of OpenSSH/sshd as long as it does not contain any known security holes. I've always uses the version that comes with FreeBSD, and never had any trouble with it.

Some people like to always running the latest version og FreeBSD while other people like staying up to date with only the security patches. If you're running a production server you would probably only want the security related updates and only update the server when must (when the version of FreeBSD reaches "end of life" and is no longer supported with security patches).

Update your ports collection with portsnap or csup whenever you like. Keeping the collection up to date is a good idea, but you don't need to update the installed programs/ports unless security related problems are reported. A nice program called portaudit will monitor your installed software and report any security holes found in your installed ports/packages.

Everything is described in the FreeBSD Handbook

I wish you good luck! :)
 
franz said:
hopefully i haven't done anything yet ! Thanks for your aswer!

Also another question (again sorry) does it matter if use freebsd-update?

I tried to use it but i read that sshd was updated to >5 (i read this in /usr/src/UPDATING of -STABLE branch) and my version after doing freebsd-update fetch - install is still 4.5p1 which was build in 2006 !
Click to expand...

As far as I know, the freebsd-update fetch install process only tracks the security patches of -RELEASE branches, not the changes in -STABLE.

Btw: I wouldn't be alarmed by an OpenSSH distribution that is slightly behind version-wise, as long as you track the security advisories. For me a new version number becomes important when I really need that one new feature in that version... and then I rather install the newest version from ports and use that one, instead of moving my base system from -RELEASE to -STABLE to get the new version in there. Trying to stay off the bleeding edge a bit when it is server related, as logn as it does the job :p
 
Step By Step

I create a cheat sheet at the root dir for when I need to update a remote server as to not botch it when updating. One of these days I should invest in a serial console.

Here is my file. Change it to your needs.

# cd /usr/src
# make update <- or csup -g -L 2 supfile
#
# Read /usr/src/UPDATING
# diff /usr/share/examples/etc/make.conf /etc/make.conf
#
# shutdown now
#
# cd /usr/obj
# chflags -R noschg *
# rm -rf *
#
# make -j10 TARGET=amd64 TARGET_ARCH=amd64 buildworld
# make -j10 TARGET=amd64 TARGET_ARCH=amd64 buildkernel
# make TARGET=amd64 TARGET_ARCH=amd64 DESTDIR=/ installkernel
# reboot <- press 4 for "single user" option
#
# fsck -p
# mount -u /
# mount -a -t ufs
# swapon -a
# date
# adjkerntz -i
# date
#
# cd /usr/src/usr.sbin/mergemaster
# ./mergemaster.sh -p
# cp -Rpv /etc /etc.old <--back up /etc
# cd /usr/src
# make TARGET=amd64 TARGET_ARCH=amd64 DESTDIR=/ installworld
# cd /usr/src/usr.sbin/mergemaster
# ./mergemaster.sh
#
# shutdown -r now
#
# cd /usr/src/sys/amd64/conf
# diff GENERIC GENERIC.6.2-RELEASE-p7
# cd /usr/src
# make -j10 buildkernel TARGET=amd64 TARGET_ARCH=amd64 KERNCONF=SMP-**CUSTOM-KERNEL**
# make installkernel TARGET_ARCH=amd64 DESTDIR=/ KERNCONF=SMP-**CUSTOM-KERNEL**
#
# exit <- reboot
# <-back up GENERIC
# cd /boot
# cp -rvp kernel.old kernel.generic
# 23.4.13 Finished
#
# You should now have successfully upgraded your FreeBSD system. Congratulations
.
#
# If things went slightly wrong, it is easy to rebuild a particular piece of the
system. For example, if you accidentally deleted /etc/magic as part of the upgr
ade or merge of /etc, the file(1) command will stop working. In this case, the f
ix would be to run:
#
# cd /usr/src/usr.bin/file
# make all install
#
# 23.4.14.6. What do I do if something goes wrong?
#
# Make absolutely sure your environment has no extraneous cruft from earlier bui
lds. This is simple enough.
#
# chflags -R noschg /usr/obj/usr
# rm -rf /usr/obj/usr
# cd /usr/src
# make cleandir
# make cleandir
#
#Yes, make cleandir really should be run twice.
#
#Then restart the whole process, starting with make buildworld.
Click to expand...
 
You must log in or register to reply here.
Back
Top