Use ansible's service module instead of templating /etc/rc.conf.local

[ioc32]

This is more aligned with the ansible way of doing things. The service.py module provides an OpenBsdService class that uses rcctl(8) to handle system services.

The playbooks themselves have not been tested yet, but initial ad-hoc testing using ansible(1) suggests we could do without manually templating /etc/rc.conf.local. See below.

Since the service to be enabled might be running, or not, we restart it to ensure it picks up the new config, if any, after enabling it.

Since the service to be disabled might be running, or not, we stop it after disabling it.

$ fgrep pflog /etc/rc.conf.local $ $ ansible localhost -m service -a "name=pflogd enabled=yes args='-s 256' state=restarted" localhost | success >> { "changed": true, "enabled": true, "name": "pflogd", "state": "started" } $ fgrep pflog /etc/rc.conf.local pflogd_flags=-s 256 $ $ ansible localhost -m service -a "name=pflogd enabled=no state=stopped" localhost | success >> { "changed": true, "enabled": false, "name": "pflogd", "state": "stopped" } $ fgrep pflog /etc/rc.conf.local pflogd_flags=NO $

[ioc32]

While looking into merging this, we could also rethink how we store enabled and disabled services and see if it makes sense to store it in one single variable (later used by one single task instead of the current two).

[ioc32]

Something simpler like this and let the reboot bring services up?

daemons:
  -
    name: unbound
    args: -c /var/unbound/etc/unbound.conf
    enabled: yes
  -
    name: sndiod
    enabled: no

[saghul]

Let's test it before merging, but looks ok!

Now, about the custom daemons thing, I think it makes extensibility a bit harder. IMHO we should always start the daemons that OpenHRC provisions, let's call then "system daemons". Then we can have some "extra daemons" setting for the user to enable or disable whatever, in case he wants to run smtpd or whatever. The syntax proposed in https://github.com/ioc32/openhrc/pull/6#issuecomment-96451543 for this looks great for this.

[ioc32]

Like so? O:-)

[saghul]

LGTM sans one comment. Did you test it?

[ioc32]

I commented sndiod out and left it as a sample disabled daemon.

If we are stripping everything down as much as possible, should we leave sensorsd out? It is not enabled by default.

[saghul]

I commented sndiod out and left it as a sample disabled daemon.

But shouldn't that go into the (new) "extra_daemons" section? Also, the daemons in the main "daemons" section might not need the enabled flag, since we will always enable them, right?

If we are stripping everything down as much as possible, should we leave sensorsd out? It is not enabled by default.

I'd put it in the "extra daemons" section.

[ioc32]

This should do :-)

[saghul]

LGTM! :+1: