LDAP failover fails
We are experiencing the LDAP failover issue described in [1]. Redhat’s solution is to not bother fixing the bug, and to tell customers to put the LDAP server behind a load-balancer. According to Redhat, that is not a good solution for FreeIPA, as explained in [2] and further elucidated in the blog post [3] that it references. I see that the community has a bug open for this [4] and the bug is being worked on here [5] but there has been no activity since 10/22. What is the status of this bugfix? Does it just need someone to review and merge it, or is there more work to be done? How are other FreeIPA users working around this problem? [1] https://bugzilla.redhat.com/show_bug.cgi?id=2024602#c3 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... [3] http://ssimo.org/blog/id_019.html [4] https://bugs.launchpad.net/keystone/+bug/1953622 [5] https://review.opendev.org/c/openstack/keystone/+/821086
Hi, I noticed that https://review.opendev.org/c/openstack/keystone/+/860118 is also linked from your bugzilla link. I wasn't aware of the work in https://review.opendev.org/c/openstack/keystone/+/821086 I'm currently trying to fix the ldap breakage in keystone. during the last keystone reviewathons it became clear that it would be better to solve this stuff in the ldappool library itself. regarding the overall project status I guess it's fair to say that ldap support ist pretty dormant right now. This is my first dive into the keystone codebase, so I guess it's save to say that additional people interested in ldap would be more than welcome. But I guess the core keystone team can say more about this. Having said all this, I guess this explains the general status of ldap related patches in keystone. HTH & kind regards Am Mittwoch, dem 19.07.2023 um 14:55 +0000 schrieb Albert Braden:
We are experiencing the LDAP failover issue described in [1]. Redhat’s solution is to not bother fixing the bug, and to tell customers to put the LDAP server behind a load-balancer. According to Redhat, that is not a good solution for FreeIPA, as explained in [2] and further elucidated in the blog post [3] that it references. I see that the community has a bug open for this [4] and the bug is being worked on here [5] but there has been no activity since 10/22.
What is the status of this bugfix? Does it just need someone to review and merge it, or is there more work to be done? How are other FreeIPA users working around this problem?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2024602#c3 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... [3] http://ssimo.org/blog/id_019.html [4] https://bugs.launchpad.net/keystone/+bug/1953622 [5] https://review.opendev.org/c/openstack/keystone/+/821086
-- Sven Kieske Senior Cloud Engineer Mail: kieske@osism.tech Web: https://osism.tech OSISM GmbH Teckstraße 62 / 70190 Stuttgart / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139
When you say "solve this stuff in the ldappool library" are you talking about moving the broken server to the end of the pool instead of removing it? Since the first server in the URL is always used, and failover doesn't seem to work, it seems like moving the broken URL to the end of the list would be a good solution, and that would eliminate the problem of having to add it back after it starts working again. I'm looking at the ldappool code here: https://opendev.org/openstack/ldappool/src/branch/master/ldappool/__init__.p... So far it's not obvious to me how the pool is being assembled. What is the relationship between the LDAP URLs in the Keystone config, and the connections in the pool? What would have to change, to allow a failing URL to be treated as if it were not the first one in the list? On Wednesday, July 19, 2023 at 11:46:25 AM EDT, Sven Kieske <kieske@osism.tech> wrote: Hi, I noticed that https://review.opendev.org/c/openstack/keystone/+/860118 is also linked from your bugzilla link. I wasn't aware of the work in https://review.opendev.org/c/openstack/keystone/+/821086 I'm currently trying to fix the ldap breakage in keystone. during the last keystone reviewathons it became clear that it would be better to solve this stuff in the ldappool library itself. regarding the overall project status I guess it's fair to say that ldap support ist pretty dormant right now. This is my first dive into the keystone codebase, so I guess it's save to say that additional people interested in ldap would be more than welcome. But I guess the core keystone team can say more about this. Having said all this, I guess this explains the general status of ldap related patches in keystone. HTH & kind regards Am Mittwoch, dem 19.07.2023 um 14:55 +0000 schrieb Albert Braden:
We are experiencing the LDAP failover issue described in [1]. Redhat’s solution is to not bother fixing the bug, and to tell customers to put the LDAP server behind a load-balancer. According to Redhat, that is not a good solution for FreeIPA, as explained in [2] and further elucidated in the blog post [3] that it references. I see that the community has a bug open for this [4] and the bug is being worked on here [5] but there has been no activity since 10/22.
What is the status of this bugfix? Does it just need someone to review and merge it, or is there more work to be done? How are other FreeIPA users working around this problem?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2024602#c3 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... [3] http://ssimo.org/blog/id_019.html [4] https://bugs.launchpad.net/keystone/+bug/1953622 [5] https://review.opendev.org/c/openstack/keystone/+/821086
-- Sven Kieske Senior Cloud Engineer Mail: kieske@osism.tech Web: https://osism.tech OSISM GmbH Teckstraße 62 / 70190 Stuttgart / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139
Does anyone on the keystone team want to comment on this? On Thursday, July 20, 2023 at 03:14:23 PM EDT, Albert Braden <ozzzo@yahoo.com> wrote: When you say "solve this stuff in the ldappool library" are you talking about moving the broken server to the end of the pool instead of removing it? Since the first server in the URL is always used, and failover doesn't seem to work, it seems like moving the broken URL to the end of the list would be a good solution, and that would eliminate the problem of having to add it back after it starts working again. I'm looking at the ldappool code here: https://opendev.org/openstack/ldappool/src/branch/master/ldappool/__init__.p... So far it's not obvious to me how the pool is being assembled. What is the relationship between the LDAP URLs in the Keystone config, and the connections in the pool? What would have to change, to allow a failing URL to be treated as if it were not the first one in the list? On Wednesday, July 19, 2023 at 11:46:25 AM EDT, Sven Kieske <kieske@osism.tech> wrote: Hi, I noticed that https://review.opendev.org/c/openstack/keystone/+/860118 is also linked from your bugzilla link. I wasn't aware of the work in https://review.opendev.org/c/openstack/keystone/+/821086 I'm currently trying to fix the ldap breakage in keystone. during the last keystone reviewathons it became clear that it would be better to solve this stuff in the ldappool library itself. regarding the overall project status I guess it's fair to say that ldap support ist pretty dormant right now. This is my first dive into the keystone codebase, so I guess it's save to say that additional people interested in ldap would be more than welcome. But I guess the core keystone team can say more about this. Having said all this, I guess this explains the general status of ldap related patches in keystone. HTH & kind regards Am Mittwoch, dem 19.07.2023 um 14:55 +0000 schrieb Albert Braden:
We are experiencing the LDAP failover issue described in [1]. Redhat’s solution is to not bother fixing the bug, and to tell customers to put the LDAP server behind a load-balancer. According to Redhat, that is not a good solution for FreeIPA, as explained in [2] and further elucidated in the blog post [3] that it references. I see that the community has a bug open for this [4] and the bug is being worked on here [5] but there has been no activity since 10/22.
What is the status of this bugfix? Does it just need someone to review and merge it, or is there more work to be done? How are other FreeIPA users working around this problem?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2024602#c3 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... [3] http://ssimo.org/blog/id_019.html [4] https://bugs.launchpad.net/keystone/+bug/1953622 [5] https://review.opendev.org/c/openstack/keystone/+/821086
-- Sven Kieske Senior Cloud Engineer Mail: kieske@osism.tech Web: https://osism.tech OSISM GmbH Teckstraße 62 / 70190 Stuttgart / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139
Anyone? How are others working around this bug? Is setting the timeout to 1 second a good solution? I tried that in my lab and it seems to work but I'm not sure what the effect would be in a heavily used region. On Tuesday, July 25, 2023 at 12:51:20 AM EDT, Albert Braden <ozzzo@yahoo.com> wrote: Does anyone on the keystone team want to comment on this? On Thursday, July 20, 2023 at 03:14:23 PM EDT, Albert Braden <ozzzo@yahoo.com> wrote: When you say "solve this stuff in the ldappool library" are you talking about moving the broken server to the end of the pool instead of removing it? Since the first server in the URL is always used, and failover doesn't seem to work, it seems like moving the broken URL to the end of the list would be a good solution, and that would eliminate the problem of having to add it back after it starts working again. I'm looking at the ldappool code here: https://opendev.org/openstack/ldappool/src/branch/master/ldappool/__init__.p... So far it's not obvious to me how the pool is being assembled. What is the relationship between the LDAP URLs in the Keystone config, and the connections in the pool? What would have to change, to allow a failing URL to be treated as if it were not the first one in the list? On Wednesday, July 19, 2023 at 11:46:25 AM EDT, Sven Kieske <kieske@osism.tech> wrote: Hi, I noticed that https://review.opendev.org/c/openstack/keystone/+/860118 is also linked from your bugzilla link. I wasn't aware of the work in https://review.opendev.org/c/openstack/keystone/+/821086 I'm currently trying to fix the ldap breakage in keystone. during the last keystone reviewathons it became clear that it would be better to solve this stuff in the ldappool library itself. regarding the overall project status I guess it's fair to say that ldap support ist pretty dormant right now. This is my first dive into the keystone codebase, so I guess it's save to say that additional people interested in ldap would be more than welcome. But I guess the core keystone team can say more about this. Having said all this, I guess this explains the general status of ldap related patches in keystone. HTH & kind regards Am Mittwoch, dem 19.07.2023 um 14:55 +0000 schrieb Albert Braden:
We are experiencing the LDAP failover issue described in [1]. Redhat’s solution is to not bother fixing the bug, and to tell customers to put the LDAP server behind a load-balancer. According to Redhat, that is not a good solution for FreeIPA, as explained in [2] and further elucidated in the blog post [3] that it references. I see that the community has a bug open for this [4] and the bug is being worked on here [5] but there has been no activity since 10/22.
What is the status of this bugfix? Does it just need someone to review and merge it, or is there more work to be done? How are other FreeIPA users working around this problem?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2024602#c3 [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm... [3] http://ssimo.org/blog/id_019.html [4] https://bugs.launchpad.net/keystone/+bug/1953622 [5] https://review.opendev.org/c/openstack/keystone/+/821086
-- Sven Kieske Senior Cloud Engineer Mail: kieske@osism.tech Web: https://osism.tech OSISM GmbH Teckstraße 62 / 70190 Stuttgart / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139
participants (2)
-
Albert Braden
-
Sven Kieske