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

Mon Oct 11 19:22:52 UTC 2010

On Mon, 2010-10-11 at 10:40 -0700, Doug Barton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Unfortunately $LIFE is preventing me from an in-depth review of this
> script at this time, but I wanted to lodge a comment or two. Please
> forgive me for the brevity.
> 
> 1. I applaud any effort in the realm of making things easier for users.

Thanks!

> 2. I like the general concept of having a programmatic interface to the
> "settings" that live in "rc.conf and friends".

Yay! Glad to find people generally support the idea of this script (and
enhancements are on the way, according to what has been discussed in
this thread).

> 3. I have read the thread, and so I have a pretty good idea of the
> environment that the author is working in, and that the complexity of
> this script is (at least in part) a result of that environment.
> 4. That said, I think that in its current form the script is:
> 	a) far too complex

I've already started dramatically reducing the complexity. Script has
dropped nearly 300 lines of code already.

> 	b) not even in the neighborhood of "FreeBSD rc.d style"

^_^

In the same state at least?
Next version should be in the same neighborhood.

> 	c) misses some knowledge of FreeBSD resources (e.g., mktemp)

I'm adding that in now.

> 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.

> 6. I would not object to this being added to ports, however

Let's see if we can't develop something that does meet the stringent
guidelines of base-distribution (failing that I'd love it in ports).

> 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).

> 
> In fact, one of the features that has been requested to add to the
> service(8) script is the idea of taking "enable" and "disable" as
> arguments. I'm supportive of that, but haven't found time to code it
> yet, in part because (as has been illuminated in this thread) the
> problem of determining how to conclusively toggle the setting is not as
> cut and dry as it appears. The model that I had more or less settled on
> for that is to be certain that /etc/rc.d/servicename is the last file
> sourced for any given invocation of source_rc_confs()

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

And slight correction... source_rc_confs() from /etc/defaults/rc.conf
doesn't source anything in /etc/rc.conf.d (it doesn't have the
`servicename' context), but rather load_rc_confs() from /etc/rc.subr
does indeed source /etc/rc.conf.d/servicename as the last file (because
it has `servicename' as a context in the first positional argument).

My feelings are that since the load_rc_conf() does the following:

1. Sources /etc/defaults/rc.conf
2. calls source_rc_confs() which:
3. Sources files from $rc_conf_files in order of appearance
4. Sources /etc/rc.conf.d/servicename if it exists

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).

This tends to work very well.

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).

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.

>  and focus on that,
> but even that mechanism has complications that I don't have time to go
> into right now.

Understandable. $LIFE and $WIFE eat up a lot of CPU cycles. God help you
if you have $PROGENY ^_^

> 
> 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).

> 
> 
> hth,
> 
> Doug
> 
> PS, have a look at, for example, 'service named rcvar'
> 
> - -- 
> 
> 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)
> 
> iQEcBAEBCAAGBQJMs0v4AAoJEFzGhvEaGryEF5oH/iVMaqFwytSIJSucka/4PkfY
> 2hUzw+OjvxqSCPZmxch+zU6hfFkWh8H0ZjbNULoA8y6FLrV1ogJuWqEb3g9K4vKt
> 3rx5reubsyS/bIWd5J0cXSM97hD2bq0DZlyFQKPiDY+xSEPiLvOcFKyzTq4MOu58
> Z78LTBt3sAHc7Yc/lpiJD8lKQDNDzhtUsB13y+7AwmKh7RkYoub0QvlGwFF5D3xu
> a7oNiRUlZJdrhfRQPq65r7h7W0fLJGxQCcOJMaUFvGvdXUREZrsuplV1ABlXZ+tL
> B95dmu7oaOdwE5vkSP+v10Wbl4oMCuLoDhAgrfwhbOF1i2bXbH5UJd+vfyljcss=
> =wz2I
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
-- 
Cheers,
Devin Teske

-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.teske at fisglobal.com

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O
M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h
r>++ y+ 
------END GEEK CODE BLOCK------
http://www.geekcode.com/

-> END TRANSMISSION <-