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.
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.
> 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.
> 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.
> 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?
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.
>> -> 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.
>
> Regards,
>
> --
>
> jhell,v
--
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
[email protected]
-> 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.
-> END TRANSMISSION <-
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
