On Mon, May 16, 2022 at 12:33 AM Jörg Kastning <
joerg.kastning(a)uni-bielefeld.de> wrote:
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.
As specified in
https://linux-system-roles.github.io/documentation/incremental_settings.html
one way would be to use
pam_pwd_faillock:
state: enabled
That seems overkill for this use case where the behavior is boolean -
either it is enabled, or it isn't, so perhaps something like
pam_pwd_faillock: true|false
makes more sense here.
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.
Another use case is
As a system administrator, I want to periodically run the pam_pwd role with
my settings to see if there has been any configuration drift (e.g. someone
has logged into the machine and manually edited one of the pam
configuration files, or used something like puppet/chef). I want
* to see if something was changed
* reset the value back to my desired value
* do not change anything if there have been no changes.
This is the "system drift scan and reset" use case.
That is, run the pam_pwd role with my given values - if something was
unexpectedly changed on the system, change it back, and report what was
changed. If nothing was changed, do not change anything, and report no
changes.
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?
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
_______________________________________________
systemroles mailing list -- systemroles(a)lists.fedorahosted.org
To unsubscribe send an email to systemroles-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/systemroles@lists.fedorahost...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure