Re: rcctl(8): Fetch default service flags
The problem occurs when I try to manage a service like nfsd which has a default set of flags. Consider the following commands, which basically performs what ansible does when the user is not supplying any extra arguments: --- # rcctl status nfsd NO # rcctl enable nfsd # rcctl status nfsd -tun 4 # --- If I now run the tool again, still without any supplied arguments, it will compare the empty set of user supplied flags to -tun 4 which always differs. So ansible will now think it needs to change something forever :). To solve this I need the default flags to compare to the output of 'status'. Well in this case, I think you should pass the flags you want to ansible -- even if they are the same as the defaults. I'm not very keen on adding a new knob... -- Antoine
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 01:50:52PM +0200, Antoine Jacoutot wrote: If I now run the tool again, still without any supplied arguments, it will compare the empty set of user supplied flags to -tun 4 which always differs. So ansible will now think it needs to change something forever :). To solve this I need the default flags to compare to the output of 'status'. Well in this case, I think you should pass the flags you want to ansible -- even if they are the same as the defaults. I'm not very keen on adding a new knob... This breaks the principle of least surprise. If you do not need to supply flags when calling rcctl in the shell you should not have to supply flags when using ansible. I fully understand if you do not want to add knobs. This only means I will need to replicate svc_default_enabled_flags() in my module. I would rather store as much logic as possible in rcctl itself to keep the overhead/upkeep low, but you can't get everything i guess :). Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 02:50:40PM +0200, Patrik Lundin wrote: On Fri, Oct 10, 2014 at 01:50:52PM +0200, Antoine Jacoutot wrote: If I now run the tool again, still without any supplied arguments, it will compare the empty set of user supplied flags to -tun 4 which always differs. So ansible will now think it needs to change something forever :). To solve this I need the default flags to compare to the output of 'status'. Well in this case, I think you should pass the flags you want to ansible -- even if they are the same as the defaults. I'm not very keen on adding a new knob... This breaks the principle of least surprise. If you do not need to supply flags when calling rcctl in the shell you should not have to supply flags when using ansible. But you should not have to. If you don't pass any flags to ansible, why is ansible looking at the output of rcctl status to compare flags? In saltstack, iirc what I implemented is that flags are only compared when one actually sets some. -- Antoine
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 03:05:40PM +0200, Antoine Jacoutot wrote: But you should not have to. If you don't pass any flags to ansible, why is ansible looking at the output of rcctl status to compare flags? In saltstack, iirc what I implemented is that flags are only compared when one actually sets some. Maby the expected results of our tools are different. My goal for the ansible module is that you either keep a specific set of flags in the playbook which will then get set if necessary, or you remove the flags and will instead get the system default. Not passing any arguments does not mean do not modify any flags, it means make sure we have the default flags. Because of this I will need to check if the current set of flags are the default or not. Hope this makes some sense :). Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
Ouch. I just noticed the following problem. There are four things a user might want: 1. Disable a service. rcctl disable service always does that, and you can compare the output of rcctl status service to NO to decide whether running that is actually needed. 2. Enable the service with default arguments. rcctl enable service flags (now, after the recent change) always does that. 3. Enable the service with custom arguments. rcctl enable service flags custom always does that, and you can compare the output of rcctl status service to custom to decide whether running that is actually needed. 4. Enable the service *without* any arguments (even if it has default arguments). I see no way to do that with rcctl(8). You have to edit /etc/rc.conf.local manually and put: service_flags= It seems that being unable to comply with request 4 is a problem. Besides, in this thread, it seems to me that request 2 and request 4 are sometimes confused with each other. My impression is that for a management tool, it is useful to offer all four options to the administrator, as well as allowing to explicitly switch from any of them to any other of them, including explicitly switching from request 2 to request 4 and vice versa. Take identd(8) as an example. It has daemon_flags=-e by default. If i don't want that, the easiest workaround i see is saying rcctl enable identd flags -t 120 that is, specifying some flags that restate defaults, just to have *some* custom flags. What if a daemon has no unrelated flags that can be abused in this way? Or do you think i'm inventing pointless complication here? Yours, Ingo
Re: rcctl(8): Fetch default service flags
4. Enable the service *without* any arguments (even if it has default arguments). It's been discussed at lenght in Slovenia -- that's a known issue; the move of rc.conf to a parsed config file has had similar side effects on other stuffs. I see no way to do that with rcctl(8). You have to edit /etc/rc.conf.local manually and put: service_flags= Not true. rcctl enable foobar flags ' ' -- Antoine
Re: rcctl(8): Fetch default service flags
Maby the expected results of our tools are different. My goal for the ansible module is that you either keep a specific set of flags in the playbook which will then get set if necessary, or you remove the flags and will instead get the system default. Not passing any arguments does not mean do not modify any flags, it means make sure we have the default flags. Because of this I will need That's backward. From what I know of Puppet and SaltStack, they work totally different. They will never change anything on the system unless you intruct them to. In your case you want that the absence of a configuration knob (flags in this case) resets what in rc.conf.local... I think that is *not* the element of least surprise :-) -- Antoine
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 03:53:15PM +0200, Antoine Jacoutot wrote: Maby the expected results of our tools are different. My goal for the ansible module is that you either keep a specific set of flags in the playbook which will then get set if necessary, or you remove the flags and will instead get the system default. Not passing any arguments does not mean do not modify any flags, it means make sure we have the default flags. Because of this I will need That's backward. From what I know of Puppet and SaltStack, they work totally different. They will never change anything on the system unless you intruct them to. In your case you want that the absence of a configuration knob (flags in this case) resets what in rc.conf.local... I think that is *not* the element of least surprise :-) To me this means the tool would miss if I for whatever stupid reason felt the need to manually tweak rc.conf.localo on a box, later forgetting I had done so. In this case I would need to always specify flags, even default (empty) ones, to be sure all systems are configured the way they are supposed to. This seems to contradict the beauty of defaults. This is probably sliding into bikeshedding territory, so I will leave it at that (would happily discuss it offlist though) :). Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On 2014/10/10 15:19, Patrik Lundin wrote: Not passing any arguments does not mean do not modify any flags, it means make sure we have the default flags. Because of this I will need to check if the current set of flags are the default or not. Would it make sense for rcctl status to display something like default (-tun 4) or similar when it's using default flags (actually, to be more exact about what I mean, when the relevant foo_flags is not set in rc.conf.local - to distinguish it from being explicitly set in rc.conf.local to the same value that is the default).
Re: rcctl(8): Fetch default service flags
On Fri, Oct 10, 2014 at 08:02:17PM +0100, Stuart Henderson wrote: On 2014/10/10 15:19, Patrik Lundin wrote: Not passing any arguments does not mean do not modify any flags, it means make sure we have the default flags. Because of this I will need to check if the current set of flags are the default or not. Would it make sense for rcctl status to display something like default (-tun 4) or similar when it's using default flags (actually, to be more exact about what I mean, when the relevant foo_flags is not set in rc.conf.local - to distinguish it from being explicitly set in rc.conf.local to the same value that is the default). Actually on second though, adding a 'default' command kind of make sense; I'm looking into it. -- Antoine
rcctl(8): Fetch default service flags
Hello, This is another question triggered by working on rcctl(8) support for the ansible service module. The module wants to figure out if it should reset the flags in rc.conf.local to the default set if no arguments are supplied by the user. The problem with this is that there is no way to find out what the default flags are. This makes it hard to deal with a service like nfsd where 'status' will return -tun 4 by default or whatever the user has set previously otherwise. I noticed there is a function in rcctl already that finds this out: svc_default_enabled_flags(). Being able to call this via some argument to rcctl would solve my problem. I am leaving out a diff because I have no idea what a good name for such an argument would be, but just calling svc_default_enabled_flags $svc in the script seems to return what I need. Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
The module wants to figure out if it should reset the flags in rc.conf.local to the default set if no arguments are supplied by the user. Can you provide an example. Because if not arguments are supplied, according to your previous mail, it should run like: rcctl enable foobar flags which will reset the flags anyway. The problem with this is that there is no way to find out what the default flags are. This makes it hard to deal with a service like nfsd But why do you need that exactly? Note that I am not against modifying rcctl, I am just trying to understand the need... -- Antoine
Re: rcctl(8): Fetch default service flags
On Thu, Oct 09, 2014 at 10:58:34PM +0200, Antoine Jacoutot wrote: The module wants to figure out if it should reset the flags in rc.conf.local to the default set if no arguments are supplied by the user. Can you provide an example. Because if not arguments are supplied, according to your previous mail, it should run like: rcctl enable foobar flags which will reset the flags anyway. The problem with this is that there is no way to find out what the default flags are. This makes it hard to deal with a service like nfsd But why do you need that exactly? Note that I am not against modifying rcctl, I am just trying to understand the need... Sorry, I should probably have been more clear on the reason I need it :). The main issue from the ansible perspective is to know if we are _going_ to change something or not. The user may for example run ansible in --check mode where it should only report if it is about to change something or not. Even when not running in --check mode the module needs to report if something was changed or not. Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
Sorry, I should probably have been more clear on the reason I need it :). The main issue from the ansible perspective is to know if we are _going_ to change something or not. The user may for example run ansible in --check mode where it should only report if it is about to change something or not. Ok but then I don't understand why you need to know the default flags :-) If you run rcctl status, it will tell you the current flags of the daemon; if these differ from the new flags you want to pass ansible then 'ansible --check' will report you that it will change the flags. Which is correct, no ? Or did I misundertand something (I probably did...). -- Antoine
Re: rcctl(8): Fetch default service flags
On Thu, Oct 09, 2014 at 11:25:58PM +0200, Antoine Jacoutot wrote: Sorry, I should probably have been more clear on the reason I need it :). The main issue from the ansible perspective is to know if we are _going_ to change something or not. The user may for example run ansible in --check mode where it should only report if it is about to change something or not. Ok but then I don't understand why you need to know the default flags :-) If you run rcctl status, it will tell you the current flags of the daemon; if these differ from the new flags you want to pass ansible then 'ansible --check' will report you that it will change the flags. Which is correct, no ? Or did I misundertand something (I probably did...). The problem occurs when I try to manage a service like nfsd which has a default set of flags. Consider the following commands, which basically performs what ansible does when the user is not supplying any extra arguments: --- # rcctl status nfsd NO # rcctl enable nfsd # rcctl status nfsd -tun 4 # --- If I now run the tool again, still without any supplied arguments, it will compare the empty set of user supplied flags to -tun 4 which always differs. So ansible will now think it needs to change something forever :). To solve this I need the default flags to compare to the output of 'status'. Regards, Patrik Lundin
Re: rcctl(8): Fetch default service flags
On Thu, Oct 09, 2014 at 11:51:50PM +0200, Patrik Lundin wrote: To solve this I need the default flags to compare to the output of 'status'. ... I guess another solution could be if 'status' only showed flags that differed from the default. Regards, Patrik Lundin