sysconf -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.

[Doug Barton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

[ Snipping the areas in which there is no disagreement ]

On 10/11/2010 12:22 PM, Devin Teske wrote:
| On Mon, 2010-10-11 at 10:40 -0700, Doug Barton wrote:
|
| 	c) misses some knowledge of FreeBSD resources (e.g., mktemp)
|
|> I'm adding that in now.

Good to know. The more you can boil down the critical elements of the
tool the easier it will be to review, FYI. If you haven't already, you
might review /etc/rc.subr and some of the scripts in /etc/rc.d for an
idea of what I mean by "rc.d style."

| 5. For those reasons I am not supportive of adding this to the base at
| this time
|
|> I agree. The 1.0 revision posted is not a candidate for base-
|> distribution. However, the thread has helped me design the second
|> revision around that desire.

Please don't focus on "getting something into the base." Focus on
producing a good tool.

| 7. I agree with the author's statement that in an ideal world the
| internals of the script would be added to rc.subr so that they could be
| available to the whole rc.d system.
|
|> And then the script could be programmed to source /etc/rc.subr and
|> therefore get even closer to the neighborhood-style of rc.d scripts
|> (which do the same).

Once again, I'm not sure that having this as a standalone script in the
base is the right way to approach this problem. Obviously there is
interest in the functionality your script currently provides, and I
agree that it's an area worth pursuing. But let's not focus on what the
final form _should_ be, since that could prevent us from seeing what it
_could_ be.

|> Might you have meant "/etc/rc.conf.d/servicename is the last file
|> sourced for any given invocation of source_rc_confs()"??

I was going by memory, and may have had some of the details wrong. I
think you get the gist of what I am suggesting however.

|> So, if someone wants to disable a given service... say, named, it seems
|> logical that the _minimum_ that the service(8) script must do is:
|
|> Either A:
|
|> Cheat and plop the new value in the last file sourced (in this case,
|> appending `named_enable="NO"' to /etc/rc.conf.d/named).
|
|> or B:
|
|> 1. Find the last place that it was defined (search in reverse-order)
|> 2. Replace the last instance in the last place it was defined
|
|> Of course, no modification should ever be made to /etc/defaults/rc.conf,
|> so it also stands to reason that if the directive is not found, then
|> throw it into the first (aka "primary") file (in this case, the first
|> file in $rc_conf_files -- usually /etc/rc.conf).

I think your analysis is correct, but your conclusion is wrong. There
are a lot of reasons why you might not want to modify /etc/rc.conf, the
biggest one being what was already discussed in this thread. In large
server farms /etc/rc.conf is often under centralized control (using
cfengine, or similar) and modifications to it may not be possible,
desirable, or persistent.

|> If there are multiple instances of definition, only the last such
|> definition will be replaced. The end result is that the operation is not
|> sloppy, and doesn't result in growing files (that simply appending would
|> result in).

This argument I'm sort of sympathetic to, but that's also one of the
reasons I'm proposing that /etc/rc.conf.d/servicename is the right thing
for us to twiddle since it's largely unused atm.

|> Also, I wouldn't go much further than the minimum... say in searching
|> out all uses and consolidating all occurrences down to one definition in
|> a single file. There are times when you do want the duplicate definition
|> hanging around. For example, if you've got /etc/rc.conf shared among a
|> bevy of machines yet you rely on /etc/rc.conf.local to override values
|> specific to the local machine.

Yes.

| So to summarize, the general idea is a good one and needed, and an area
| that I'd like to see more work in. Perhaps it might be a good idea to
| move the discussion about that to freebsd-rc@?
|
|> I'll look into signing up for the rc mailing list (didn't see that when
|> I checked last -- I'll have to look again). Maybe I'll post v2.0 to
|> there (but will cc back hackers cause I know folks may not be part of
|> both).

The canonical way to deal with that is to post the message to the proper
list (-rc@), then post a brief note to the other list (-hackers@) saying
where the discussion is being continued. We discourage people from
cc'ing multiple FreeBSD lists.


hth,

Doug

- -- 

Breadth of IT experience, and    |   Nothin' ever doesn't change,
depth of knowledge in the DNS.   |   but nothin' changes much.
Yours for the right price.  :)   |		-- OK Go
http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (MingW32)

iQEcBAEBCAAGBQJMtLKTAAoJEFzGhvEaGryE13IH/3E2rT0CRrO/hm0Ssp/ttgSp
dVdYRpWbXLM8ELz6B5jzL9/maJK6mUpqkO6n+89KWFVvNkUnlBE7e4F/OI8q63vA
5273cwJDI1OlIHE2dNYylWbETs9NjdmCthNn6emRtMf++3+1yikSfDt+KaJ9AiNk
7/rus6/3Q7DawBeUlx4RnMTV3bFC/yfwJfvYzve14t0UN//SXw+0EzErbWFWheqD
IqEsu9eCZM2tyFNZKORW0IFxvJ/5QT4HqVwnzzSD4NUw5M+pp7u3W06USVV/vl3G
+soFPcBANLBlqTN/rTjJ8cJrUpcz1+nXbJ6nVjxVSqKRiCLKId3gkQFLePzwtO8=
=6RwN
-----END PGP SIGNATURE-----