Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Identity Management users with many sites requiring high availability would need at least 1-2 IdM replicas per site. When the number of sites is higher than 20-50, the number of IdM Master servers become too high and harder to maintain. It would be better to deploy ~20 IdM master servers in the major sites and then deploy Read Only replicas in other sites which won't require write access.
Currently, IdM only supports only writable replicas and the high availability is provided by these replicas + offline caching on the client (SSSD) side. However, this does not cover situations when the connection to IdM master server (in other side) is broken and admin needs to log in to a server he/she never logged to.
This story is a long way....
Read only replica's would be high appreciated! Quit some organizations use a read only Windows Domain Controller in DMZ for obvious reason. Some kind of read-only replica's would fit this situation :)
(In reply to W. de Heiden from comment #16)
> This story is a long way....
> Read only replica's would be high appreciated! Quit some organizations use a
> read only Windows Domain Controller in DMZ for obvious reason. Some kind of
> read-only replica's would fit this situation :)
You're completely right. The adoption of this product is limited due to this issue. Another example is premises (write master) -> Cloud (read-only replica).
Please note that this is a very complex RFE. The engineering team is aware of it and has in a (very) long term radar, but it is simply too complex and not prioritized enough to do it in near future. I do not expect it to land in next 1-2 years at least unless there is a strong contribution in the upstream project.
What is more likely to arrive sooner than a Read Only replica is a trust relationship between IdM/FreeIPA replicas, so that for example there can be FreeIPA deployment in DMZ, with trust to (One Way?) Trust to other IdM replica out of DMZ.
Support of the Red-Only replicas is a long standing requirement that has superior complexity and scope. At this point Red Hat Engineering does not see Red Hat delivering this functionally in any foreseeable future. The community ticket (https://pagure.io/freeipa/issue/5569) will still be open welcoming contributions. With the emergence of the microservice technologies and short lived services and clusters Red Hat engineering believes that a better approach would be to support cross-forest IdM to IdM trusts allowing deployment of the small IdM clusters at the edge or in DMZ thus addressing most of the reasons for this requirement.
Please track the progress for IdM to IdM trusts via the following BZ https://bugzilla.redhat.com/show_bug.cgi?id=1185854.
Comment 34f1outsourcing
2023-09-21 13:07:36 UTC
Comment hidden (spam)
What is this crap? Previous versions were supporting read only, so why is now difficult? What is wrong with adding a config entry that does something like this.
Please note this is called bind-dyndb-ldap, not freeip-dyndb-ldap. So stick to standards and forget freeip.
--- a/src/ldap_helper.c 2023-09-21 10:01:10.227396899 +0000
+++ b/src/ldap_helper.c 2023-09-21 10:09:50.785071437 +0000
@@ -3064,6 +3064,9 @@
isc_result_t result;
ldap_connection_t *ldap_conn = NULL;
+ result = ISC_R_SUCCESS;
+ return result;
+
REQUIRE(dn != NULL);
REQUIRE(mods != NULL);
REQUIRE(ldap_inst != NULL);
Your development team there is fucking things up. I have to give the bind user unlimited, memory/swap consumption is terrible, service named stop is taking for ever. It was good 10 years ago, how can it be so bad now.