rcctl: howto set flags for disabled services?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

rcctl: howto set flags for disabled services?

Harald Dunkel-3
Hi folks,

I have to keep the flags of dnsmasq and openvpn in sync on
several hosts, even though some hosts are just a hot standby,
not running the service per default.

Problem: The "flags" in rcctl is overloaded (probably for
historical reasons): If flags is set to "NO", then the service
is not run.

Would it be possible to put this "NO" somewhere else to avoid
a conflict?


Thanx in advance
Harri

Reply | Threaded
Open this post in threaded view
|

Re: rcctl: howto set flags for disabled services?

Harald Dunkel-3
On Wed, 18 Oct 2017 10:25:52 +0200
Harald Dunkel <[hidden email]> wrote:

> Hi folks,
>
> I have to keep the flags of dnsmasq and openvpn in sync on
> several hosts, even though some hosts are just a hot standby,
> not running the service per default.
>
> Problem: The "flags" in rcctl is overloaded (probably for
> historical reasons): If flags is set to "NO", then the service
> is not run.
>
> Would it be possible to put this "NO" somewhere else to avoid
> a conflict?
>

I understand that this is how it always worked in openBSD and
that changes might introduce unexpected side effects.

Do you think the request to distinguish between the "usual" command
line flags and the information whether a service should be started
at boot time is unreasonable?


Regards
Harri

Reply | Threaded
Open this post in threaded view
|

Re: rcctl: howto set flags for disabled services?

Sebastian Benoit-3
Harald Dunkel([hidden email]) on 2017.11.14 07:48:01 +0100:

> On Wed, 18 Oct 2017 10:25:52 +0200
> Harald Dunkel <[hidden email]> wrote:
>
> > Hi folks,
> >
> > I have to keep the flags of dnsmasq and openvpn in sync on
> > several hosts, even though some hosts are just a hot standby,
> > not running the service per default.
> >
> > Problem: The "flags" in rcctl is overloaded (probably for
> > historical reasons): If flags is set to "NO", then the service
> > is not run.
> >
> > Would it be possible to put this "NO" somewhere else to avoid
> > a conflict?
> >
>
> I understand that this is how it always worked in openBSD and
> that changes might introduce unexpected side effects.
>
> Do you think the request to distinguish between the "usual" command
> line flags and the information whether a service should be started
> at boot time is unreasonable?

Thats only one solution to your problem, but not the only one.

Possible solutions that change the way rc.conf variables work are difficult,
and i dont see why they are needed.

Going to a rc.conf.local format where you have

  daemon=YES|NO
  daemon_flags=-foo

does not help you much. Then the next problem becomes how you switch from NO
to YES.

So here is one way to store your flags and switch your configs
automatically, with no changes to how rc.d works:

* run ifstated (or something else) to monitor your state
* use a script thats run on promotion/demotion of a machine, that script runs rcctl(8) as
  needed
* on state change, have ifstated (or something else) run the script

Now you have the flags of your programms in the arguments
of "rcctl set <service> flags ...", all in one file that you can keep in
sync over multiple machines.

Reply | Threaded
Open this post in threaded view
|

Re: rcctl: howto set flags for disabled services?

Harald Dunkel-3
Hi Sebastian,

On 11/15/17 12:22 PM, Sebastian Benoit wrote:

> Harald Dunkel([hidden email]) on 2017.11.14 07:48:01 +0100:
>>
>> Do you think the request to distinguish between the "usual" command
>> line flags and the information whether a service should be started
>> at boot time is unreasonable?
>
> Thats only one solution to your problem, but not the only one.
>
> Possible solutions that change the way rc.conf variables work are difficult,
> and i dont see why they are needed.
>

They are needed to keep the command line flags separate from the
information whether a service should be run at all. Some tools like
openvpn and dnsmasq support a pretty complex set of command line
flags. If you disable such a service for the next reboot, then all
these flags are lost.

> Going to a rc.conf.local format where you have
>
>   daemon=YES|NO
>   daemon_flags=-foo
>
> does not help you much. Then the next problem becomes how you switch from NO
> to YES.
>

You could use "rcctl enable", as documented. My suggestion was to
change the rc script internals, keeping rcctl as it is. Did you
notice that rcctl(8) seems to imply that the flags can be set inde-
pendently from enable/disable? Sample session:

bash-4.4# rcctl get apmd flags
-C
bash-4.4# rcctl disable apmd
bash-4.4# rcctl enable apmd
bash-4.4# rcctl get apmd flags
bash-4.4#

Sorry to say, but this is not as documented. To me the lost command
line flags look like an unwanted side effect, i.e. a bug.

> So here is one way to store your flags and switch your configs
> automatically, with no changes to how rc.d works:
>
> * run ifstated (or something else) to monitor your state
> * use a script thats run on promotion/demotion of a machine, that script runs rcctl(8) as
>   needed
> * on state change, have ifstated (or something else) run the script
>
> Now you have the flags of your programms in the arguments
> of "rcctl set <service> flags ...", all in one file that you can keep in
> sync over multiple machines.
>

You mean I should write a wrapper for each service and put all
knowledge about the command line arguments into this script?
Actually I thought thats what rcctl is good for.

Please check https://www.openbsd.org/faq/faq10.html. It says

"Do not alter rc.conf(8) directly. Instead, use the rcctl(8)
utility to maintain the /etc/rc.conf.local file. This makes
future upgrades easier -- all the changes are in the one file
that isn't touched during upgrade."

Your suggestion is to put the command line flags somewhere
else. Wouldn't you agree that this is a conflict? Not to
mention that according to the quote rcctl has been provided
as a command line interface to the rc internals, which means
changes to the internals *are* possible.


Regards
Harri

Reply | Threaded
Open this post in threaded view
|

Re: rcctl: howto set flags for disabled services?

Stuart Henderson
On 2017/11/20 10:10, Harald Dunkel wrote:

> Hi Sebastian,
>
> On 11/15/17 12:22 PM, Sebastian Benoit wrote:
> > Harald Dunkel([hidden email]) on 2017.11.14 07:48:01 +0100:
> >>
> >> Do you think the request to distinguish between the "usual" command
> >> line flags and the information whether a service should be started
> >> at boot time is unreasonable?
> >
> > Thats only one solution to your problem, but not the only one.
> >
> > Possible solutions that change the way rc.conf variables work are difficult,
> > and i dont see why they are needed.
> >
>
> They are needed to keep the command line flags separate from the
> information whether a service should be run at all. Some tools like
> openvpn and dnsmasq support a pretty complex set of command line
> flags. If you disable such a service for the next reboot, then all
> these flags are lost.
>
> > Going to a rc.conf.local format where you have
> >
> >   daemon=YES|NO
> >   daemon_flags=-foo
> >
> > does not help you much. Then the next problem becomes how you switch from NO
> > to YES.
> >
>
> You could use "rcctl enable", as documented. My suggestion was to
> change the rc script internals, keeping rcctl as it is. Did you
> notice that rcctl(8) seems to imply that the flags can be set inde-
> pendently from enable/disable? Sample session:
>
> bash-4.4# rcctl get apmd flags
> -C
> bash-4.4# rcctl disable apmd
> bash-4.4# rcctl enable apmd
> bash-4.4# rcctl get apmd flags
> bash-4.4#
>
> Sorry to say, but this is not as documented. To me the lost command
> line flags look like an unwanted side effect, i.e. a bug.

There is a difference in the mechanism between daemons from packages
(where it would be _possible_ to enable/disable independent of storing
flags) and daemons from base (where it is not, unless changes are made
to rc.conf - and I don't see a good way to do this without a difficult
transition)..

And I don't think standard rcctl operations should work differently
depending on whether something is in base or is a package.

> > So here is one way to store your flags and switch your configs
> > automatically, with no changes to how rc.d works:
> >
> > * run ifstated (or something else) to monitor your state
> > * use a script thats run on promotion/demotion of a machine, that script runs rcctl(8) as
> >   needed
> > * on state change, have ifstated (or something else) run the script
> >
> > Now you have the flags of your programms in the arguments
> > of "rcctl set <service> flags ...", all in one file that you can keep in
> > sync over multiple machines.
> >
>
> You mean I should write a wrapper for each service and put all
> knowledge about the command line arguments into this script?
> Actually I thought thats what rcctl is good for.
>
> Please check https://www.openbsd.org/faq/faq10.html. It says
>
> "Do not alter rc.conf(8) directly. Instead, use the rcctl(8)
> utility to maintain the /etc/rc.conf.local file. This makes
> future upgrades easier -- all the changes are in the one file
> that isn't touched during upgrade."
>
> Your suggestion is to put the command line flags somewhere
> else. Wouldn't you agree that this is a conflict? Not to
> mention that according to the quote rcctl has been provided
> as a command line interface to the rc internals, which means
> changes to the internals *are* possible.

- it's simple to do what you want here really, just that you need
to do some setup without using rcctl. all you *actually* need to do
in this case is set openvpn_flags and dnsmasq_flags in rc.conf.local
(note, not rc.conf) and don't list them in pkg_scripts; then just
"rcctl start openvpn" and "rcctl stop openvpn" etc as needed.

- do you really need to stop and start these daemons anyway? can you
just run them even when the machine is not master?

Reply | Threaded
Open this post in threaded view
|

Re: rcctl: howto set flags for disabled services?

Harald Dunkel-3
Hi Stuart,

On 11/20/17 10:43 AM, Stuart Henderson wrote:
>
> There is a difference in the mechanism between daemons from packages
> (where it would be _possible_ to enable/disable independent of storing
> flags) and daemons from base (where it is not, unless changes are made
> to rc.conf - and I don't see a good way to do this without a difficult
> transition)..
>

Probably you are right. My assumption was that the decision whether or
not a service is run is made outside of the service's rc script.

> And I don't think standard rcctl operations should work differently
> depending on whether something is in base or is a package.
>

Agreed.

>
> - it's simple to do what you want here really, just that you need
> to do some setup without using rcctl. all you *actually* need to do
> in this case is set openvpn_flags and dnsmasq_flags in rc.conf.local
> (note, not rc.conf) and don't list them in pkg_scripts; then just
> "rcctl start openvpn" and "rcctl stop openvpn" etc as needed.
>

Understood. I will try.

> - do you really need to stop and start these daemons anyway? can you
> just run them even when the machine is not master?
>

openvpn was a bad example. AFAICS openvpn in openbsd doesn't provide a
rc script. I have to run 2 instances of openvpn in parallel, anyway
(IPv4 and IPv6).

My dnsmasq answers dhcp requests and sends out router advertisements
for IPv6. I would prefer to run dnsmasq only once on the carp master and
the right interfaces.


What about the sample session I had posted? Slightly modified:

        bash-4.4# rcctl get apmd flags
        -C
        bash-4.4# rcctl set apmd status off
        bash-4.4# rcctl set apmd status on
        bash-4.4# rcctl get apmd flags
        bash-4.4#

According to the documentation this is still not what you would expect.
I understand that there is a high risk on changing the internals of
rcctl and the rc scripts, but if the code is kept as it is, then it's
necessary to mention the side effect in the documentation.


Regards
Harri