sys issueshttps://git.gsi.de/chef/cookbooks/sys/-/issues2022-02-08T15:04:35Zhttps://git.gsi.de/chef/cookbooks/sys/-/issues/27Flawed logic in sys::pam2022-02-08T15:04:35ZChristopher HuhnFlawed logic in sys::pamLooking at possible ways to make `sys::pam` configure `pam_krb5` without existing Kerberos keytab I stumbled upon [this code](recipes/pam.rb#L115-119).
It makes the strong assumption that a section with the hard-coded descriptive name *...Looking at possible ways to make `sys::pam` configure `pam_krb5` without existing Kerberos keytab I stumbled upon [this code](recipes/pam.rb#L115-119).
It makes the strong assumption that a section with the hard-coded descriptive name *Kerberos authentication* should not be enabled if a hard-coded file `/etc/krb5.keytab` does not exist.
This is strongly coupled to the GSI specific setup in our wrapper cookbook and does not belong here IMHO.
The logic should be deleted here and move to the wrapper cookbook.
In the big picture it may be completely superfluous:
1. The *Kerberos authentication* `pamupdate` stanza is defined with `Default = 'no'` in the wrapper cookbook and has to be turned on explicitly.
2. The configuration of the `pam_krb5` module *must not* break logins in case of misconfiguration or inoperable Kerberos infrastructure.m.pauschm.pauschhttps://git.gsi.de/chef/cookbooks/sys/-/issues/9Flawed logic in sys::krb52020-09-29T05:56:00ZChristopher HuhnFlawed logic in sys::krb5The [krb5 recipe](recipes/krb5.rb#L41-43) tries to deploy `/etc/krb5.keytab`.
Anyhow the [`sys_wallet` provider](providers/wallet.rb#L15) tries to acquire derived keytabs using this `/etc/krb5.keytab`.
Therefore this can never work.
R...The [krb5 recipe](recipes/krb5.rb#L41-43) tries to deploy `/etc/krb5.keytab`.
Anyhow the [`sys_wallet` provider](providers/wallet.rb#L15) tries to acquire derived keytabs using this `/etc/krb5.keytab`.
Therefore this can never work.
Remove the resource?m.pauschm.pausch