freebsd-update not updating reported patchlevel

[Polytropon]

On Fri, 4 May 2012 16:45:51 -0500 (CDT), Robert Bonomi wrote:
> 
> Polytropon <freebsd at 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 at 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, ...