How to handle role requirements on other roles
by Richard Megginson
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
(Certificate README)[
https://github.com/linux-system-roles/certificate/blob/master/README.md]
* A RELP connection may need to open a port in the firewall, and could use
the
firewall role.
* A RELP connection may need to set SELinux attributes for a port, and
could use
the selinux role.
There are many more candidates which could use the Certificate role, the
Network
role, the Firewall role, etc. Any role that needs an X509 cert could use
the
certificate role. Any role that needs to open a port could use the
firewall and
selinux roles.
I have submitted a proposal at
https://github.com/linux-system-roles/linux-system-roles.github.io/pull/78
please comment
1 year, 11 months
Re: Best practice to revert/disable settings made by a role?
by Jörg Kastning
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
for example.
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
to me.
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.
Joerg
1 year, 11 months
Best practice to revert/disable settings made by a role?
by Jörg Kastning
Hi,
Currently my role pam_pwd [0] 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.
Joerg
[0] https://github.com/Tronde/pam_pwd
--
Jörg Kastning
E-Mail: joerg.kastning(a)uni-bielefeld.de
1 year, 11 months
How to handle roles with dependencies on collections?
by Richard Megginson
Some roles now have dependencies on collections, since with ansible-core
some of the plugins are now external to ansible and only available via
collections.
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
then use
ansible-galaxy collection install -r
/path/to/roles/linux-system-roles.storage/meta/collection-requirements.yml
Any ideas?
1 year, 11 months
