Re: *** HEAD'S UP ***
Doug Barton([EMAIL PROTECTED])@2002.04.23 21:58:34 +:
On Mon, 22 Apr 2002, JJ Behrens wrote:
I strongly disagree with your disagreement of his disagreement :)) Citing
/etc/defaults/rc.conf once more:
# The ${rc_conf_files} files should only contain values which override
# values set in this file.
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
--
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.net/
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. 10x
msg44414/pgp0.pgp
Description: PGP signature
Re: *** HEAD'S UP ***
If memory serves me right, Karsten W. Rohrbach wrote: 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. How is this different from the release notes? src/release/doc/* http://people.freebsd.org/~bmah/relnotes/ - 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 This information is in UPDATING. I suppose one could make a credible argument that it should be in the release notes for the security branches (e.g. RELENG_4_5), but that's not the way we do things currently. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: *** HEAD'S UP ***
On Sat, 20 Apr 2002, Doug White wrote: On Fri, 19 Apr 2002, Doug Barton wrote: I highly recommend backing up your existing rc.conf[.local], and copying /etc/defaults/rc.conf to /etc/rc.conf. NO NO NO!! YOU WILL CRASH YOUR SYSTEM IF YOU COPY DEFAULTS/RC.CONF TO RC.CONF WITHOUT REMOVING THE INCLUSION CODE AT THE BOTTOM. I fixed this almost two years ago. :) -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: *** HEAD'S UP ***
On Sat, 20 Apr 2002 [EMAIL PROTECTED] wrote:
In short, I strongly disagree with explicitly include your choices
for anything that you care about, whether they are the defaults or not.
I strongly disagree with your disagreement :)
To me, it makes more sense explicitly include choices for anything you
care about, whether they are defaults or not.
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Need to update rc.conf (Was: Re: *** HEAD'S UP ***)
On Sun, 21 Apr 2002, Andy Farkas wrote: On Sat, 20 Apr 2002 [EMAIL PROTECTED] wrote: In short, I strongly disagree with explicitly include your choices for anything that you care about, whether they are the defaults or not. I strongly disagree with your disagreement :) To me, it makes more sense explicitly include choices for anything you care about, whether they are defaults or not. The reason I started doing what I suggested is that over the years I got burned by people changing defaults. Whatever you _think_ things should be, the reality is what it is. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
*** HEAD'S UP ***
Howdy, Apparently my last message wasn't clear enough, for which I apologize. In addition to the general, non-life-threatening changes to /etc I did recently, a few more fundamental things have changed as well, specifically to /etc/defaults/rc.conf. Rather than focus on the specifics, I'd like to suggest a more general solution. I highly recommend backing up your existing rc.conf[.local], and copying /etc/defaults/rc.conf to /etc/rc.conf. Then, go through the whole file, and explicitly include your choices for anything that you care about, whether they are the defaults or not. In this way, you can be sure that the system will always behave the way you want it to. In addition to this, I generally include the settings that are specific to the individual machine (like hostname, gateway, ifconfig_) in /etc/rc.conf.local. That way it's easier to blat the rc.conf file periodically. I also added an option to mergemaster to compare your rc.conf[.local] stuff to what's in /etc/defaults/rc.conf after you're done updating. To take advantage of that, use 'mergemaster -C', or 'echo COMP_CONFS=yes .mergemasterrc'. What this won't show you is differences to the defaults that you don't have in /etc/rc.conf[.local]. For that, you're expected to pay attention to the diff of /etc/defaults/rc.conf as you install it. :) Any questions, comments, or suggestions... fire away. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: *** HEAD'S UP ***
Date: Fri, 19 Apr 2002 15:37:27 -0700 (PDT) From: Doug Barton [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Howdy, Apparently my last message wasn't clear enough, for which I apologize. In addition to the general, non-life-threatening changes to /etc I did recently, a few more fundamental things have changed as well, specifically to /etc/defaults/rc.conf. Rather than focus on the specifics, I'd like to suggest a more general solution. I highly recommend backing up your existing rc.conf[.local], and copying /etc/defaults/rc.conf to /etc/rc.conf. Then, go through the whole file, and explicitly include your choices for anything that you care about, whether they are the defaults or not. In this way, you can be sure that the system will always behave the way you want it to. In addition to this, I generally include the settings that are specific to the individual machine (like hostname, gateway, ifconfig_) in /etc/rc.conf.local. That way it's easier to blat the rc.conf file periodically. I also added an option to mergemaster to compare your rc.conf[.local] stuff to what's in /etc/defaults/rc.conf after you're done updating. To take advantage of that, use 'mergemaster -C', or 'echo COMP_CONFS=yes .mergemasterrc'. What this won't show you is differences to the defaults that you don't have in /etc/rc.conf[.local]. For that, you're expected to pay attention to the diff of /etc/defaults/rc.conf as you install it. :) Any questions, comments, or suggestions... fire away. OK. You asked for it... I really hate to see the suggestion that people copy files from /etc/defaults to /etc. This really breaks the paradigm of having only changes in defaults in /etc so that defaults can be changed with a normal system update. While the new mergemaster option helps with this, I would really rather not see rc.conf (and other files) become large and not trivial to scan over. A suggestion to scan through /etc/defaults/rc.conf is not unreasonable. Of course, people SHOULD pay attention to whet mergemaster has to say, but even I have messed up when updating an important server and not watching all of the things mergemaster showed in an effort to get the system back on-line quickly. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
