Univention Bugzilla – Bug 38511
univention-system-setup-boot calls pam-auth-update
Last modified: 2015-05-28 16:45:44 CEST
See Bug #38510 Comment #3: > I've also add a 'ucr commit' to the postinst. I'm not complete sure but I > think it is possible that univention-system-setup-boot is installed on a > productive server. In this case a package upgrade would break the PAM > configuration. If it is a problem during the package upgrade, we should also provide an erratum for UCS 4.0-1. It can also be changed in a generic way as an upgrade for 4.0-2 and 4.0-1. +++ This bug was initially created as a clone of Bug #38510 +++ I've installed a UCS 4.0-2 system with the Nagios service and I'm unable to authenticate as user Administrator. ==> /var/log/auth.log <== May 12 07:25:34 master681 apache2: pam_krb5(nagios:auth): pam_sm_authenticate: entry (nonull) May 12 07:25:34 master681 apache2: pam_krb5(nagios:auth): (user Administrator) attempting authentication as Administrator@DEADLOCK68.INTRANET May 12 07:25:34 master681 apache2: pam_krb5(nagios:auth): user Administrator authenticated as Administrator@DEADLOCK68.INTRANET May 12 07:25:34 master681 apache2: pam_krb5(nagios:auth): (user Administrator) temporarily storing credentials in /tmp/krb5cc_pam_cZ2Dzt May 12 07:25:34 master681 apache2: pam_krb5(nagios:auth): pam_sm_authenticate: exit (success) May 12 07:25:34 master681 unix_chkpwd[9149]: could not obtain user info (Administrator) ==> /var/log/apache2/error.log <== [Tue May 12 07:25:34 2015] [error] [client 10.205.1.178] PAM: user 'Administrator' - invalid account: Authentication failure
Hello Here I have the same scenario, and the occurrence is repeated identically. If you have some progress in the solution, I am grateful, Michael
Hello I succeeded in authenticating the nagios by modifying the /etc/pam.d/common-account files and /etc/pam.d/commom-password.
Merged r60642 and r60644 from 4.0-2 r60839 8.1.66-43.1000.887.201505221309 r60846 2015-05-22-univention-system-setup.yaml
The packages are only on omar, but not in the other testing repositories. root@master70:~# curl -s http://192.168.0.10/build2/ucs_4.0-0-errata4.0-1/all/ | grep -o '8.1.66-43.1000.887.201505221309' 8.1.66-43.1000.887.201505221309 8.1.66-43.1000.887.201505221309 8.1.66-43.1000.887.201505221309 8.1.66-43.1000.887.201505221309 8.1.66-43.1000.887.201505221309 8.1.66-43.1000.887.201505221309 8.1.66-43.1000.887.201505221309 8.1.66-43.1000.887.201505221309 root@master70:~# curl -s http://test.software-univention.de/4.0/maintained/component/4.0-1-errata/all/ | grep -o 'univention.*\?8.1.66-43.1000.887.201505221309' root@master70:~# curl -s http://univention-repository.knut.univention.de/4.0/maintained/component/4.0-1-errata/all/ | grep -o 'univention.*\?8.1.66-43.1000.887.201505221309' root@master70:~# curl -s http://apt.knut.univention.de/4.0/maintained/component/4.0-1-errata/all/ | grep -o 'univention.*\?8.1.66-43.1000.887.201505221309'
In doc/extended-docs/domain-4.0.xml we are suggesting a pam_auth_update without the UCR commit. Should we adapt this, too?
(In reply to Florian Best from comment #5) > In doc/extended-docs/domain-4.0.xml we are suggesting a pam_auth_update > without the UCR commit. Should we adapt this, too? No. That documentation is for integrating a non-UCS system into a UCS domain. UCR is not available on those systems anyway.
I tested the changes with "4.0-1-errata-test" on testing.univention.de. OK: postinst OK: postrm OK: YAML
<http://errata.univention.de/ucs/4.0/195.html>