Univention Bugzilla – Bug 30049
pam's (common-auth) univention-ucc-update-nss does not work for ssh sessions (UCC-remote)
Last modified: 2013-03-26 09:14:37 CET
If a user is created, he is not known in nss on ucc thin clients, but a "local" login with that user is possible (kerberos authentication). Then common-auth executes univention-ucc-update-nss and updates the passwd. But ssh does not allow logins with unknown usernames. For a remote session, the "unknown" user logs on to the thin client (local login -> common-auth -> univention-ucc-update-nss -> user is known on the thin client). Then the sessions script for the remote session tries to establish a ssh connection to the desktop server. But this ssh connection is not possible, as long as the user is unknown on the desktop server. On ucc desktop servers the nss information will be updated every five minutes. So you have to wait 5 minutes before you can log on with a new user to a UCC remote session.
I think this is a blocker. It means a user have to wait five minutes before he is able to login. Either we should push the nss data to the terminal server or the terminal server should pull the nss data when a user is created.
We will use the listener on the ucc terminal server. Changes: * db3 has been "cherry picked" to ucc (ucs 3.1) and build * univention-directory-listener has been "cherry picked" to ucc (ucs 3.1) and build. Several changes via patches: 01_python2.7.patch - python2.6 -> python2.7 02_gcc_errors.patch - fixes some "ucc build" errors 03_replace_runit_with_upstart.patch - runit has been removed, upstart (which also supports respawn) is used instead. 05_join_script.patch - replaced manual "join tests" with joinscripthelper.lib * univention-ucc-application-server: Two new listener modules, nss-passwd.py and nss.py. nss.py is (almost) identical to nss.py from ucs and nss-passwd.py is (almost) identical to ucc-nss-passwd.py from ucc-integration. nss.py calls ldap-group-to-file.py in the postrun if a group object has been changed. nss-passwd.py calls ldap-passwd-to-file.py in the postrun if a user object has been changed. ldap-group-to-file.py and ldap-passwd-to-file.py generating /var/lib/extrausers/passwd and group for nss-extrauser (ldapsearch for the corresponding object on ucs ldap server). In addition there are two cron jobs (default every 15 minutes). One for calling ldap-group-to-file.py and one for ldap-passwd-to-file.py. The behavior can be configured with the following ucr variables. nss/group/cachefile?yes \ nss/group/cachefile/invalidate_on_changes?yes \ nss/group/cachefile/invalidate_interval?"*/15 * * * *" \ nss/group/cachefile/check_member?yes \ nss/passwd/cachefile?yes \ nss/passwd/cachefile/invalidate_on_changes?yes \ nss/passwd/cachefile/invalidate_interval?"*/15 * * * *" \ ucc/nss/update=no On ucc terminal servers, the ssh-rsync nss update is disabled via ucc/nss/update=no. * univention-ucc-pam Added check for ucc/nss/update in univention-ucc-update-nss.
QA: * the listener has to be extensively tested * nss update (listener -> ldapsearch -> local group/passwd) on a ucc terminal server * nss update on ucc clients (univention-ucc-update-nss, ssh-rsync -> local group/passwd)
The package univention-ucc-application-server installs Univention Directory Listener as a dependency. The listerner is correctly installed using Upstart. With the adapted postinst the Listener is now correctly started during the initial installation. /usr/lib/univention-directory-listener/system/ldap_server.py is present, but doesn't cause any harm. This should be fixed in UCS, I filed Bug 30195 for that. ucc/nss/update is set to "no" after the installation of univention-ucc-application-server and correctly disables the download of passwd/group files in Skript /usr/sbin/univention-ucc-update-nss. When creating a user in the UMC it becomes available in /var/lib/extrausers/passwd after a few seconds and the user can login from his thin client right away. The start of the Listener through the Cron job also works correctly.
UCC 1.0 has been released: http://forum.univention.de/viewtopic.php?f=26&t=2417 http://forum.univention.de/viewtopic.php?f=54&t=2418 If this error occurs again, please use "Clone This Bug".