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

[jhell]

On 10/07/2010 01:47, Devin Teske wrote:
> 
> On Oct 6, 2010, at 9:49 PM, jhell wrote:
> 
>> On 10/06/2010 23:29, Devin Teske wrote:
>> 
>> I see no real advantage
> 
> If you had to administer thousands of FreeBSD systems, you would.
> 

Normally I have found large scale (1000's) of Unix like systems
benefiting from the use of cfengine that is available via ports(7) and
the use of other such software as Nagios, MUNIN for example that allow
you to achieve quick deployment and monitoring of production systems.

Not that this is a real comfortable solution to this either but the
values contained throughout FreeBSD systems are also available via
bsnmpd(1).

> This script is obviously targeted to those for which are mentioned in
> the header... "system administrators, power-users, and developers".
> 
> 
> 
>> With that noted what advantage does this script bring compared to
>> a script like service(8) that is already in the base system?
> 
> service(8) clearly doesn't do what this script does. The values that
>  associate to an executable rc.d script are but only a fraction of 
> what rc.conf(5) is used for. See `/etc/defaults/rc.conf' for all 
> possible values.
> 

I am well aware of its use and the values it contains for a majority of
the FreeBSD releases, dating back to 4.2 ;) Before that time it was
mostly Linux.

> 
>> How much time does a end user spend enabling/disabling services for
>> a system?
> 
> In our environment? A script like this empowers support personnel and
> engineers with the ability to perform a generalized query on 
> thousands of machines simultaneously and collate the results back 
> into a paging application (such as less(1) or more(1)), finding 
> possible misconfigurations, problems, or other issues that arise by 
> human error, script error, or legacy options languishing from an 
> upgrade process. Further, with the ability to set options, it makes 
> remediating problems quite easy.
> 

Alright, understandable. Large scale environments don't really fit into
the PAGER area but I am following you.

> 
>> How much of a difference in time would this make to the end user as
>> per say just having to echo a variable into an rc.conf?
> 
> That's a sloppy way to manage production equipment/environments.
> 

Remember, there is a very few examples of your script to go on for usage
and really not much real example usage scenarios that at least I can
relate to by giving the script a quick look-over without getting really
deep into it (yet). This is why the probing questions are coming up and
that will at least help me if not others build a scenario at which your
script can be looked at in possibly a more correct manner rather than
passing judgment.

> 
>> If this would be put in place into the base system where would it 
>> be and who would maintain it ?
> 
> It would likely be placed in the same directory as sysctl(8) 
> (/sbin/sysrc).
> 
> I would maintain it.
> 
> 
>> Is it feasible to expect an end user to read rc.conf(5)
>> services(8) while also consuming knowledge of etc/defaults/rc.conf
>> & boot(8) as well sysctl.conf(5) and loader.conf(5).
> 
> A friend of mine and I just installed 8.1-RELEASE-p1 onto his laptop.
> We had to go through all those man-pages and more to get everything
> good with the wpa_supplicant_* options. We didn't have to go to
> google, bing, wolfram alpha, barnes & noble, or any place... all the
> answers for setting up his laptop using 802.11g tied to a WAP w/
> WPA2.
> 
> But what does that have to do with the price of bread in China?
> 

Well unless those bread factories machines are powered by FreeBSD, I
hope not much. ;)

> This script helps system administrators, power-users, and developers.
> It's designed to make the task of performing non-interactive edits to
> rc.conf(5) not only easier, but cleaner. The files are left fully
> in-tact by the script, which is the important part to note. It's not
> going to sloppily keep tacking on new values for the same directive
> if the script is called 1,000 times over. This enables such things as
> being called from cron on a regular basis even.
> 
> 
>> Also you search for grep and awk in your script.
> 
> No. I check for the presence of them with $PATH expansion.
> 
> The have() function is a one-line function that remaps the `type' 
> shell built-in to have no output, yet still return the error status 
> (or lack thereof). If you read the sh(1) manual, you'll see that the
>  `type' built-in can be passed a shell keyword, a shell function, or
>  failing that, it will find the executable via $PATH expansion, and 
> failing that will return error status. The have() function that I 
> have defined in my script allows me to do this:
> 
> if have grep; then # use grep else # use case with glob(7) pattern 
> matching fi
> 
> 
>> If this were to be in base, then utilities like this would not need
>> to be searched for as base utilities are generally static to where
>> they live in the file-system already... /usr/bin/grep /usr/bin/awk
>> for example. I do not think it makes much sense for a base utility
>> to search outside of its world for a executable especially for
>> grep(1) and awk(1). Call these directly and let the end user modify
>> their PATH as to where the location of these would actually be
>> called from rather than adding extra complicity.
> 
> The integral point of confusion is lack of knowledge that have() is 
> `type' which already performs $PATH expansion. I'm not probing for 
> their location, I'm testing for their existence so that I can use the
> name. Think of it like a `try' statement.
> 

Alright thank you for your explanation. I do not normally see this usage
and this just sort of stood out at me and I did not want to assume what
you were trying to accomplish, without asking.

> 
>>> -> 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.
> 
>> Due to this disclaimer I am not sure that even the implicit BSD 
>> license can override this. Though there is a thin gray line here, 
>> it might be suitable to remove this from future email unless you 
>> are specifically addressing something to a specific person.
> 
> Please. If you read it (as have I many times) it means nothing more 
> than that I own the IP rights to what I wrote and that if you aren't
>  the person that I sent this to (and you are whom I sent this to -- 
> by-way of the freebsd-hackers mailing list), then you should not read
> it, trash it, and purge your trash. To my eyes, it didn't look all
> that legalese to me, and thought it was pretty clear.
>

Ok


Regards,

-- 

 jhell,v