<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Meandering Life! &#187; sso</title>
	<atom:link href="http://manku.thimma.org/category/sso/feed/" rel="self" type="application/rss+xml" />
	<link>http://manku.thimma.org</link>
	<description>Hither, Thither ...</description>
	<lastBuildDate>Sat, 21 Jan 2012 06:07:03 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Debian/Ubuntu, NSS, LDAP and Udev</title>
		<link>http://manku.thimma.org/2007/07/debianubuntu-nss-ldap-and-udev/</link>
		<comments>http://manku.thimma.org/2007/07/debianubuntu-nss-ldap-and-udev/#comments</comments>
		<pubDate>Wed, 18 Jul 2007 02:57:27 +0000</pubDate>
		<dc:creator>shashi</dc:creator>
				<category><![CDATA[solution]]></category>
		<category><![CDATA[sso]]></category>
		<category><![CDATA[tech]]></category>
		<category><![CDATA[ubuntu]]></category>

		<guid isPermaLink="false">http://manku.thimma.org/?p=34</guid>
		<description><![CDATA[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 &#8230; <a href="http://manku.thimma.org/2007/07/debianubuntu-nss-ldap-and-udev/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>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.</p>
<p>During the initial days when we deployed and provisioned the system, I faced a problem in which the desktops wouldn’t boot.</p>
<p><span style="font-family: courier new;">udevd[1005]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…</span><br />
<span style="font-family: courier new;">udevd[1005]: nss_ldap: could not search LDAP server – Can’t contact LDAP server</span><br />
<span style="font-family: courier new;">udevd[1005]: lookup_group: error resolving group ‘nvram’: Illegal seek</span></p>
<p>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 <span style="font-family: courier new;">udevd</span> messages that still persisted.</p>
<p>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.</p>
<p><span style="font-family: courier new;">udevd[1005]: lookup_group: error resolving group ‘nvram’: Illegal seek<br />
</span><br />
Now, udev is set to create the device nvram at boot time and change group ownership of the device to nvram.<br />
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.</p>
<p>Hence the solution would be to give udev what it seeks; The group “nvram”!</p>
<p><span style="font-family: courier new;"># addgroup –system nvram</span></p>
<p>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.</p>
]]></content:encoded>
			<wfw:commentRss>http://manku.thimma.org/2007/07/debianubuntu-nss-ldap-and-udev/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

