According to the Ansible team, support for listing platforms in
role `meta/main.yml` files is being removed.
Instead, they recommend using `galaxy_tags`
https://github.com/ansible/ansible/blob/stable-2.17/changelogs/CHANGELOG-v2.17.rst
"Remove the galaxy_info field platforms from the role templates"
https://github.com/ansible/ansible/issues/82453
For each version listed under `platforms.EL` - add a tag like `elN`.
Q: Why not use a delimiter between the platform and the version e.g. `el-10`?
This is not allowed by ansible-lint:
```
meta-no-tags: Tags must contain lowercase letters and digits only., invalid: 'el-10'
meta/main.yml:1
```
So we cannot use uppercase letters either.
Q: Why not use our own meta/main.yml field?
No other fields are allowed by ansible-lint:
```
syntax-check[specific]: 'myfield' is not a valid attribute for a RoleMetadata
```
Q: Why not use some other field?
There are no other applicable or suitable fields.
Q: What happens when we want to support versions like `N.M`?
Use the word "dot" instead of "." e.g. `el10dot3`.
Similarly - use "dash" instead of "-".
We do not need tags such as `fedoraall`.
The `fedora` tag implies that the role works on all supported versions of fedora.
Otherwise, use tags such as `fedora40` if the role only supports specific versions.
In addition - for roles that have different variable files for EL9, create
the corresponding EL10 files, and update the variables for EL10.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
* feat: Add support for Ubuntu Nobel/24.04 LTS
* fix: Add missing PrintMotd to Ubuntu 22.04
* fix(tests): Various linting fixes
---------
Co-authored-by: Jakub Jelen <jjelen@redhat.com>
Some of our test suites require sshd2 to be completely stopped
and removed, or subsequent tests will fail.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
The option was introduced in 6bb0d7b456
without documentation and intended use. The recent change
f6ae2094fe propagated this option to the
generated service files, which is resulting in unexpected results, when
a user decided to set only `sshd_config_file` for the second sshd
service causing the service file points to the system-wide
configuration file.
This is an attempt to fix this by introducing some heuristics to guess
if the user wants to set up second drop-in directory (ending with .d)
or create a standalone configuration file.
Fixes: #280
* README: Fix double-the in documentation
* README: Consistently referer to the role name and not to repository name
* README: Improve wording
* Fix more typos
* ci: Add GH action to check for spelling mistakes
Specifics:
* Debian 12 has no longer the instantiated service using inet, see the
following commit:
0dc73888bb
* I am not matching the Description tag verbosely as I do not find it
crucial for functionality.
* We generate additional -f switch to the sshd CLI pointing go the main
sshd config we manage
* The Before=sshd.service in the socket is not generated as I find it
unnecessary when we conflict the service.
* Recent Ubuntu versions have RuntimeDirectoryPreserve option, which I
set for all Ubuntu/Debian as it should not hurt.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
The old ansible-community ansible-lint is deprecated. There is a
new ansible-lint github action.
The latest Ansible repo gating tests run ansible-lint against
the collection format instead of against individual roles.
We have to convert the role to collection format before running
ansible-test.
This also requires tox-lsr 3.2.1
Role developers can run this locally using
`tox -e collection,ansible-lint-collection`
See https://github.com/linux-system-roles/tox-lsr/pull/125
Fix ansible-lint and ansible-test issues reported by the
latest 2.16 versions.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
Feature: Allow running and testing the role with ostree managed nodes.
Reason: We have users who want to use the role to manage ostree
systems.
Result: Users can use the role to manage ostree managed nodes.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
I noticed some test failures in tests that check ownership/permissions
of config files. The tests were recently changed to reuse the same
VM, so I suspect config files were not being backed up/restored with
the correct file attributes. Use `cp -a` to preserve all file
attributes.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
