Help understanding basic FreeBSD concepts (ports, updates,
nightrecon at hotmail.com
Sat Nov 7 17:59:47 UTC 2009
> 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
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.
More information about the freebsd-questions