[SSSD] debbuging, how to turn off cache [SOLVED]

steve steve at steve-ss.com
Wed Apr 17 06:13:00 UTC 2013


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.

> 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.

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?

Cheers and thanks for your patience.
Steve




More information about the sssd-devel mailing list