David C. Rankin wrote:
if you have services that rely on pam authentication, such as dovecot, etc.., you will find that your applications an no longer authenticate using pam until you install a specific pam service in /etc/pam.d for that application,
Although this change is probably not going to affect me but may be this should have been done in two releases.
It affected me and caused data loss. atd(8) couldn't run its jobs, bailed out with the job renamed to start `=', and then cleaned those up when it was re-started. No output from them was gathered. The jobs are often one-offs, hand-written as input to at(1), perhaps weeks or months ago. What they intended to do has been lost.
https://bugs.archlinux.org/task/61700 is the bug on package at needing an /etc/pam.d entry.
https://bbs.archlinux.org/viewtopic.php?pid=1831377 is a recent thread on this pambase change causing problems. Apparently, I hijacked it so it's now closed. But I'm pleased I did because others that arrive there from Google, like I did, will now have the trail I laid to follow.
I also ask there if a check should be in place on all packages that depend on pam to see if they provide /etc/pam.d/foo. If there's not too many exceptions then it may mop up the outstanding ones, and spot future new violations.
pactree -ld1 -r pam | sed 1d | xargs -rtn1 pkgfile -l |& egrep $'\t''/etc/pam.d/.|^pkgfile'