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?
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.
# getent --service=sss passwd oracle oracle:*:550:400:Oracle User:/home/oracle:/bin/bash
# getent --service=sss group asmadmin asmadmin:*:403:oracle
Any guidance, either to solve the problem else to obtain some useful diagnostics?
John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri 17 May 2013 05:09:17 PM EDT, 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?
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.
# getent --service=sss passwd oracle
oracle:*:550:400:Oracle User:/home/oracle:/bin/bash
# getent --service=sss group asmadmin
asmadmin:*:403:oracle
Any guidance, either to solve the problem else to obtain some useful diagnostics?
You haven't mentioned what version of SSSD you are using on which version of RHEL6. SSSD *should* be starting before udev on RHEL 6.4 (I'm not sure about 6.3 and older: I know it used to start too late and that was changed).
When you are doing those 'getent' calls, why are you using --service? If you omit that, are you getting different results? If so, it means that your /etc/nsswitch.conf is misconfigured.
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.
# 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?
# 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
-----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
On Mon, May 20, 2013 at 09:41:52AM -0400, Stephen Gallagher wrote:
-----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.
You're right about the problem (it could very well be it), but the fix landed in 6.4.
# 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
Ah, thank you. I usually order the parameters the other way around than the reporter :)
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?
Would udev accept numeric IDs to set the disk ownership?
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Bossert -
Stephen Gallagher