Date: Mon, 22 Apr 2002 21:17:40 -0700 From: "Lucky Green" <shamrock@cypherpunks.to> To: <freebsd-stable@freebsd.org> Subject: Re: /etc/defaults/rc.conf theory Message-ID: <002d01c1ea7d$cf1cb060$c33a080a@LUCKYVAIO>
next in thread | raw e-mail | index | archive | help
Doug Barton wrote: On Sun, 21 Apr 2002, M. Warner Losh wrote: > In message: <200204200256.g3K2uOu10038@sheol.localdomain> > hawkeyd@visi.com (D J Hawkey Jr) writes: > : IMHO, you muddy, if not nullify, the abstract altogether. You are > advocating > : copying this file down to /etc, and editing it. There goes the concept of > : "overriding the values contained in this file". > > Yes. /etc/defaults/rc.conf and /etc/rc.conf are separated because we > wanted to change the defaults from time to time. Users hate this. ----------------- Depends on the user. My rc.conf has perhaps 15 lines and some of those are simply there because the OpenSSH and bind ports in STABLE tend to lag quite a bit behind the release and the port versions are installed in different directories than the those that come with the default FreeBSD distribution. I once or twice read /etc/defaults/rc.conf out of sheer curiosity, but I don't seem to be impacted by the majority of the defaults. There were times when I did wish to make a change and for that it was handy to be able to see what the defaults are. As for changing defaults from underneath the user, there are probably times when it makes sense to do so for security reasons. There was a time when all machines came with the basic services (chargen, echo, etc.) turned on. This is no longer the case since security principles have changed and I doubt many users noticed that change once it happened. Those who did notice probably also knew how to re-enable these services. There are some sudden changes that can break things, I remember upgrading once and sendmail stopped working because the config files had moved from /etc to /etc/mail/, but it didn't take long to figure out what the problem was and cleaning up the hierarchy as features get added just has to be done at times even if that breaks things. If anything, I believe rc.conf could be shortened further. I doubt there are many FreeBSD boxes out there that don't use ntp, so that line could be added to the defaults. Sendmail recently added another 4 lines to rc.conf, which again could be moved into defaults for those users that actually still use sendmail as the MTA. The basic assumption that I as a user am making is that if the FreeBSD team re-organizes layouts for a release, they will make the corresponding changes to /etc/defaults/rc.* so I don't have to worry about a service breaking during upgrade because some path changed while given the developers an opportunity to clean up the layout without the user having to track any such changes by wading through pages of docs. Which is important to me, given that I maintain a machine on the other side of the planet to which I only have ssh access. The less lines there are in rc.conf, the less chance I get to screw up the config. Of the three or four times in the last few years that the machine didn't come back from a reboot after making the world or upgrading ssh, a typo or error in rc.conf was the culprit each time. The current structure works well for me. Other users with highly customized boxes may feel differently. But then, I am tracking the present security branch, not CURRENT, and thus may care less about what well-tested reorganizations happen under the hood than more adventurous users. There may be better structures than the current structure. I don't know. However, if you change the structure, whatever you do please ensure that there is an automated migration tool that will suck in the current config files and bring them into the new format as part of an upgrade from source. One satisfied FreeBSD user, --Lucky 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?002d01c1ea7d$cf1cb060$c33a080a>