not sure if it's a bug honestly, maybe looking for a trick whenever pambase gets updated, I have to manually restart cronie which I fail to do until I realize cron didn't do what I expected :) Reproducible: Always Steps to Reproduce: update pambase watch failure of cron in /var/log/messages I'm not aware how, but I guess there should be some signal/dependencies forcing cronie service to restart...
Any more information in syslog, and emerge -pvO pam pambase please.
messages: Oct 15 07:30:01 big crond[9707]: PAM unable to dlopen(/lib64/security/pam_faillock.so): /lib64/libpam.so.0: version `LIBPAM_MODUTIL_1.4.1' not found (required by /lib64/security/pam_faillock.so) Oct 15 07:30:01 big crond[9707]: PAM adding faulty module: /lib64/security/pam_faillock.so Oct 15 07:30:01 big crond[9707]: (root) PAM ERROR (Module is unknown) Oct 15 07:30:01 big crond[9707]: (root) FAILED to authorize user with PAM (Module is unknown) big /etc/init.d # emerge -pvO cronie pam pambase These are the packages that would be merged, in order: [ebuild R ] sys-process/cronie-1.5.5::gentoo USE="anacron inotify pam (-selinux)" 0 KiB [ebuild R ] sys-libs/pam-1.4.0_p20200829::gentoo USE="berkdb filecaps pie (split-usr) -audit -debug -nis (-selinux)" ABI_X86="(64) -32 (-x32)" 0 KiB [ebuild R ] sys-auth/pambase-20201010::gentoo USE="elogind nullok passwdqc sha512 -caps -debug -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -pwhistory -pwquality -securetty (-selinux) -systemd" 0 KiB unaltered from ebuilds :)
(In reply to David Coornaert from comment #2) > messages: > > Oct 15 07:30:01 big crond[9707]: PAM unable to > dlopen(/lib64/security/pam_faillock.so): /lib64/libpam.so.0: version > `LIBPAM_MODUTIL_1.4.1' not found (required by > /lib64/security/pam_faillock.so) > Oct 15 07:30:01 big crond[9707]: PAM adding faulty module: > /lib64/security/pam_faillock.so > Oct 15 07:30:01 big crond[9707]: (root) PAM ERROR (Module is unknown) > Oct 15 07:30:01 big crond[9707]: (root) FAILED to authorize user with PAM > (Module is unknown) > > I suspect you need to run dispatch-conf or etc-update? faillock is gone: https://www.gentoo.org/support/news-items/2020-06-23-upgrade-to-sys-libs_pam-1_4_0.html.
Not our bug as seen from logs. Please follow sam's advice.
I just checked ; nothing in etc-update (well excepted keyboard mapping and apache stuff )
big /etc/init.d # etc-update Scanning Configuration files... The following is the list of files which need updating, each configuration file is followed by a list of possible replacement files. 1) /etc/apache2/httpd.conf (1) 2) /etc/apache2/vhosts.d/default_vhost.include (1) 3) /etc/conf.d/apache2 (1) 4) /etc/conf.d/keymaps (1) 5) /etc/conf.d/xdm (1) 6) /etc/mysql/mysql.d/50-distro-server.cnf (1) 7) /etc/ssh/ssh_config (1) 8) /etc/ssh/sshd_config (1)
(In reply to David Coornaert from comment #5) > I just checked ; > nothing in etc-update (well excepted keyboard mapping and apache stuff ) well, it is not mandatory etc-config stuff, but something is definitely broken on yyour side, because pam_faillock is shipped alongside with current pam.
You only need to take action if: * you made manual changes to the PAM stack, or * you use FEATURES="-config-protect-if-modified" option allright, Not my case the thing will work till next pambase updates... Ok I must have something wrong locally, my fault , *bow* Any clue ?
(In reply to David Coornaert from comment #8) > You only need to take action if: > * you made manual changes to the PAM stack, or > * you use FEATURES="-config-protect-if-modified" option > > > allright, Not my case > > the thing will work till next pambase updates... > Ok I must have something wrong locally, my fault , *bow* > > > Any clue ? Try rebuilding pam and pambase.
Ok I'll wait one day to check which users' crontab fails exactly the I'll rebuild pam stuff I'll let you know here TY
(In reply to David Coornaert from comment #10) > Ok I'll wait one day to check which users' crontab fails > exactly > the I'll rebuild pam stuff > I'll let you know here > > TY I found https://forums.gentoo.org/viewtopic-t-516677.html and it makes complete sense when you recall the pkg_postinst message in pam. Try restarting your cron daemon.
