* Add new options from OpenSSH 9.9p1
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
* ci: Add CentOS10
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
* tests: Use LogLevel option for testing to avoid OpenSSH 9.9 bug
The OpenSSH 9.9p1 has a bug in parsing/printing the Compression option
so lets use different option for testing.
https://bugzilla.mindrot.org/show_bug.cgi?id=3759
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
---------
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Setting TMPDIR globally causes problems on some platforms.
Instead, set it at the `block` level and put the role
invocation inside the block.
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
* robustness: quote test backup/restore file names
This avoids issues if file names are not safepaths.
* security: use quote with command, shell and validate with variable
Skip quotation only if variable is checked.
Add test suit to excercise some quote use cases.
* robustness: fail if systemd.unit could have something in need of quote
Ensure systemd.unit contents is robust. This disables possibility to
have something that needs to be quoted there. But as ansible lacks
proper way to quote systemd unit files (see man systemd.syntax, rules
are not shell rules), it is better to fail such configs. If you are
trying to do that, you are doing it wrong anyway or have malicious
intent.
Also ensure similar issue with sysctl.conf.
Issue can be seen with `tests_hostkeys_unsafe_path.yml`, when adding
following to role params:
sshd_install_service: true
sshd_config_file: "{{ ansible_facts.env.TMPDIR }}/sshd.d/foo.conf"
sshd_binary: "{{ ansible_facts.env.TMPDIR }}/sshd"
__sshd_runtime_directory: "{{ ansible_facts.env.TMPDIR }}/run"
* tests: Quote also the source filename
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
* tests: Add more negative test cases
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
* tests: Skip the test with unsafe TMPDIR as it does not work on CentOS8
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
* Move the variable checks to separate file ...
... and explain better why this is problematic
Drops also the check for internal variables as the user should not
bother with these.
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
---------
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Co-authored-by: Markus Linnala <Markus.Linnala@knowit.fi>
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>
