On Thu, Dec 28, 2006 at 12:56:45AM +0100, Hubert Feyrer wrote:
> On Wed, 27 Dec 2006, Darren Reed wrote:
> >>Seconded. Darren, could you ellaborate, please?
> >
> >If "rcadmin" was to be committed, part of its purpose would be to
> >search the rc.d directories for "foo", such that "rcadmin enable foo"
> >would work if foo is in /etc/rc.d or /usr/pkg/etc/rc.d or...(it doesn't
> >do that yet.)
> >
> >The name of the game is to make the interface to using the scripts
> >something else so that you don't need to know the name of the script
> >or its location, just the the name of the service.
> 
> So the point is to add a second interface to disable/enable services, 
> besides editing /etc/rc.conf, that keeps state in single files (as already 
> provided by the rc.subr framework) and that prevents users from knowing 
> directory/path data?
> 
> The question coming to my mind would be "what's wrong with putting 
> ipfilter=yes into /etc/rc.conf" - what is it?

How do you script it?

But really, you need to know:
a) which file to edit
b) how to edit it correctly
c) know if nobody else is editting it at the same time
...

To old timers, sure, "edit /etc/rc.conf" seems easy.

But there are lots of complications and i ask you this,
is asking someone to edit a file in order to enable a
service the easiest we can make it?

Why can't it be easier?

Why can't we make it that you can just run some command
line tool and that takes care of all of the above complications
for you ?

Darren