docs(changelog): version v0.21.0 [citest skip] (#255)

This commit is contained in:
Sergei Petrosian 2023-09-13 15:42:01 +02:00 committed by GitHub
parent 0bc6d8f40b
commit 9a3aa1adb9
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 856 additions and 0 deletions

678
.README.html Normal file

File diff suppressed because one or more lines are too long

View file

@ -1,6 +1,127 @@
Changelog
=========
[v0.21.0] - 2023-09-12
--------------------
### New Features
- feat: manage ssh certificates (#252)
**Enhancement:**
- Deploy User CA on the system
- Configure principals (optional)
**Reason:**
This allows you to configure and manage the SSH server to authenticate via certificates.
Improves SSH authentication security: certificates have a validity period, unlike SSH keys.
More information on SSH certificates is available here: [Managing SSH Access at Scale with HashiCorp Vault](https://www.hashicorp.com/blog/managing-ssh-access-at-scale-with-hashicorp-vault).
**Result:**
All tests passed.
The related documentation is available and an example can be found in ```examples/example-use-certificates.yml```.
**Issue Tracker Tickets (Jira or BZ if any):** -
### Bug Fixes
- fix: Support inject_facts_as_vars = false (#244)
Enhancement:
Support `inject_facts_as_vars = false` in ansible.cfg.
The setting is considered safer because a compromised host cannot inject facts into variables.
Reason:
Minor security enhancement.
This setting is also recommended in some tuning guides like
https://docs.openstack.org/kolla-ansible/wallaby/user/ansible-tuning.html#fact-variable-injection
and issue mitigation guides:
https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#when-is-it-unsafe-to-bulk-set-task-arguments-from-a-variable
`ansible_facts` are used only with one name. Previously for example `ansible_facts['os_family']` was also used as `ansible_os_family`. This helps maintainability.
Result:
Support `inject_facts_as_vars = false`. If setting is `true`, situation still works as expected.
Also drop `ansible` prefix from local variables to avoid possible conflicts in namespace and avoid possible confusion.
Issue Tracker Tickets (Jira or BZ if any): -
- fix: Makes runtime dir relative (#249)
Enhancement:
Makes systemd RuntimeDirectory service file directive relative (`sshd` instead of `/run/sshd`).
Reason:
The [docs](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=) say it has to be relative.
Result:
The following error is gone from the journal:
```
/etc/systemd/system/backdoor-ssh.service:14: RuntimeDirectory= path is not valid, ignoring assignment: /run/custom-ssh
```
Waiting for the tests.
Issue Tracker Tickets (Jira or BZ if any): none
### Other Changes
- chore: fix markdown for heading in CHANGELOG (#242)
chore: add missing h2 heading for the 0.19.0 release
There was no markdown h2 heading for the 0.19.0 release which
broke the changelog parser in the collection release, causing
the changelog to look like
https://github.com/linux-system-roles/auto-maintenance/commit/0eade02032c55ffc008240ce44cfbee25276b51c#diff-ddbe2c1474f5ea331aef8eedcd595299f771578e4416a5f112ae69ed5a934bc0R4
Add the correct markdown
Signed-off-by: Rich Megginson <rmeggins@redhat.com>
- chore: drop support of Fedora 31, EOL 2020-11-24 (#243)
Enhancement:
-
Reason:
Fedora 31 is EOL.
Result:
Drop explicit support of EOL distro version. Less code to maintain.
- ci: Add markdownlint, test_converting_readme, and build_docs workflows (#247)
Enhancement: Add markdownlint, test_converting_readme, and build_docs GitHub workflows
Reason:
* markdownlint runs against markdown files to ensure correct syntax and avoid any issues with converting README.md to HTML
* test_converting_readme converts README.md > HTML and uploads this test artifact to ensure that conversion works fine
* build_docs converts README.md > HTML and pushes the result to the docs branch to publish dosc to GitHub pages site
* Rename commitlint.yml workflow into pr-title-lint for clarity
- ci: Ignore var-naming[no-role-prefix] ansible-lint rule that fails expectedly (#248)
Enhancement: Ignore var-naming[no-role-prefix] ansible-lint rule that fails expectedly
Reason: ansible-lint recently added a rule `var-naming[no-role-prefix]` that fails expectedly, this role generally uses `sshd` instead of `ansible_sshd`, and also vars from other roles e.g. `firewall_`.
Result: ansible-lint ignores this rule and passes.
- build(deps): bump actions/checkout from 3 to 4 (#254)
Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4.
[v0.20.0] - 2023-06-19
--------------------

57
contributing.md Normal file
View file

@ -0,0 +1,57 @@
# Contributing to ansible-sshd
## Where to start
The first place to go is [Contribute](https://linux-system-roles.github.io/contribute.html).
This has all of the common information that all role developers need:
* Role structure and layout
* Development tools - How to run tests and checks
* Ansible recommended practices
* Basic git and github information
* How to create git commits and submit pull requests
**Bugs and needed implementations** are listed on
[Github Issues](https://github.com/willshersystems/ansible-sshd/issues).
Issues labeled with
[**help wanted**](https://github.com/willshersystems/ansible-sshd/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22)
are likely to be suitable for new contributors!
**Code** is managed on [Github](https://github.com/willshersystems/ansible-sshd), using
[Pull Requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests).
## Creating a release
You must use automation to create releases consistently. The process of creating a release is the following:
1. Clone ansible-sshd, ensure that you have a remote for your fork configured and checkout a new branch to use for a release PR:
```bash
git clone git@github.com:willshersystems/ansible-sshd.git
git remote add <your_gh_username> git@github.com:<your_gh_username>/ansible-sshd.git
git checkout -b new-ver
```
2. Get the [linux-system-roles/auto-maintenance/role-make-version-changelog.sh](https://github.com/linux-system-roles/auto-maintenance/blob/main/role-make-version-changelog.sh) script:
```bash
wget https://raw.githubusercontent.com/linux-system-roles/auto-maintenance/main/role-make-version-changelog.sh
```
3. Run the [linux-system-roles/auto-maintenance/role-make-version-changelog.sh](https://github.com/linux-system-roles/auto-maintenance/blob/main/role-make-version-changelog.sh) script:
```bash
sh role-make-version-changelog.sh
```
This script creates updates CHANGELOG.md with a summary of pull requests added since the previous release and with automatically identified new version based on the PR types.
It also optionally updates .README.html with changes to README.md made since the previous release.
To learn more about available script options, see [role-make-version-changelog.sh documantation](https://github.com/linux-system-roles/auto-maintenance#role-make-version-changelogsh).
4. Verify that the script added a commit for new release by running `git log`.
5. Push the changes to your fork and create a PR.
These are all the manual steps that you must do to initiate a new release.
After the PR is reviewed and merged, i.e. after changes are made to CHANGELOG.md, the [changelog_to_tag.yml](https://github.com/willshersystems/ansible-sshd/blob/main/.github/workflows/changelog_to_tag.yml) workflow triggers and creates tag and release.