-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/20/2013 09:08 AM, Jakub Hrozek wrote:
On Fri, May 17, 2013 at 09:09:17PM +0000, John Bossert wrote:
Am fighting a battle with sssd/ldap and udev (RHEL6/Centos6).
I have a udev rule that sets disk ownership to oracle/asmadmin at boot. The user oracle and group asmadmin are registered in ldap.
Other (udev) forums suggest that udev is executing before networking is enabled, ergo ldap is unreachable and the disks remain owned by root/root. Hmmm, could sssd caching be a solution?
Yes, it should.
Following the various tutorials, I've enabled sssd, with "cache_credentials = TRUE" in sssd.conf, but I'm still seeing the same results. Either sssd caching isn't happening, or udev isn't making use of it.
cache_credentials only caches salted password hashes (which is off by default). Identity lookups are always cached and if there was at least one lookup prior to requesting the data offline, it should work even before network is up.
There might potentially be a race-condition where SSSD is reporting as started before the back-ends are responding, depending on which version of SSSD he's running. I think we fixed that in RHEL 6.3.
# getent --service=sss passwd oracle oracle:*:550:400:Oracle User:/home/oracle:/bin/bash
This seems strange to me, earlier you said that both oracle user and asmadmin group are in LDAP, yet you are able to resolve a the oracle user from passwd?
You misread this one. Reordering the arguments for clarity:
getent passwd -s sss oracle
# getent --service=sss group asmadmin asmadmin:*:403:oracle
Any guidance, either to solve the problem else to obtain some useful diagnostics?
I'm not quite certain what the problem is, can you describe it in more detail? Does udev not start?
John
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users