Help understanding basic FreeBSD concepts (ports, updates, jails)

[Michael Powell]

Roger wrote:

> Hello all,
> 
> I have another concept that I'm confused about, the source distribution.
> Some ports, like "lsof" require the existence of /usr/src.
> What I don't understand is which version to use to keep synchronized
> with the production release.
> When the installed was performed the release was 7.2 but after doing
> "freebsd-update" the release is now
> 7.2-p4. 

A RELEASE such as 7.2 has a maintenance period during which the security 
team will apply security patches to the OS. Only the patches are applied, 
the rest of the bulk of /usr/src is untouched. This is what the -p4 means. 
The security support period for different releases can be located on the web 
site. Some releases are designated "extended support", while others have 
shorter time frames.


> According to the documentation, I can track CURRENT, STABLE plus
> other. Which one is the recommended one for a production server. I have
> not build that many
> packages that need the sources present so now would be a good time to
> find out which one
> I should use.
> 

I don't use the binary freebsd-update myself, but still use the old csup the 
source in /usr/src and the make buildworld/buildkernel/install dance. So I 
tend to think in terms of CVS tags. The tag RELENG_7_2_0_RELEASE would fetch 
the original release bits that never change. The tag RELENG_7_2 would fetch 
the /usr/src that has the security patches applied.

The -p4 you observed means that freebsd-update used binaries built with 
security patches applied. If there exists any question as to whether your 
/usr/src is in sync you can simply csup your source with the RELENG_7_2 tag 
in the supfile.

There is also another way to patch, and that is to apply patches manually. 
Let's say, for example, the built in bind had a file or two that got 
patched. You could rebuild just this one thing and after installing the bits 
simply restart the daemon. Sometimes this is preferred when one needs to 
prevent a security hole but doesn't want to reboot a server. A downside is 
when you do this it does not register the "-p4" like you noticed.

For a production server I feel it is best to use production release. IMHO 
there is one possible cause to consider STABLE for a production server and 
that is if there is new code "Merged From Current" that addresses and 
corrects a very specific problem. Let's say you have a particular NIC in 
your server that is exhibiting an exact same (and reproducible) condition as 
described in a bug report. If code which fixes this exact problem becomes 
available it will be written in CURRENT, and after some testing if deemed to 
be of sufficient quality it will be merged back to STABLE. Upgrading to 
STABLE will then pull in this fix. IMHO I wouldn't normally consider this 
unless there is an exact match between problem and fix.

-Mike