Date: Sat, 5 May 2012 00:05:42 +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: <20120505000542.34f8c1f5.freebsd@edvax.de> In-Reply-To: <201205042145.q44Ljpbr044152@mail.r-bonomi.com> References: <20120504193004.c749ce16.freebsd@edvax.de> <201205042145.q44Ljpbr044152@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 May 2012 16:45:51 -0500 (CDT), Robert Bonomi wrote:
>
> Polytropon <freebsd@edvax.de> wrote:
> >
> > First of all, thanks for explaining your point of view.
> > Allow me to add a few thoughts:
> >
> > On Fri, 4 May 2012 11:44:49 -0500 (CDT), Robert Bonomi wrote:
> > >
> > > Polytropon <freebsd@edvax.de> wrote:
> > > > 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.
> > >
> > > The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be
> > > included in kernal builds, and where the *handful* of utilities -- e.g.
> > > lsof -- that are intimately coupled to the exact O/S version are already
> > > picking up 'system specific' gory details.
> >
> > Correct. I appreciate the idea of having _one_ centralized
> > point for that information that is "authoritative" regarding
> > all queries. Like "uname" displays several aspects of the
> > kernel's data, it is limited in some regards:
> >
> > For example, if you have updated the system the binary
> > way to -p3 which included a kernel change, uname will
> > report that -p3 properly. If you follow -STABLE, you
> > don't get the information of what "build" you currently
> > have, so you cannot put it into relation "after what
> > -p<level> we currently are".
> >
> > % uname -r
> > 8.2-STABLE
>
> "uname -v", maybe ??
Like "uname -a" ("maximum output"), only the date of the kernel
build is present. I'd like to know that "strange number" and
how it relates (pre-/postdates) -p<level> patch levels.
> If you're talking about trying to associate a particular patch/revison
> level of a particular program with a partiular 'world' patchlevel. That
> is a very different problem, and requires a separate separate solution,
> something like a 'correlation' database.
Yes, that was my primary intention.
> > For the kernel, uname prints various information (which are
> > obtained from the kernel directly, which is good), but what
> > program can do the same for the system?
>
> For kernel info, any program that can 'popen' for write "uname -a". *grin*
> For the patchlevel of the 'world', TTBOMK it isn't recorded anywhere
> conveniently accessible.
I know that this "build" number is stored somewhere (I found it
once!), I think it was a header file. Sure, you can grep for it,
but it would be easier to make this information better accessible
(and maybe even to put it into relation to a patch level number).
> > Not fully, if I see it correctly. E. g., what "build" number
> > has a particular -STABLE installation? Or, if kernel and world
> > are able to be updated independently - no kernel change, but a
> > program change from -p<level> to -p<level+1> will leave the
> > kernel's uname -r at -p<level>, so how to tell easily that
> > the world is at -p<level+1>?
>
> It doesn't presently exist.
>
> That's precisely what the solution I proposed addresses.
>
> In the complete solution I proposed,
> 'tail -1 /etc/{patchlog'
>
> Or, for a program,
> one can popen() that command, and read the output
> or even
> #include <sys/patchlog>
> #include <stdio.h>
>
> fd=fopen(PATCHLOG,"r");
> fseek(fd,PATCHLOG_LAST,SEEK_END);
> fgets(line,sizeof(line),fd)
So when does it arrive in -CURRENT? :-)
> > > The entire point of my proposal is to make it an IMMUTATABLE RECORD of
> > > 'what was done'. 'add to top' has several disadvantages. First,
> > > a performance issue, you do have to read down the log to find the
> > > first 'END' line rather than being able to seek directly to it.
> > > Second, and the *BIG* one, you risk destroying the prior information
> > > by re-writing the file. Third, it makes it easier for a 'malicious'
> > > update to cover it's tracks.
> >
> > Additionally, _undoing_ operations would also be logged - not
> > by omitting lines, but by a proper record that states how things
> > have been reverted to a previous level, which is also very good
> > for diagnostics.
>
> If it's being done by automation, it can either log all the individual
> 'undo' changes, or just log a 'reverting to patchlevel {foo} line.
> There are benefits to both approaches.
>
> If it's a 'manual' reversion, there's no way to guarantee anything gets
> added to the log.
Let's assume that the standard ways (freebsd-update, make installworld
or installkernel, mergemaster) are sufficiently considered to deal with
the logging when undoing changes. Of course that could make things a
bit complicated (e. g. overwriting "newer" files with "older" ones).
> > > When you learn to design stuff that _you_ can't break -- even if you are
> > > deliberately trying -- life gets a lot easier. *GRIN*
> >
> > Very true. The idea of "proper append-only" and continuous logging
> > is familiar to me in terms of database operations. Any state can be
> > constructed from a proper log. In an extended approach, CVS uses
> > the "only add information, not delete them" to manage versions,
> > which is like "database, undelete, any version, progress meter
> > and logging" all in one. :-)
> >
> I used to do work for the financial/brokerage industry. There is a saying
> that "for any foolproof system there exists a _sufficiently_determined_
> fool capable of breaking it."
That is a general principle in _all_ IT-related work. :-)
> I can state, from years of experience, that
> that industry has a *LOT* of 'sufficiently determined' fools. and it's
> -never- their fault, and you have to fix it *IMMEDIATELY*, every second their
> app is off line costs ${BIG_BUCKS}
Of couse, simply because "I didn't do any anything - I just go
there and clickityclick!" :-)
--
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?20120505000542.34f8c1f5.freebsd>