We have a home brewn Single Sign-On implementation in our office which uses account information stored in OpenLDAP, exports home directories (NFS mounts) for clients using Automount. Our desktops run either Ubuntu Dapper or Debian Etch.
During the initial days when we deployed and provisioned the system, I faced a problem in which the desktops wouldn't boot.
udevd[1005]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
udevd[1005]: nss_ldap: could not search LDAP server - Can't contact LDAP server
udevd[1005]: lookup_group: error resolving group 'nvram': Illegal seek
I originally thought since udevd starts up before networking in rc2.d, it isn't able to seek the LDAP server and hence is causing some problem. So, I changed the priority of networking from S40 to S02 and that appeared to solve the problem. But there were those udevd messages that still persisted.
Cut, six months later when Ubuntu Feisty Fawn was released and we installed the same. We still used to get the same problem. But no amount of changing the priorities helped this time. This made me take a hard look at the logs and it was then that I observed the last line in each set of logs.
udevd[1005]: lookup_group: error resolving group 'nvram': Illegal seek
Now, udev is set to create the device nvram at boot time and change group ownership of the device to nvram.
But we've setup the NSS service to lookup LDAP (in /etc/nsswitch.conf) for passwd, group and shadow. So, everytime udev wanted the group called nvram, a search for the group nvram was done in the local /etc/groups file and not finding it there, an LDAP seek was done (wow, PAM!!!) and either it couldn't contact the LDAP server (because network isn't brought up yet) or when contacted (as in our Dapper case) it couldn't find the group called nvram in LDAP.
Hence the solution would be to give udev what it seeks; The group "nvram"!
# addgroup --system nvram
Once that is done. A reboot confirmed this indeed was the solution!!! The moral of the story is that people creating udevd rules should take into account non-existant users/groups. And create them if not found. Also, a framework for the whole SSO solution is missing in the open source world, which is why Micro$oft is able to shove it's products to corporates. Let me know if any effort exists which does try to address the situation.
No comments:
Post a Comment