Many of our roles need to use the functionality provided by another role.
An example for the Logging role:
* When new certs need to be generated with deploying the logging system,
integration with the certificate role. See also
* A RELP connection may need to open a port in the firewall, and could use
* A RELP connection may need to set SELinux attributes for a port, and
the selinux role.
There are many more candidates which could use the Certificate role, the
role, the Firewall role, etc. Any role that needs an X509 cert could use
certificate role. Any role that needs to open a port could use the
I have submitted a proposal at
Am 16.05.2022 um 19:16 schrieb Richard Megginson:
> Another consideration: what if you want to remove all of your previous
> settings and restore the pam configuration to the system defaults?
> As a system administrator, I am inheriting a set of heterogeneous machines,
> and I don't know the state of pam password settings on those machines, and
> I need them all to be the same.
> In that use case, it would be nice to be able to revert the settings to the
> system default, then apply the given settings, to ensure that all machines
> are configured identically.
I've spent some time thinking about how to do that. And I find it pretty
hard to accomplish. The PAM stack is very complex. My role only
configures a small part of it (pam_pwquality and pam_faillock). Would I
only restore the settings from these two to the systems default settings
it could lead to a misunderstanding when speaking of system default.
Other settings could have been changed I don't be aware of.
Probably it would be best if the role supports all possible PAM options,
like the system role for sshd. But I have to admit that's beyond my
capabilities. I would like to focus on the aspect of password quality. I
even think about removing the pam_faillock functionality entirely,
because it has nothing to do with the password quality and I couldn't
answer the question why would I prefer pam_faillock over pam_faildelay
Well, currently I'm unsure how to proceed.
> The last part is more complicated than it seems. One simple way would be
> to replace all config files with the system defaults, then apply your
> changes, which would ensure that the system is in the exact end state you
> desire. However, the role would report changes always and would not be
> idempotent. What you really want to know is - What will be the end state
> of the system if I apply these changes, and is that state the same state
> that currently exists?
As I wrote above, I don't control the whole PAM configuration, only a
small well defined part of it. So it's true in my case I won't know the
exact state of the PAM stack. Maybe that's an unusual case where I only
control defined aspects of a systems configuration while other 'roots'
have control about all config options instead those which are delegated
I understand that there are a lot more details I have to think about
when it comes to using this outside of my own environment. I'll have to
think about it to figure out if I have the time and ability to do that.
Currently my role pam_pwd  enables pam_faillock by default. I'm going
to make this configurable by the user. But it has come to my mind that
once pam_faillock was enabled one might like to switch it back and
disable it again by using the same role. I'm not sure what's the best
way to do that and would like to get your opinions on this.
I've thought about using a variable (bool) to enable/disable
pam_faillock and set the state option of the corresponding tasks either
to present or absent.
In cases where I have to use the command module, due to the lack of
other options, I would use a conditional to decide whether the task
should run or not.
What do you think about it? Do you get what I mean? Is my approach OK or
is there a better way of doing it?
Looking forward to reading your replies.
We'll try to get this into CI as soon as possible after it is officially
released. We will likely replace the current ansible-core 2.12 environment
---------- Forwarded message ---------
From: Matt Martz <matt(a)sivel.net>
Date: Tue, May 10, 2022 at 1:57 PM
Subject: [ansible-devel] ansible-core 2.13 schedule change
To: <ansible-announce(a)googlegroups.com>, Ansible Development <
Due to unexpected scheduling conflicts with the ansible-core 2.13 general
availability release, we will be releasing 2.13.0 on May 16, 2022.
This date is one week earlier than the previously communicated date of May
The roadmap document has been updated to reflect this change:
You received this message because you are subscribed to the Google Groups
"Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ansible-devel+unsubscribe(a)googlegroups.com.
To view this discussion on the web visit
Some roles now have dependencies on collections, since with ansible-core
some of the plugins are now external to ansible and only available via
for background see https://github.com/linux-system-roles/storage/issues/258
The Ansible team regards this as a "not my problem" issue.
I was thinking of adding a non-standard file like
`meta/collection-requirements.yml` to the roles that need it - at least we
could document that users will have to first do
ansible-galaxy role install linux-system-roles.storage
ansible-galaxy collection install -r