Date: Fri, 4 May 2012 04:14:05 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org, m.seaman@infracaninophile.co.uk Subject: Re: freebsd-update not updating reported patchlevel Message-ID: <201205040914.q449E5iZ037677@mail.r-bonomi.com> In-Reply-To: <4FA38AB8.7010806@infracaninophile.co.uk>
index | next in thread | previous in thread | raw e-mail
> From owner-freebsd-questions@freebsd.org Fri May 4 02:54:56 2012
> Date: Fri, 04 May 2012 08:52:24 +0100
> From: Matthew Seaman <m.seaman@infracaninophile.co.uk>
> To: freebsd-questions@freebsd.org
> Subject: Re: freebsd-update not updating reported patchlevel
>
> On 03/05/2012 23:43, Robert Bonomi wrote:
> > Amazingly, this very question was covered on this list within the last few
> > hours. <grin>
>
> It's not that much of a coincidence. ...
No kidding. <wry grin>
The 'amazingly' was a wry commentary on that very fact.
>
> I wonder if it would be possible or indeed worthwhile to have a very
> small kld or sysctl that shows the current patch level and that can be
> updated without replacing the kernel entire. Obviously, this introduces
> the possibility of faking the patchlevel, so perhaps this should be
> constructed so it can only be modified on reboot.
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Both kernel revision level and 'world' patchlevel are reset -only-
when a new minor (or major) release of the O/S is installed. Aside
from that, they increment semi-independantly -- 'world' patchlevel
is always greater-equal to kernel revision level.
Ideally, this is a _log_ of all the actual changes, something along the
lines of:
BEGIN updates
updated {foo}, Vers x.y.z, old file renamed to {foo}.x.y.x-replaced
patchfile {foo1} for {pathname}, patch application succeeded
patchfile {foo2} for {pathname}, patch application FAILED
obselete file {foo3} renamed to {foo3}.x.y.z-obselete
END updates Now at patchlevel {quux}
For 'audit' purposes', every line is prefixed with
timestamp,
login username/effective UID(as a username)
the tty device from which the action was performed.
When a new release of the O/S is installed, the patchlog file is renamed
or deleted, and a single line of the form:
END install Now at patchlevel 0
is written. Thus there is always an END line with the patchlevel ID.
The numeric patchlevel is written as a fixed-width *right-justiied* field.
Thus, the last 'END' starts at a 'known' position before the end of the
file, allowing an application to do a direct fseek(3)/lseek(2) to it (or
the patchlevel) without having to read the entire file. ('install' and
'updates' are chosen with malice aforethought, they're the same length ;)
>From the command-line, 'tail -1 {patchlog}' gets everything.
With this kind of setup, and assuming that all distributed patchfiles have
'unique' names, the 'patchlog' provides a roadmap for reconstructing the
state of the kernel and 'world' as of any particular point in time.
AT LEAST as important, it provides a record that would let one 'back out'
an update, to revert to a prior system state, if needed. In fact, it
would be 'easy' to have automation perform that task.
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201205040914.q449E5iZ037677>