Questions about patches

[Mike Meyer]

In <Pine.BSI.4.44L.0304081728340.9915-100000 at rs.netgate.net>, Chris Miller <ctodd at netgate.net> typed:
> I intend on running a "build" server to which all other servers will NFS
> mount to perform OS upgrades, but I'd prefer not to have to do this for
> every advisory. I've scoured the FreeBSD site and other resources for a
> couple of days, but I've found no binary way of patching the OS as I'm
> accustomed to doing with BSD/OS and RedHat. So my first question is;
> Is/will there be a better method of patching the core OS in the future
> that addresses only the affected components?

This is what rdist is for - though rsync may be preferable these days.

Make sure you build everything you need on the build server. Rdist to
the test server - unless the build server is the test server - and run
your regression tests against it. After everything passes, rdist to
the production machines.

Rdist can even be configured to run commands after the files are
installed. This lets you restart daemons as needed, and add
machine-specific tweaks to config files.  I'm not sure i'd trust it to
reboot with a new kernel, though.

Do set 'INSTALL="install -C"' in /etc/make.conf on the build machine.

> Now on to the ports and packages. The maintainers of the ports collection
> appear to do a good job of quickly patching software in the ports
> collection, but rarely is an announcement made to the list (at least to
> any of the freebsd lists I subscribe to) which makes it difficult to
> determine when something has been in fact patched. New packages are
> released soon after in most cases, but often run several releases behind
> what is current, ruling out pkg_add as an option.

Ports security issues are regularly announced on the freebsd-announce
list. They probably show up on the security-notifications list as
well, but both lists are low volume.

> Unfortunately patching a given port (with dependancies) seems to require
> updating the entire ports tree to the latest versions, then compiling and
> installing. In some instances we may want to apply a patch to an existing
> version of an application rather than update it, but this is not possible
> most of the time. From what I can surmise, the proceedure for patching
> applications in a multi server environment is to update the ports tree and
> to build/install/test these on a build server, and then package them up
> and install them remotely via pkg_add. Questions; 1. Is this the best way
> to apply patches to applications? 2. Are there any plans to provide a
> better notification system when applications are patched similar to what
> RedHat has done with Bugzilla?

If you're going to be running an rdist to update the OS, you might as
well update packages the same way. Rdist allows per-machine selection
of components, named component lists, and similar things.

The problem with rdist for this is that it makes handling things at
the package level difficult. If all your machines are going to be
clones from a small set of machines, rdist will work well. If each
machine is going to have a different set of packages installed on it,
then rdist will be problematical.

In the latter case, I'd set PACKAGES in /etc/make.conf to point to a
disk that can be exported read-only to the production machines, and
use portupgrade - it's a port - to install and upgrade the packages on
each machine. portupgrade will take care of cleaning up old ports and
keep the dependencies straight.

	<mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.