Re: rcctl(8): special services and flags

2014-10-09 Thread Antoine Jacoutot
> 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 approriate
> way to do it, am I mistaken?

Hmm actually that makes sense yes.
Let me sleep on it... ;-)

-- 
Antoine



Re: rcctl(8): special services and flags

2014-10-09 Thread Patrik Lundin
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 of the patch seems pointless to me.
> Why do you want to allow "disable foo flags"?
> Or am i overlooking something?
> 

I agree the first half may be pointless, I was only trying to be
symmetrical in the handling of the flags keyword so it works both ways:
---
# rcctl enable pf flags 
# rcctl disable pf flags
---

I don't feel strongly about this though, either way is fine for my
needs.

>
> The second half is ok schwarze@ if Antoine wants to commit,
> though i'd slightly prefer the simplified version given below.
> 

Looks good to me :).

Regards,
Patrik Lundin



Re: rcctl(8): special services and flags

2014-10-09 Thread Patrik Lundin
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 module notices that flags are currently set ("NO"), and tries to
> > call "rcctl enable pf flags" which fails: 
> 
> Why is ansible appending flags in the first place when no flags are 
> configured?
> 

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 approriate
way to do it, am I mistaken?

Regards,
Patrik Lundin



Re: rcctl(8): special services and flags

2014-10-09 Thread Ingo Schwarze
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 supplied no arguments, but there currently are flags set
> in rc.conf.local we append an empty "flags" argument to reset the
> default value.
> 
> 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 module notices that flags are currently set ("NO"), and tries to
> call "rcctl enable pf flags" which fails: 
> 
> ---
> # rcctl enable pf flags 
> rcctl: "pf" is a special variable, cannot set "flags"
> ---
> 
> I am not sure how to deal with this properly since I do not want to
> duplicate the _special_services variable in the module.

Indeed, i'd consider that a bad idea.

Besides, i see your problem.  I don't see a good way either to
find out that for running a service without flags

 - both "enable sshd" and "enable sshd flags" works
 - only "enable tftpd flags" works, but "enable tftpd" sets an argument
 - only "enable pf" works, "enable pf flags" errors out

I agree that always allowing the "flags" keyword simplifies usage.

> 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 of the patch seems pointless to me.
Why do you want to allow "disable foo flags"?
Or am i overlooking something?

The second half is ok schwarze@ if Antoine wants to commit,
though i'd slightly prefer the simplified version given below.

Yours,
  Ingo


Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.38
diff -u -p -r1.38 rcctl.sh
--- rcctl.sh1 Sep 2014 18:01:55 -   1.38
+++ rcctl.sh9 Oct 2014 19:41:57 -
@@ -276,7 +276,7 @@ if [ -n "$flag" ]; then
if [ "$action" != "enable" ]; then
_rc_err "${0##*/}: \"flags\" can only be set with 
\"enable\""
fi
-   if svc_is_special $svc; then
+   if svc_is_special $svc && [ -n "$4" ]; then
_rc_err "${0##*/}: \"$svc\" is a special variable, 
cannot set \"flags\""
fi
if [ "$4" = "NO" ]; then


> Index: rcctl.sh
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.38
> diff -u -p -u -r1.38 rcctl.sh
> --- rcctl.sh  1 Sep 2014 18:01:55 -   1.38
> +++ rcctl.sh  9 Oct 2014 18:17:56 -
> @@ -274,10 +274,14 @@ fi
>  if [ -n "$flag" ]; then
>   if [ "$flag" = "flags" ]; then
>   if [ "$action" != "enable" ]; then
> - _rc_err "${0##*/}: \"flags\" can only be set with 
> \"enable\""
> + if [ -n "$4" ]; then
> + _rc_err "${0##*/}: \"flags\" can only be set 
> with \"enable\""
> + fi
>   fi
>   if svc_is_special $svc; then
> - _rc_err "${0##*/}: \"$svc\" is a special variable, 
> cannot set \"flags\""
> + if [ -n "$4" ]; then
> + _rc_err "${0##*/}: \"$svc\" is a special 
> variable, cannot set \"flags\""
> + fi
>   fi
>   if [ "$4" = "NO" ]; then
>   _rc_err "${0##*/}: \"flags NO\" contradicts \"enable\""



Re: rcctl(8): special services and flags

2014-10-09 Thread Antoine Jacoutot
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 supplied no arguments, but there currently are flags set
> in rc.conf.local we append an empty "flags" argument to reset the
> default value.
> 
> 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 module notices that flags are currently set ("NO"), and tries to
> call "rcctl enable pf flags" which fails: 

Why is ansible appending flags in the first place when no flags are configured?


> ---
> # rcctl enable pf flags 
> rcctl: "pf" is a special variable, cannot set "flags"
> ---
> 
> I am not sure how to deal with this properly since I do not want to
> duplicate the _special_services variable in the module.
> 
> 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.
> 
> If I am going about this the wrong way any pointers are greatly
> appreciated of course!
> 
> Regards,
> Patrik Lundin
> 
> Index: rcctl.sh
> ===
> RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
> retrieving revision 1.38
> diff -u -p -u -r1.38 rcctl.sh
> --- rcctl.sh  1 Sep 2014 18:01:55 -   1.38
> +++ rcctl.sh  9 Oct 2014 18:17:56 -
> @@ -274,10 +274,14 @@ fi
>  if [ -n "$flag" ]; then
>   if [ "$flag" = "flags" ]; then
>   if [ "$action" != "enable" ]; then
> - _rc_err "${0##*/}: \"flags\" can only be set with 
> \"enable\""
> + if [ -n "$4" ]; then
> + _rc_err "${0##*/}: \"flags\" can only be set 
> with \"enable\""
> + fi
>   fi
>   if svc_is_special $svc; then
> - _rc_err "${0##*/}: \"$svc\" is a special variable, 
> cannot set \"flags\""
> + if [ -n "$4" ]; then
> + _rc_err "${0##*/}: \"$svc\" is a special 
> variable, cannot set \"flags\""
> + fi
>   fi
>   if [ "$4" = "NO" ]; then
>   _rc_err "${0##*/}: \"flags NO\" contradicts \"enable\""
> 

-- 
Antoine



rcctl(8): special services and flags

2014-10-09 Thread Patrik Lundin
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 an empty "flags" argument to reset the
default value.

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 module notices that flags are currently set ("NO"), and tries to
call "rcctl enable pf flags" which fails: 

---
# rcctl enable pf flags 
rcctl: "pf" is a special variable, cannot set "flags"
---

I am not sure how to deal with this properly since I do not want to
duplicate the _special_services variable in the module.

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.

If I am going about this the wrong way any pointers are greatly
appreciated of course!

Regards,
Patrik Lundin

Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.38
diff -u -p -u -r1.38 rcctl.sh
--- rcctl.sh1 Sep 2014 18:01:55 -   1.38
+++ rcctl.sh9 Oct 2014 18:17:56 -
@@ -274,10 +274,14 @@ fi
 if [ -n "$flag" ]; then
if [ "$flag" = "flags" ]; then
if [ "$action" != "enable" ]; then
-   _rc_err "${0##*/}: \"flags\" can only be set with 
\"enable\""
+   if [ -n "$4" ]; then
+   _rc_err "${0##*/}: \"flags\" can only be set 
with \"enable\""
+   fi
fi
if svc_is_special $svc; then
-   _rc_err "${0##*/}: \"$svc\" is a special variable, 
cannot set \"flags\""
+   if [ -n "$4" ]; then
+   _rc_err "${0##*/}: \"$svc\" is a special 
variable, cannot set \"flags\""
+   fi
fi
if [ "$4" = "NO" ]; then
_rc_err "${0##*/}: \"flags NO\" contradicts \"enable\""