On 04/17/2013 02:13 AM, steve wrote:
On 04/16/2013 08:53 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue 16 Apr 2013 12:34:53 PM EDT, steve wrote:
On 04/16/2013 05:39 PM, Jakub Hrozek wrote:
On Tue, Apr 16, 2013 at 05:21:35PM +0200, steve wrote:
On 04/16/2013 05:17 PM, Jakub Hrozek wrote:
On Tue, Apr 16, 2013 at 10:44:08AM +0200, steve wrote: > Hi Thanks for the syntax. It works perfectly now. Good > advice about the brutal technique too. > > I'm actually trying to debug a bash script which runs > getent passwd <user>. On Ubuntu it seems that getent is run > in a different process as it returns nothing. The same > script on openSUSE returns as expected. I know it's OT but > any ideas how to get output from getent in an Ubuntu bash > script? Cheers, Steve This really shouldn't matter, does getent on Ubuntu works fine without bash script?
Yes, it's fine outside the script. It's just that the script sets permissions on some files to the new user. We have to use his numeric gidNumber because his username is not available to use as such (as getent shows)
The only file getent should care about is nsswitch.conf
Does the script run as that particular user?
Also, I think Ubuntu runs a different shell, maybe that would make a difference in a script.
The other things to try would be stracing the getent to see if the getent actually reaches the SSSD and checking the sssd_nss logs to reference the lookup.
Hi everyone It seems to take time for sssd to pick up new objects. I added a sleep 10 before doing anything with the new user and could then use his username or, put another way, getent passwd username worked after the sleep.
10 seconds is fine as we don't add users that often but it would be nice if nss could pick it up a bit quicker.
This is only my second day with sssd and I would like to thank all the devs for a great project..
If you're too quick to request the user from before the LDAP server has filtered it out to all the replicas, you may be hitting SSSD's negative cache (which is 15s). The reason for this is to avoid repeated lookups against the LDAP server if you for example enter the wrong username into a script that makes multiple requests.
How are you creating the user, and how did you determine that 10 seconds was an appropriate sleep time?
Hi The actual code at that point in the script is:
echo "dn: cn=$1,cn=Users,$basedn changetype: modify add: objectClass objectClass: posixAccount
add: uidNumber uidNumber: $uid
add: gidNumber gidNumber: $gid
add:unixHomeDirectory unixHomeDirectory: $unixhome
add: loginShell loginShell: /bin/bash" > /tmp/$1 ldbmodify --url=$db $auth /tmp/$1
mkdir $unixhome sleep 10 ##This is the line where the wait is necessary chown -R "$1":"Domain Users" $unixhome
We add the rfc2307 attributes to the user $1. It takes 10 seconds for the user to become visible. We started at 2 seconds and tested increments of 2 until we saw the user emerge from the ldap at 10 seconds. With nslcd we do not have the wait. I think this must be something to do with the sssd cache.
Jakub, Stephen, does this hit SSSD negative cache? Is it fast cache? If this is a special system is there a way to reduce negative cache timeout? Is it:
entry_negative_timeout (integer) Specifies for how many seconds nss_sss should cache negative cache hits (that is, queries for invalid database entries, like nonexistent ones) before asking the back end again.
Default: 15
Depending on the server you use, the ldapmodify might return immediately while actually taking a few hundred milliseconds to finish flushing the transaction on the server-side. So if you are creating the user and processing it in the same script, you may be creating a race condition for yourself.
I'm new to all this stuff so I'm not sure what a race condition is but yes we are creating a user and processing him immediately afterwards. Maybe we can't do that wit sssd.
Yes this is a race.
The other problem we have is when we change e.g. the unixHomeDirectory for a user on the server. How do we tell the clients that something has changed? We can't go around all clients, login as root and issue a sssd_cache -u <user>! Any ideas?
It will be corrected next time user logs in I assume. So is this a problem? Is there a reason why the change should happen earlier than that?
Cheers and thanks for your patience. Steve
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel