Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Aug 2001 17:13:29 -0500
From:      Christopher Schulte <christopher@schulte.org>
To:        Mike Meyer <mwm@mired.org>, ian j hart <ianjhart@ntlworld.com>
Cc:        "stable@FreeBSD.ORG" <freebsd-stable@FreeBSD.ORG>
Subject:   Re: RELENG_4_3 calls itself -RELEASE?
Message-ID:  <5.1.0.14.0.20010803170055.03355828@pop.schulte.org>
In-Reply-To: <15211.7879.635254.595670@guru.mired.org>
References:  <3B6AF5AB.5116FD56@ntlworld.com> <2.1-7761648-395-A-OEWW@smtp-server.mmcable.com> <3B6AF5AB.5116FD56@ntlworld.com>

next in thread | previous in thread | raw e-mail | index | archive | help
At 04:59 PM 8/3/2001 -0500, Mike Meyer wrote:
>A very unreliable one. Given N commits on the branch, you have N+1
>possible states for the system to be in. If you leave the name as is,
>you can't tell the difference between any of them. If you change the
>name, you can only tell the difference between 1 of them and rest, and you
>have N states you can't tell the difference between. If you're using
>that to decide whether or not your systems are in some way "safe", you
>need to be hit with *real* clue stick.

Don't people keep old fashioned status-logs on their servers?  Something as 
easy as:

system.foo.org
FreeBSD 4.3-RELEASE 4.3.0p9 (RELENG_4_3) #0: Sat Jul 28 01:49:03 CDT 2001
cvsup: RELENG_4_3 @ Sat Jul 28 01:33:33 CDT 2001 and make world|kernel
vulnerabilities: NONE

For each box you maintain, update vulnerability status when new problem 
report hits the fan.  Update when you cvsup, make world, patch parts of 
source and so on.

The OS should report its 'patch' level more accurately, but the problem is 
there are far too many ways to update a box.  Do I cvsup and make 
world?  Do I cvsup and only install newly changed binaries?  Maybe I 
manually apply a patch and rebuild part of my source.  Or use the binary 
patches?  Install a third party binary to replace FreeBSD's service 
altogether?  You get the point.  FreeBSD's flexibility comes back to shoot 
itself in the foot, here.

No matter which approach you take, documentation may be a viable solution.

>--
>Mike Meyer <mwm@mired.org>                      http://www.mired.org/home/mwm/
>Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

--chris


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20010803170055.03355828>