Add support for OpenRC runlevels

[berney]

Checklist

• [x] make test-all (UNIX) passes. CI will also test this
• [x] unit and/or integration tests are included (if applicable)
• [x] documentation is changed or added (if applicable)

Description of change

Continuation of https://github.com/aelsabbahy/goss/pull/371

Alpine Linux (and Gentoo) use OpenRC. Goss was hard-coded to expect a service to be at the sysinit runlevel, if the service was at a different runlevel the service check would erroneously fail.

Behaviour prior to this PR: -

alpine38:/tmp# service sshd status
 * status: started

alpine38:/tmp# ./goss-0.3.6-linux-amd64 -g /tmp/goss/goss.yaml v
..........F.

Failures/Skipped:

Service: sshd: enabled:
Expected
    <bool>: false
to equal
    <bool>: true

Total Duration: 0.012s
Count: 12, Failed: 1, Skipped: 0

With this PR the service block now supports an optional runlevel attribute, which defaults to sysinit if omitted maintaining the old behaviour.

Now it is possible to install openssh-server in Alpine linux and properly check the service is running with the following config: -

service:
  sshd:
    enabled: true
    running: true
    runlevel: default

Additionally you might have:

port:
  tcp:22:
    listening: true
    ip:
    - 0.0.0.0
  tcp6:22:
    listening: true
    ip:
    - '::'
user:
  sshd:
    exists: true
    groups:
    - sshd
    home: /dev/null
    shell: /sbin/nologin
group:
  sshd:
    exists: true
process:
  sshd:
    running: true

Post this PR:

alpine38:/tmp# ~/goss-berne2d -g /tmp/goss/goss.yaml v
runlevel is default
............

Total Duration: 0.012s
Count: 12, Failed: 0, Skipped: 0

[aelsabbahy]

Looks good. Wonder if it makes more sense to allow the user to test for different runlevels.

Let me know what you think of this approach: https://github.com/berney/goss/compare/f-openrc-runlevels...aelsabbahy:f-openrc-runlevels_changes?expand=1

One possible enhancement is for enabled to match against the current runlevel. The example code I have above enabled will be true if any level is enabled.

[berney]

I like that you made all the other attributes, enabled and running, optional. I like that you changed it to many runlevels (a list), as this better reflects the underlying init systems, where a single service can belong to many runlevels.

The Travis CI build failure on your changes branch seems to be due to a temporal issue. On builds on my local system today, it seems gliderlabs.com is down.

[aelsabbahy]

Awesome, if there are no objections, change requests on your end. I'll update this PR with the changes above.

As for the CI issues, I've resolved all of that in a different PR. So there might be a little bit of a merge/update-pr/merge type dance.

[berney]

No objections from me. Please go ahead and update this PR, merging your changes. If I need to do anything let me know. If there's problems with updating/merging PRs or something and you need to open a new PR, no problem. I'll be happy if this change lands one way or another.

[berney]

I like the current behaviour in your changes where enabled will return true if any run level is enabled - I prefer this behaviour rather than checking if the current runlevel matches an enabled level. I think the writer of a goss file should check the current runlevel as a separate check (like command who -r) if that matters to them. Current behaviour someone can check just enabled to just check that a service is enabled for any runlevel (even if its not the current runlevel), or they can specify the runlevels to check the lists match.

[aelsabbahy]

Getting really close on this one.. it'll be merged into the v4 branch since it's a breaking change (enabled).

Hoping to have this released by the end of the month or early next month with v4

[aelsabbahy]

closed by #668, will be in v4

[aelsabbahy]

Many thanks for your contribution. Hoping to have this released soon!