Hi,
even though RHEL-6.4 is still brewing, I think there might be some interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.
So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot: http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/
The NVR of these test packages will be lower than those in 6.4 to keep the upgrade path clean. The only missing functionality is the PAC responder, which means this SSSD version won't be able to work with an AD domain that is in a trust relationship with an IPA 3.x domain. I had to disable the PAC responder as it requires Kerberos 1.10.
Because some new functionality required tweaking the SELinux policy, you will encounter AVC denials when the new fast cache is accessed. That said, my quick smoke testing went fine and we will be glad to hear test results or bug reports.
Using the repository comes with a warning - this is NOT an official Red Hat supported repository. The packages have NOT gone through formal QA. If it breaks your RHEL-6.3 installation, you get to keep the pieces.
This is the repo configuration I used: -------------------------- [sssd-1.9-RHEL6.3] name=SSSD 1.9.x built for latest stable RHEL baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/$basearch/ enabled=1 skip_if_unavailable=1 gpgcheck=0
[sssd-1.9-RHEL6.3-source] name=SSSD 1.9.x built for latest stable RHEL - Source baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/SRPMS enabled=0 skip_if_unavailable=1 gpgcheck=0 --------------------------
Happy testing!
Jakub Hrozek jhrozek@redhat.com writes:
even though RHEL-6.4 is still brewing, I think there might be some interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.
So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot: http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/
The NVR of these test packages will be lower than those in 6.4 to keep the upgrade path clean. The only missing functionality is the PAC responder, which means this SSSD version won't be able to work with an AD domain that is in a trust relationship with an IPA 3.x domain. I had to disable the PAC responder as it requires Kerberos 1.10.
Because some new functionality required tweaking the SELinux policy, you will encounter AVC denials when the new fast cache is accessed. That said, my quick smoke testing went fine and we will be glad to hear test results or bug reports.
Hello Jakub and the SSSD team,
My interest in the 1.9 version is first and foremost the performance enhancements related to large groups. At our site, we have lots of fairly large file groups and a few enormous ones (which we're getting rid of but it takes some time). I installed sssd-1.9 from your test repo on a rhel6.3 VM, ran a couple of quick tests and compared it to an identical VM with the stock sssd-1.8 from rhel6.3. The results are astonishing:
Test 1: time getent group <group with 7k members>
sssd-1.9.2-1.el6_3.x86_64: 0m1.087s sssd-1.8.0-32.el6.x86_64: 0m5.937s
Test 2: time id <member of several large groups>
sssd-1.9.2-1.el6_3.x86_64: 0m9.669s sssd-1.8.0-32.el6.x86_64: 1m28.578s
Both tests were done without a preexisting cache, i.e. 'service sssd stop; rm /var/lib/sss/db/*; service sssd start', then run test. We're using plain LDAP (rfc3207) as id provider and auth provider.
This is a remarkable performance boost, and I can't wait to see an official sssd-1.9 package in rhel6. Thanks for all your hard work and have a nice weekend! :)
PS. Will we see sssd-1.9 in Fedora 17?
Cheers,
On Fri, Oct 19, 2012 at 08:48:56PM +0200, Trond Hasle Amundsen wrote:
Jakub Hrozek jhrozek@redhat.com writes:
even though RHEL-6.4 is still brewing, I think there might be some interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.
So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot: http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/
The NVR of these test packages will be lower than those in 6.4 to keep the upgrade path clean. The only missing functionality is the PAC responder, which means this SSSD version won't be able to work with an AD domain that is in a trust relationship with an IPA 3.x domain. I had to disable the PAC responder as it requires Kerberos 1.10.
Because some new functionality required tweaking the SELinux policy, you will encounter AVC denials when the new fast cache is accessed. That said, my quick smoke testing went fine and we will be glad to hear test results or bug reports.
Hello Jakub and the SSSD team,
My interest in the 1.9 version is first and foremost the performance enhancements related to large groups. At our site, we have lots of fairly large file groups and a few enormous ones (which we're getting rid of but it takes some time). I installed sssd-1.9 from your test repo on a rhel6.3 VM, ran a couple of quick tests and compared it to an identical VM with the stock sssd-1.8 from rhel6.3. The results are astonishing:
Test 1: time getent group <group with 7k members>
sssd-1.9.2-1.el6_3.x86_64: 0m1.087s sssd-1.8.0-32.el6.x86_64: 0m5.937s
Test 2: time id <member of several large groups>
sssd-1.9.2-1.el6_3.x86_64: 0m9.669s sssd-1.8.0-32.el6.x86_64: 1m28.578s
Both tests were done without a preexisting cache, i.e. 'service sssd stop; rm /var/lib/sss/db/*; service sssd start', then run test. We're using plain LDAP (rfc3207) as id provider and auth provider.
This is a remarkable performance boost, and I can't wait to see an official sssd-1.9 package in rhel6. Thanks for all your hard work and have a nice weekend! :)
This is great to hear, Trond. Thank you for taking the time to test the pre-release packages. I'm glad the performance has improved for you! I believe that the in-memory fast cache would provide even bigger boost for groups and users that are being accessed regularly.
PS. Will we see sssd-1.9 in Fedora 17?
Yes, as a matter of fact it might be the time to put 1.9 into updates-testing.
Ok, I gave it a try (with an AD provider) and here are the bugs I have found so far:
0. My configuration: id_provider = ad auth_provider = ad chpass_provider = ad cache_credentials = True ldap_id_mapping = False # ldap_sasl_authid = LOGINA$@DUBLIN.AD.S3GROUP.COM
1. Upgrade db database from the 1.8 versions (aka RHEL 6U3) does not work. SSSD won't start (dies silently). I had to rm /var/lib/sss/db/* to make it working. 2. sssd won't work when I specify correct ldap_sasl_authid (see the example above). This is bad as I might have my krb5.keytab cluttered with other (possibly not working) keys so I would like to keep the possibility of specifying the ldap_sasl_authid manually. 3. This is a show stopper for me. I can not disable ID mapping as the example above does not work for me:
Desired results: Only users and groups w/ RFC2307 attributes are seen, NO id mapping is performed. Achieved results: Users and groups who have defined RFC2307 attributes are displayed fine (RFC2307 attributes honored), but also users & groups with no RFC2307 attributes are displayed (RFC2307 attributes computed by sssd)
Ondrej
On 10/18/2012 11:23 AM, Jakub Hrozek wrote:
Hi,
even though RHEL-6.4 is still brewing, I think there might be some interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.
So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot: http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/
The NVR of these test packages will be lower than those in 6.4 to keep the upgrade path clean. The only missing functionality is the PAC responder, which means this SSSD version won't be able to work with an AD domain that is in a trust relationship with an IPA 3.x domain. I had to disable the PAC responder as it requires Kerberos 1.10.
Because some new functionality required tweaking the SELinux policy, you will encounter AVC denials when the new fast cache is accessed. That said, my quick smoke testing went fine and we will be glad to hear test results or bug reports.
Using the repository comes with a warning - this is NOT an official Red Hat supported repository. The packages have NOT gone through formal QA. If it breaks your RHEL-6.3 installation, you get to keep the pieces.
This is the repo configuration I used:
[sssd-1.9-RHEL6.3] name=SSSD 1.9.x built for latest stable RHEL baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/$basearch/ enabled=1 skip_if_unavailable=1 gpgcheck=0
[sssd-1.9-RHEL6.3-source] name=SSSD 1.9.x built for latest stable RHEL - Source baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/SRPMS enabled=0 skip_if_unavailable=1 gpgcheck=0
Happy testing! _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Nov 08, 2012 at 06:17:40PM +0100, Ondrej Valousek wrote:
Ok, I gave it a try (with an AD provider) and here are the bugs I have found so far:
- My configuration:
id_provider = ad auth_provider = ad chpass_provider = ad cache_credentials = True ldap_id_mapping = False # ldap_sasl_authid = LOGINA$@DUBLIN.AD.S3GROUP.COM
- Upgrade db database from the 1.8 versions (aka RHEL 6U3) does not
work. SSSD won't start (dies silently). I had to rm /var/lib/sss/db/* to make it working.
This is pretty bad. Do you still have the old database somewhere or the possibility of generating it again with old packages? We haven't seen this bug so far in our testing, but apparently it's out there..
- sssd won't work when I specify correct ldap_sasl_authid (see the
example above). This is bad as I might have my krb5.keytab cluttered with other (possibly not working) keys so I would like to keep the possibility of specifying the ldap_sasl_authid manually.
So this is authid that was working with the plain ldap provider but dosn't work with ad provider? Can you share logs?
Have you tried if using this authid works even with 1.9 with the ldap provider?
- This is a show stopper for me. I can not disable ID mapping as the example above does not work for me:
Desired results: Only users and groups w/ RFC2307 attributes are seen, NO id mapping is performed. Achieved results: Users and groups who have defined RFC2307 attributes are displayed fine (RFC2307 attributes honored), but also users & groups with no RFC2307 attributes are displayed (RFC2307 attributes computed by sssd)
I suspect that this issue might be fixed in the latest builds. I was planning to upgrade this preview repo to 1.9.3 when it becomes ready, but it wouldn't be too hard to include the fixes we have so far so you could test.
Ondrej
Thank you very much for testing.
This is pretty bad. Do you still have the old database somewhere or the possibility of generating it again with old packages? We haven't seen this bug so far in our testing, but apparently it's out there..
No, unfortunately I do not :-(. But I will try to replicate the problem and if I manage, I will send it to you.
So this is authid that was working with the plain ldap provider but dosn't work with ad provider? Can you share logs?
Have you tried if using this authid works even with 1.9 with the ldap provider?
Exactly, this authid worked fine with just ldap provider. I will send the logs in private.
I suspect that this issue might be fixed in the latest builds. I was planning to upgrade this preview repo to 1.9.3 when it becomes ready, but it wouldn't be too hard to include the fixes we have so far so you could test.
Please do include those and let me know. This is a crucial functionality for me. Thanks!
Ondrej
On Thu, 2012-11-08 at 18:32 +0100, Ondrej Valousek wrote:
This is pretty bad. Do you still have the old database somewhere or the possibility of generating it again with old packages? We haven't seen this bug so far in our testing, but apparently it's out there..
No, unfortunately I do not :-(. But I will try to replicate the problem and if I manage, I will send it to you.
Do you have any logs perchance ? Might be enough to figure out something.
Simo.
On Fri, Nov 09, 2012 at 08:41:57AM +0100, Ondrej Valousek wrote:
Do you have any logs perchance ?
Have only this: (Thu Nov 8 16:10:57 2012) [sssd] [sysdb_upgrade_10] (0x0020): UPGRADING DB TO VERSION 0.11 (Thu Nov 8 16:10:57 2012) [sssd] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute]
Ondrej
Thank you, that at least tells us which of the three DB upgrades we did during the 1.9 development broke. For the record, the changes were:
* 0.11 - fake users to ghost users * 0.12 - different schema for autofs entries * 0.13 - introduce sshKnownHostsExpire and index them
I know you are using AD, so the best way for us to try and replicate the problem would be to try upgrading different nested group structures. Is there anything else peculiar about your setup? Groups with no users, non-posix (=lacking GID) groups etc?
Of course, if you could reproduce the problem again and send us more verbose logs, that would be even more helpful..
Anyway, this problem is now being tracked as: https://fedorahosted.org/sssd/ticket/1631
On 11/08/2012 06:24 PM, Jakub Hrozek wrote:
- sssd won't work when I specify correct ldap_sasl_authid (see the
example above). This is bad as I might have my krb5.keytab cluttered with other (possibly not working) keys so I would like to keep the possibility of specifying the ldap_sasl_authid manually.
So this is authid that was working with the plain ldap provider but dosn't work with ad provider? Can you share logs?
Have you tried if using this authid works even with 1.9 with the ldap provider?
looks like the syntax of the ldap_sasl_authid parameter has changed. Previously (in the 1.8.x version) it accepted form <principal_name>@<REALM>, now it only accepts <principal_name>
Ondrej
On Fri, 2012-11-09 at 08:58 +0100, Ondrej Valousek wrote:
On 11/08/2012 06:24 PM, Jakub Hrozek wrote:
- sssd won't work when I specify correct ldap_sasl_authid (see the
example above). This is bad as I might have my krb5.keytab cluttered with other (possibly not working) keys so I would like to keep the possibility of specifying the ldap_sasl_authid manually.
So this is authid that was working with the plain ldap provider but dosn't work with ad provider? Can you share logs?
Have you tried if using this authid works even with 1.9 with the ldap provider?
looks like the syntax of the ldap_sasl_authid parameter has changed. Previously (in the 1.8.x version) it accepted form <principal_name>@<REALM>, now it only accepts <principal_name>
Can you create a ticket for this ? We shouldn't break existing configurations, and this sound just like a plain bug to me.
Simo.
On 11/09/2012 09:01 AM, Simo Sorce wrote:
On Fri, 2012-11-09 at 08:58 +0100, Ondrej Valousek wrote:
On 11/08/2012 06:24 PM, Jakub Hrozek wrote:
- sssd won't work when I specify correct ldap_sasl_authid (see the
example above). This is bad as I might have my krb5.keytab cluttered with other (possibly not working) keys so I would like to keep the possibility of specifying the ldap_sasl_authid manually.
So this is authid that was working with the plain ldap provider but dosn't work with ad provider? Can you share logs?
Have you tried if using this authid works even with 1.9 with the ldap provider?
looks like the syntax of the ldap_sasl_authid parameter has changed. Previously (in the 1.8.x version) it accepted form <principal_name>@<REALM>, now it only accepts <principal_name>
Can you create a ticket for this ? We shouldn't break existing configurations, and this sound just like a plain bug to me.
Simo.
Can someone very that this is an issue and log a ticket?
On Fri, Nov 09, 2012 at 03:10:53PM -0500, Dmitri Pal wrote:
On 11/09/2012 09:01 AM, Simo Sorce wrote:
On Fri, 2012-11-09 at 08:58 +0100, Ondrej Valousek wrote:
On 11/08/2012 06:24 PM, Jakub Hrozek wrote:
- sssd won't work when I specify correct ldap_sasl_authid (see the
example above). This is bad as I might have my krb5.keytab cluttered with other (possibly not working) keys so I would like to keep the possibility of specifying the ldap_sasl_authid manually.
So this is authid that was working with the plain ldap provider but dosn't work with ad provider? Can you share logs?
Have you tried if using this authid works even with 1.9 with the ldap provider?
looks like the syntax of the ldap_sasl_authid parameter has changed. Previously (in the 1.8.x version) it accepted form <principal_name>@<REALM>, now it only accepts <principal_name>
Can you create a ticket for this ? We shouldn't break existing configurations, and this sound just like a plain bug to me.
Simo.
Can someone very that this is an issue and log a ticket?
Given that it's Friday evening already and the issue might get forgotten easily over the weekend I created a ticket to investigate the possible issue: https://fedorahosted.org/sssd/ticket/1635
Even if it turned out to be a documentation task, if an experienced user like Ondrej ran into this problem, chances are others will as well.
On Thu, Oct 18, 2012 at 11:23:53AM +0200, Jakub Hrozek wrote:
Hi,
even though RHEL-6.4 is still brewing, I think there might be some interest in trying out the 1.9.x series of the SSSD on RHEL-6.3.
So I went ahead and built the SSSD 1.9.2 in a RHEL-6.3 buildroot: http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/
The NVR of these test packages will be lower than those in 6.4 to keep the upgrade path clean. The only missing functionality is the PAC responder, which means this SSSD version won't be able to work with an AD domain that is in a trust relationship with an IPA 3.x domain. I had to disable the PAC responder as it requires Kerberos 1.10.
Because some new functionality required tweaking the SELinux policy, you will encounter AVC denials when the new fast cache is accessed. That said, my quick smoke testing went fine and we will be glad to hear test results or bug reports.
Using the repository comes with a warning - this is NOT an official Red Hat supported repository. The packages have NOT gone through formal QA. If it breaks your RHEL-6.3 installation, you get to keep the pieces.
This is the repo configuration I used:
[sssd-1.9-RHEL6.3] name=SSSD 1.9.x built for latest stable RHEL baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/$basearch/ enabled=1 skip_if_unavailable=1 gpgcheck=0
[sssd-1.9-RHEL6.3-source] name=SSSD 1.9.x built for latest stable RHEL - Source baseurl=http://repos.fedorapeople.org/repos/jhrozek/sssd/epel-6/SRPMS enabled=0 skip_if_unavailable=1 gpgcheck=0
Happy testing!
Hi,
First and foremost I wanted to thank all the users who have submitted their bug reports, test results or any other form of feedback. We've managed to identify several critical bugs in the 1.9.2 release we haven't seen during our testing, in particular related to database upgrade or nested group memberships. Thank you!
I have refreshed the repository with bits that are equivalent to upstream 1.9.3 release and are quite close to what RHEL6.4 would be shipping with.
Because RHEL6.4 is going to ship 1.9.2 + patches, we needed to maintain a clean upgrade path from this repository to 6.4 final. So we chose quite nonstandard release tag that contains upstream_1_9_3 to make it clear you're running upstream 1.9.3 just with a funny name.
Upgrading from the previous builds in the same repo should be smooth as well.
Fixing the nested group memberships required a little more processing when saving the groups. So I wanted to ask the users who have reported performance enhancements as compared with 1.8 to kindly check if the new packages are still doing good performance wise.
Using the repository comes with a warning - this is NOT an official Red Hat supported repository. The packages have NOT gone through formal QA. Please proceed with caution.
Happy testing!
On Mon, Dec 10, 2012 at 02:16:50PM +0100, Jakub Hrozek wrote:
I have refreshed the repository with bits that are equivalent to upstream 1.9.3 release and are quite close to what RHEL6.4 would be shipping with.
I refreshed the repo again, the previous packages in uploaded this morning had a packaging bug that caused the 1.9.2 tarball to be included. I didn't realize at first that the %setup macro looks for %{name}-%{version} by default and I forgot to override that with -n.
I fixed the packages (and verified that it's really 1.9.3 code this time) and uploaded them to the repo. Please upgrade to 1.9.2-5.upstream_1_9_3.el6_3 or later.
Sorry for the inconvenience.
On Mon, Dec 10, 2012 at 05:58:09PM +0100, Jakub Hrozek wrote:
On Mon, Dec 10, 2012 at 02:16:50PM +0100, Jakub Hrozek wrote:
I have refreshed the repository with bits that are equivalent to upstream 1.9.3 release and are quite close to what RHEL6.4 would be shipping with.
I refreshed the repo again, the previous packages in uploaded this morning had a packaging bug that caused the 1.9.2 tarball to be included. I didn't realize at first that the %setup macro looks for %{name}-%{version} by default and I forgot to override that with -n.
I fixed the packages (and verified that it's really 1.9.3 code this time) and uploaded them to the repo. Please upgrade to 1.9.2-5.upstream_1_9_3.el6_3 or later.
Sorry for the inconvenience.
One more refresh - I've built 1.9.2-5.upstream_1_9_3.el6_3 that includes all the fixes since 1.9.3, in particular the memory leaks and nss crash John Hodrien reported and the ldap_sasl_authid regression reported by Ondrej Valousek. We plan on including the additional fixes as per the 1.9.4 milestone in the SSSD Trac.
Once again, thank you very much for testing.
Happy holidays!
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Ondrej Valousek -
Simo Sorce -
Trond Hasle Amundsen