From owner-freebsd-questions@FreeBSD.ORG Fri May 4 22:05:46 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347EB106566B for ; Fri, 4 May 2012 22:05:46 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id D1D848FC12 for ; Fri, 4 May 2012 22:05:45 +0000 (UTC) Received: from r56.edvax.de (port-92-195-20-192.dynamic.qsc.de [92.195.20.192]) by mx01.qsc.de (Postfix) with ESMTP id 0C7003CF53; Sat, 5 May 2012 00:05:43 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id q44M5gpr003003; Sat, 5 May 2012 00:05:43 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Sat, 5 May 2012 00:05:42 +0200 From: Polytropon To: Robert Bonomi 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> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: freebsd-update not updating reported patchlevel X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:05:46 -0000 On Fri, 4 May 2012 16:45:51 -0500 (CDT), Robert Bonomi wrote: > > Polytropon 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 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 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 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 to -p will leave the > > kernel's uname -r at -p, so how to tell easily that > > the world is at -p? > > 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 > #include > > 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, ...