Best Version for Stability

B

bsd10

What is the best version of FreeBSD to minimize updates? The idea is to have my system run as long as possible without having to update it, and I'm considering two routes:

1) Run a -RELEASE and just do security patches. Ports only supports -STABLE and -CURRENT, but this may not be such a problem.

2) Track an older -STABLE, like 6, that changes less but is still supported by ports.

If you do track a -RELEASE, is there a way to automate patching the existing ports so you won't have to update to the most recent port when there is a security issue?
 
Run a -RELEASE. Forget about 6.x, support for it will stop in november of this year. So you won't get any security patches anymore.

Don't automate updating your ports. They sometimes need to be updated in a specific order. An automatic update won't be able to know this.
 
bsd10 said:
What is the best version of FreeBSD to minimize updates? The idea is to have my system run as long as possible without having to update it, and I'm considering two routes:

1) Run a -RELEASE and just do security patches. Ports only supports -STABLE and -CURRENT, but this may not be such a problem.

2) Track an older -STABLE, like 6, that changes less but is still supported by ports.

If you do track a -RELEASE, is there a way to automate patching the existing ports so you won't have to update to the most recent port when there is a security issue?
Click to expand...

If you are looking for maximum stability they you need to use a -RELEASE, as the -STABLE still is a development port(regardless of it's name). Also, ports have nothing to do with what version of FreeBSD that you are running(6.X, 7.X, 8.X, -STABLE or -CURRENT). So to minimize updates and rebuilding you base system, follow a release using binary updates.

And as SirDice said. Do _NOT_ automate updates of either the ports or the base system, you can however get notified when the base system needs patching using freebsd-update cron.

The ports tree don't use backporting of patches, that's almost unique to debian and in some respect to redhat.
 
I built a firewall with nanobsd using pf about a year ago, and it has pretty much run continuously since then, but the only port I used was the dhcp server. For a real server running more ports, it doesn't look like that kind of stability is possible, but my plan now is to track the newest -RELEASE with freebsd-update and use pkg_upgrade for ports.

When you say not to automate the updates, do you mean not to write my own script to do it, or do you mean there will be a problem with config file format changes or something like that? I was planning to run freebsd-update and pkg_upgrade as a cron jobs.
 
bsd10 said:
I built a firewall with nanobsd using pf about a year ago, and it has pretty much run continuously since then, but the only port I used was the dhcp server. For a real server running more ports, it doesn't look like that kind of stability is possible, but my plan now is to track the newest -RELEASE with freebsd-update and use pkg_upgrade for ports.

When you say not to automate the updates, do you mean not to write my own script to do it, or do you mean there will be a problem with config file format changes or something like that? I was planning to run freebsd-update and pkg_upgrade as a cron jobs.
Click to expand...

I don't know to much about nanobsd, but to my knowledge it's build from stock FreeBSD and if you haven't updated it in a year you probably have open security holes in it now. As there have been some quite serious patches the last 12 months, which I would say is a bad thing for a firewall.

And when I say not to automate updates, I do mean don't! freebsd-update cron in your crontab does download the patches and then sends you(ie root) an email that there are paches ready to be installed. Then you have to login and run freebsd-update install. It may however require a reboot or a restart of specific services, but that's something that you have to figure out when you look at what is being patched.

And for ports, it's a BIG no-no. It will sooner or later need you to do something manually or in a specific order, even if you use packages.

A system that is stable for a long time doesn't come from automation, but from actively updating and keeping track of what is going on.
 
gilinko said:
A system that is stable for a long time doesn't come from automation, but from actively updating and keeping track of what is going on.
Click to expand...

Sooo true!

But to play as the devil's advocate, we may also say that a system with no maintenance at all has a high probability of stability! ;)
 
hansivers said:
Sooo true!

But to play as the devil's advocate, we may also say that a system with no maintenance at all has a high probability of stability! ;)
Click to expand...

But no system exists, and if it did a good (and possibly paranoid) sysadmin would still not trust it.
 
Is there a way to build a binary update server that would work like freebsd-update but for both the base system and for ports? The servers being updated would all have the same ports installed.
 
bsd10 said:
Is there a way to build a binary update server that would work like freebsd-update but for both the base system and for ports? The servers being updated would all have the same ports installed.
Click to expand...
You can pass [red]-p[/red] to ports-mgmt/portupgrade, or (I think) [red]-b[/red] to ports-mgmt/portmaster (I don't have ports-mgmt/portmanager installed, so I don't know what it's options might be), and use the resulting packages to install on all your other machines*. Also "make package" in the build directory works.


*I'm assuming you can do this numerous ways, including setting up an internal webserver and pointing all the client machines to it as your master package repository. My machines vary too much in hardware to use the same packages, hence I can't give you a detailed set of instructions.
 
fronclynne said:
You can pass [red]-p[/red] to ports-mgmt/portupgrade, or (I think) [red]-b[/red] to ports-mgmt/portmaster (I don't have ports-mgmt/portmanager installed, so I don't know what it's options might be), and use the resulting packages to install on all your other machines*. Also "make package" in the build directory works.


*I'm assuming you can do this numerous ways, including setting up an internal webserver and pointing all the client machines to it as your master package repository. My machines vary too much in hardware to use the same packages, hence I can't give you a detailed set of instructions.
Click to expand...

I can have portmaster hit an internal build server for packages, but it sounds like there will be cases where there needs to be manual intervention. I'd like to do the update of both the base system and ports on the build server, and then have the individual servers do a single binary update for everything. Is that possible, or is there another route that would be better?
 
For your base system using freebsd-update you can't use your own server(as far as I know), but as this is a binary update only(and a binary update between versions) it will still be "a single binary update" for the base system.

As for ports, a dedicated build server can be used to build the necessary packages that you want and then other servers can update from that source. It will speed up installation on your servers, but then again you will need a extra server that constantly rebuild what you need and on this server.

But you can't do a "single binary update for everything". The base system has nothing to do with the ports and the ports have nothing to do with the base system. They are two completely different entities. Unlike in Linux where everything is mashed up from the kernel to the applications.
 
For the ports try http://tinderbox.marcuscom.com/ in portstree http://www.freshports.org/ports-mgmt/tinderbox

For example I have on my build machine the following layout

sources:
/usr/RELENG_7_2
/usr/RELENG_7_3
/usr/RELENG_8_0

ports:
/usr/ports => current
/usr/ports_freeze => own maintained ports tree (only security fixes)

In the tinderbox I have all combination off sources and ports so I can build current and security updates without destroying my build machine with portmaster ...

Even I can port my own updates easily with the following line in make.conf and this layout.

/etc/make.conf
VALID_CATEGORIES+= myports

ports/myports
ports/myports/port1
ports/myports/port2
...

The build machine self has only ports installed which are build inside the tinderbox.
This way I build all the ports I need for ~30 machines.
 
ohauer said:
For the ports try http://tinderbox.marcuscom.com/ in portstree http://www.freshports.org/ports-mgmt/tinderbox

For example I have on my build machine the following layout

sources:
/usr/RELENG_7_2
/usr/RELENG_7_3
/usr/RELENG_8_0

ports:
/usr/ports => current
/usr/ports_freeze => own maintained ports tree (only security fixes)

In the tinderbox I have all combination off sources and ports so I can build current and security updates without destroying my build machine with portmaster ...

Even I can port my own updates easily with the following line in make.conf and this layout.

/etc/make.conf
VALID_CATEGORIES+= myports

ports/myports
ports/myports/port1
ports/myports/port2
...

The build machine self has only ports installed which are build inside the tinderbox.
This way I build all the ports I need for ~30 machines.
Click to expand...

This is very interesting-how do you get the ports tree with only security fixes? Do you patch the ports yourself? It doesn't seem like the FreeBSD team updates old ports.
 
bsd10 said:
This is very interesting-how do you get the ports tree with only security fixes?
Click to expand...
You don't. Keep in mind there is only one (1) ports tree.
 
SirDice said:
You don't. Keep in mind there is only one (1) ports tree.
Click to expand...

ohauer said he has a /usr/ports_freeze directory that he maintains with only security fixes, and I was wondering if he does that manually, which seems like it would be very time intensive, or if he has a better way to do it.

I don't know if you are familiar with nanobsd, but it builds a single image from the kernel, world, and packages that you include. The image has one slice for the configuration, and two separate slices with the rest of the /usr/obj tree, only one of which is mounted at a time. When you need to update, you rebuild the image and run a script to copy the new image over the unused slice, and then reboot using the slice you just updated. I was hoping to do something similar, but with a binary update that would just update the diff instead of requiring the entire slice to be copied. It seems like nanobsd already does something very close, so I was hoping there was support for this somewhere.

Please let me know if I should start a different thread, since the current thread title is a little off topic.
 
bsd10 said:
ohauer said he has a /usr/ports_freeze directory that he maintains with only security fixes, and I was wondering if he does that manually, which seems like it would be very time intensive, or if he has a better way to do it.
Click to expand...
The only way I know of would be to do it by hand. There are no official 'releases' of the ports tree except HEAD. If you track a release with the source tree you will get security patches but there's nothing like that for the ports tree.
 
bsd10 said:
ohauer said he has a /usr/ports_freeze directory that he maintains with only security fixes, and I was wondering if he does that manually, which seems like it would be very time intensive, or if he has a better way to do it.
Click to expand...

Sure, I maintain this tree manually and sometimes it is really a lot of work.
The thing is you don't have to implement every updated port on the tree only for a version bump (for example a new/changed option flag you don't use) or if it is only a feature update.
Since a view years the first thing I do is a diff between the old and new sources and then decide if I need the update.
I have a script which fetch and extracts the current ports into the current tree, collects all installed ports from all machines plus all ports build on the tinderbox and fetch the new sources for this ports.
This way I have always the latest sources on my build machine and can diff now quickly.

You have to go choose a way, jump regularly to new versions, track a own stable tree and do the work yourself or don't update and miss security fixes.
This is one of the difference between FreeBSD an for example Centos where you have a version without feature updates for the next 4-5 years and everyone use ports build by someone else (unknown, trusted?) and then maybe run with the next Release change into trouble (~ every 6 month).

I decide to go with FreeBSD and I'm happy about this decision.
 
Thanks ohauer-Tinderbox looks good, and I think it makes sense to just do security patches manually to avoid jumping to new versions all the time. That also seems to be the approach of the RELEASE branches.

It seems that after a certain amount of time, the patched ports tree and the current ports tree would diverge so much that patching with diffs would be more work than updating your ports to current. Have you updated your patched ports tree to current yet, or are you still working with the original?
 
bsd10 said:
It seems that after a certain amount of time, the patched ports tree and the current ports tree would diverge so much that patching with diffs would be more work than updating your ports to current. Have you updated your patched ports tree to current yet, or are you still working with the original?
Click to expand...

Thanks to tinderbox you can create a new build with a different ports tree, so if a current tree is stable for your ports you can copy the whole tree into a new frozen tree (I name my trees similar to ports_$date).

Since I always build my ports for current and the frozen I can quickly test the new tree and jump between current the new and the old frozen tree/packages if needed.

As bonus I can submit working patches in the hope they will be adopted and next time there is less work for the ports I have in use. Then it is easier to start over with a new frozen tree ;)
 
Packages for -STABLE are build continuously and for -RELEASE the ports tree is frozen and then built(which is about to happen for the 8.1-RELEASE build). Once a -RELEASE package build has been done it will not be updated. Why the packages are built continuously for the -STABLE branch is because it is a development branch and changes has to be tested so they don't break anything, thus it has to testbuild the entire ports tree.


As for what to recommend is difficult, as it depends on your interest and knowledge. But the things already said so far in this thread covers almost all aspects. Just remember tracking -STABLE core system is not the same as tracking the ports build done for -STABLE, and vice versa.
 
You must log in or register to reply here.
Back
Top