Date: Fri, 4 May 2012 16:45:19 +0200 From: Polytropon <freebsd@edvax.de> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: freebsd-questions@freebsd.org Subject: Re: freebsd-update not updating reported patchlevel Message-ID: <20120504164519.d04ba910.freebsd@edvax.de> In-Reply-To: <201205040914.q449E5iZ037677@mail.r-bonomi.com> References: <4FA38AB8.7010806@infracaninophile.co.uk> <201205040914.q449E5iZ037677@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
> 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'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
Allow me to extent the approach: For -STABLE versions (e. g. if
updated per CVS), those files could contain the "build number"
and the date of the currently installed -STABLE "snapshot".
A separation of a "kernel version file" and a "world version
file" is useful in cases the kernel won't be touched, so no
need to update its version file (as well as the kernel itself)
by a binary update.
The files should be easily parsable. They could even contain
an assignment in sh syntax, as well as comments (for BSDL and
$FreeBSD$ information). Their templates could be stored in
the /usr/src subtree for the etc/ structure, so programs like
"make" and "mergemaster" could access them from there.
Maybe a binary command could be added to the base system to
query this information (maybe "getent" could do that?).
Here are some suggestions:
/etc/kernversion
VERSION="8.2"
BRANCH="STABLE"
BUILD="12345"
DATE="2011-08-01 12:34:56"
or
/etc/kernversion
VERSION="8.4"
BRANCH="RELEASE"
PATCH="2"
DATE="2012-02-02 02:02:02"
/etc/sysversion
VERSION="8.4"
BRANCH="RELEASE"
PATCH="4"
DATE="2012-04-04 04:04:04"
This shows: Kernel has last been updated to patchlevel 2 (to
check with "uname -r" will show that version), but the system
has been updated two more times to patchlevel 4.
The notation could be X.Y-pZ or X.Y.Z for -RELEASE installations,
and X.Y-B for -STABLE installations. However, it's not hard to
write any custom "parser and composer" if urgently needed.
Maybe things also present in "uname -a" output (such as architecture
and OS name) could be included, but I think that's not required
because it's mostly obvious. :-)
> 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.
Also very nice. By simply _viewing_ the file, the most non-current
version will be discovered, so maybe (just _maybe_) re-ordering them
in upside-down (newest version on top) would be better? Of course,
this would not go well with the "log idea". Files like UPDATING
in the /usr/ports and /usr/src tree use such an approach.
Such a log file would not feel comfortable in /etc, it should
rather go to /var or even /var/log. :-)
> 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.
How about performing "version skips", e. g. from -p1 to -p4
directly (using freebsd-update), or wider steps, e. g. from
8.3 to 8.4 (using sources per CVS)?
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120504164519.d04ba910.freebsd>