On 2017/11/20 10:10, Harald Dunkel wrote: > Hi Sebastian, > > On 11/15/17 12:22 PM, Sebastian Benoit wrote: > > Harald Dunkel([email protected]) 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?
