Hi Amish, > 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' -- Cheers, Ralph.
