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