> An example would be if the user started out with supplying "-s" to ntpd
> and then changes his mind and removes the flag. The idea is to then call
> rcctl with an empty "flags" argument to get the default set of flags
> instead.
>
> It was my understanding from the man page that this was the app
On Thu, Oct 09, 2014 at 10:04:44PM +0200, Ingo Schwarze wrote:
> > A possible solution to this would be to relax the flags check in rcctl,
> > so it only cares if there are actual flags supplied. See diff below for
> > a suggestion on how to deal with this which seems to work.
>
> The first half o
On Thu, Oct 09, 2014 at 10:02:50PM +0200, Antoine Jacoutot wrote:
> >
> > The later behaviour causes a problem when modifying special services
> > like pf. When disabling pf a "pf=NO" is added to rc.conf.local as
> > expected, but when trying to enable it again it will fail because the
> > ansible
Hi Patrik,
Patrik Lundin wrote on Thu, Oct 09, 2014 at 09:02:14PM +0200:
> While working on rcctl(8) support for ansible I have run into a
> situation I am not sure how to deal with.
>
> Basically, if the user has supplied arguments we append
> "flags " and this works good.
>
> If the user supp
On Thu, Oct 09, 2014 at 09:02:14PM +0200, Patrik Lundin wrote:
> Hello,
>
> While working on rcctl(8) support for ansible I have run into a
> situation I am not sure how to deal with.
>
> Basically, if the user has supplied arguments we append
> "flags " and this works good.
>
> If the user supp
Hello,
While working on rcctl(8) support for ansible I have run into a
situation I am not sure how to deal with.
Basically, if the user has supplied arguments we append
"flags " and this works good.
If the user supplied no arguments, but there currently are flags set
in rc.conf.local we append a
