Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Apr 2002 12:54:00 +0200
From:      "Karsten W. Rohrbach" <karsten@rohrbach.de>
To:        Doug Barton <DougB@FreeBSD.org>
Cc:        JJ Behrens <jj@nttmcl.com>, freebsd-stable@FreeBSD.org
Subject:   Re: *** HEAD'S UP ***
Message-ID:  <20020424125400.F87244@mail.webmonster.de>
In-Reply-To: <20020423215717.S66402-100000@master.gorean.org>; from DougB@FreeBSD.org on Tue, Apr 23, 2002 at 09:58:34PM -0700
References:  <20020422114407.B21612@alicia.nttmcl.com> <20020423215717.S66402-100000@master.gorean.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--xQmOcGOVkeO43v2v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Doug Barton(DougB@FreeBSD.org)@2002.04.23 21:58:34 +0000:
> On Mon, 22 Apr 2002, JJ Behrens wrote:
>=20
> > I strongly disagree with your disagreement of his disagreement :))  Cit=
ing
> > /etc/defaults/rc.conf once more:
> >
> > # The ${rc_conf_files} files should only contain values which override
> > # values set in this file.
>=20
> 	The comment exists because some people with commit privileges to
> this file have different ideas as to how it should be used. If you want to
> blindly trust your system to changing winds of fortune, that's your right.
> Personally, I don't recommend it.

in _both_ of the scenarios (eg. copying /etc/defaults/rc.conf to
/etc/rc.conf and editing configuration in place, or just "superseding"
default settings the other way round), a sensible systems administrator
does _in no way_ get around the task to diffing the new
/etc/defaults/rc.conf against the old one and do customizations to
/etc/rc.conf.

How about a Changelog? NOTES (HEAD) and UPDATING in /usr/src are one
way, but a semi-automatic way of making changes transparent to the
administrator would be a good start, i think.

[putting on asbestos suit]
for one of my workstations at home i use debian woody, and they got this
glorious idea of apt-changelog. installing this package gives you a diff
between old changelogs (installed packages) and the new ones (updates).
having this mechanism in place gives you a really good time when you
upgrade a system from binaries, which - if apt-changelog is not
installed - is pretty intransparent to the operator due to the amount of
automation behind the scenes. they tackle a different problem with it,
but i think it makes sense.
[im pretty sweaty now, putting asbestos suit off again ;-)]

so, how about the idea of having a Changelog for the userland
(/usr/src/etc based or somewhere in the source hierarchy it would make
sense), and one for the kernel (/usr/src/sys)?

this would provide the following improvements to administrators and
users:

- major kernel issues (device numbering changes, fixes and changes in
  behaviour of major kernel subsystems) are documented centrally. i
  recognize that most folks out there do not have their provate mirror
  of the cvs to pull out the commit logs (even in case an admin _has_
  knowledge and access to anoncvs, it is a pretty PITA to dig through
  the source tree and pull out cvs commit logs to find out what has
  changed)
- changes to default configuration, mods to the /etc/rc* system
- most important, a list of _resolved_ SAs that are in the current dist.
  in fact, i recognize this as a major point, judging from several
  threads on -hackers and -security of the last weeks. finding out what
  "patch level" you are on an arbitrary box would be "more
  /etc/Changelog" and there you go. mergemaster would display the diff
  between old and new version right when it starts, so the admin
  instantly gets an overview of what major things have changed

of course, this implies these two or three files to be maintained by
someone. the release engineer, who must have a certain overview and
insight of the system as a whole before generating a release, would be
the best to commit the Changelogs, IMHO. i see that warner maintains
the UPDATING file, but he is (according to the docs) not directly
involved in release generation.

comments?

regards,
/k

--=20
> Life is a sexually transmitted disease.
KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie
http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.n=
et/
GnuPG:   0xDEC948A6 D/E BF11 83E8 84A1 F996 68B4  A113 B393 6BF4 DEC9 48A6
REVOKED: 0x2964BF46 D/E 42F9 9FFF 50D4 2F38 DBEE  DF22 3340 4F4E 2964 BF46
REVOKED: 0x4C44DA59 RSA F9 A0 DF 91 74 07 6A 1C  5F 0B E0 6B 4D CD 8C 44
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists. 1=
0x

--xQmOcGOVkeO43v2v
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Comment: For info see http://www.gnupg.org

iD8DBQE8xo7Is5Nr9N7JSKYRAlJ5AJ9QQaDSH6/c/WW4dx/MiJDAz3ImdwCfbJwe
5Rn5c1FTs7W59lty8Bg4Z0M=
=MQD7
-----END PGP SIGNATURE-----

--xQmOcGOVkeO43v2v--

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?20020424125400.F87244>