[Bug]: service provider: OpenBSD: failure to start as flags are applied last

[klemensn]

Is this a critical security issue?

• This is not a security issue.

Describe the Bug

On OpenBSD, a service resource starts a service before configuring its flags, i.e. command line arguments to the daemon/program, which may cause it to fail and/or start with default flags instead of those configured.

Expected Behavior

Completion of service configuration before service startup.

Steps to Reproduce

1. Default service configuration after package installation: disabled, stopped, no flags.
   Thus, rcctl -f start openvpn would eventually execute /usr/local/bin/openvpn --daemon, which is guaranteed to fail (no parameters or config files).

$ grep openvpn /etc/rc.conf.local
$ rcctl get openvpn
openvpn_class=daemon
openvpn_execdir=
openvpn_flags=NO
openvpn_logger=
openvpn_rtable=0
openvpn_timeout=30
openvpn_user=root

2. Given that, the following resource should be equivalent to, in that order:

# rcctl enable openvpn
# rcctl set openvpn flags --config /etc/openvpn/server.conf
# rcctl start openvpn

$ cat service.pp
service { 'openvpn':
        flags  => '--config /etc/openvpn/server.conf',
        ensure => 'running',
        enable => true;
}

3. But the provider always starts the service first, which may fail if flags are required as in this case:

# puppet apply --debug service.pp
[...]
Debug: Executing: '/usr/sbin/rcctl check openvpn'
Debug: Executing: '/usr/sbin/rcctl get openvpn status'
Debug: Service[openvpn](provider=openbsd): Is disabled
Debug: Executing: '/usr/sbin/rcctl get openvpn flags'
Debug: Service[openvpn](provider=openbsd): Flags are: "NO"
Debug: Executing: '/usr/sbin/rcctl -f start openvpn'
Error: Could not start Service[openvpn]: Execution of '/usr/sbin/rcctl -f start openvpn' returned 1: openvpn(failed)
Error: /Stage[main]/Main/Service[openvpn]/ensure: change from 'stopped' to 'running' failed: Could not start Service[openvpn]: Execution of '/usr/sbin/rcctl -f start openvpn' returned 1: openvpn(failed)
Debug: Class[Main]: Resource is being skipped, unscheduling all events
[...]

(https://man.openbsd.org/rcctl.8#f is never needed if the service being started is already enabled.)

Environment

OpenVox 8.22.0 on OpenBSD/amd64 7.8-current

Additional Context

No response

Relevant log output

[jay7x]

systemd provider has similar issue.. e.g. if one would like to have a service that is running and enabled, then puppet/openvox would start it first and enable it after.