Date: Sat, 07 Nov 2009 13:00:16 -0500 From: Michael Powell <nightrecon@hotmail.com> To: freebsd-questions@freebsd.org Subject: Re: Help understanding basic FreeBSD concepts (ports, updates, jails) Message-ID: <hd4chn$9cq$1@ger.gmane.org> References: <9d972bed0911060931k4ee2a5b7n9d62db23beeb6367@mail.gmail.com> <9d972bed0911070839q3f9ded02q40de4637278bcec9@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hd4chn$9cq$1>