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
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
