[Freeipa-users] Re: ipa-replica-install failing - operations error: the changelog directory already exists and is not empty
Hi, thanks for the confirmation. In this case, you can fix the issue with the following procedure: To fix the master that was missing the "cn=changelog5,cn=config" entry follow these steps: [1] Remove the directory /var/lib/dirsrv/slapd-XXX/cldb [2] Use ldapmodify and add this entry dn: cn=changelog5,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-XXX/cldb nsslapd-changelogmaxage: 30d [3] Reinitialize this master from another "good" master, as this master is most likely out of date now. Don't forget to replace the slapd-XXX with your actual instance name. HTH, flo On Tue, Jun 1, 2021 at 7:55 PM Sinh Lam wrote: > Hi Florence - > > Thank you for your response. So to answer your question - > > 1) the directory does exist on the master > 2) the cn=changelog5,cn=config entry is missing in the dse.ldif file. > > Thanks. > > Sinh > > > On June 1, 2021 at 9:25:53 AM, Florence Renaud (f...@redhat.com) wrote: > > Hi, > the error looks similar to > https://bugzilla.redhat.com/show_bug.cgi?id=1590974 > Most of the comments are private in this BZ because they refer to customer > deployments, but the issue can happen if cn=changelog5,cn=config is missing > on the master AND the changelog directory is present. > > Can you check on the master if there is a directory: > /var/lib/dirsrv/slapd-XXX/cldb and if there is an entry > cn=changelog5,cn=config in /etc/dirsrv/slapd-XXX/dse.ldif? > flo > > On Wed, May 26, 2021 at 8:41 PM Sinh Lam via FreeIPA-users < > freeipa-users@lists.fedorahosted.org> wrote: > >> Hi Everyone - >> >> I’m running into this odd issue I can’t seem to find a resolution to. >> Long story short, my IPA master was on a system that had a power failure. >> Upon bring up, the dirsrv failed to start up due to a zero byte dse.ldif >> file. Used a “backup” of the file and my master seemed to have came back >> up ok however replication seems to have stopped working. >> >> When I noticed that replication wasn’t working from the replicas to the >> master I went digging and found this (which led me to try to recover by >> removing the old replicas and trying to do a reinstall) : >> >> replica.domain.net: replica >> last update status: Error (6) Replication error acquiring replica: >> Unable to acquire replica: there is no replicated area on the consumer >> server. Replication is aborting. (no such replica) >> last update ended: 2021-05-20 15:29:28+00:00 >> >> The above “last update” corresponds with the power outage that took down >> the IPA master. >> >> I’m trying to re-initialize the replication by doing a reinstall of the >> replica server but I’m failing with the following error : >> >> Disabled p11-kit-proxy >> Configuring directory server (dirsrv). Estimated time: 30 seconds >> [1/42]: creating directory server instance >> [2/42]: configure autobind for root >> [3/42]: tune ldbm plugin >> [4/42]: stopping directory server >> [5/42]: updating configuration in dse.ldif >> [6/42]: starting directory server >> [7/42]: adding default schema >> [8/42]: enabling memberof plugin >> [9/42]: enabling winsync plugin >> [10/42]: configure password logging >> [11/42]: configuring replication version plugin >> [12/42]: enabling IPA enrollment plugin >> [13/42]: configuring uniqueness plugin >> [14/42]: configuring uuid plugin >> [15/42]: configuring modrdn plugin >> [16/42]: configuring DNS plugin >> [17/42]: enabling entryUSN plugin >> [18/42]: configuring lockout plugin >> [19/42]: configuring topology plugin >> [20/42]: creating indices >> [21/42]: enabling referential integrity plugin >> [22/42]: configuring certmap.conf >> [23/42]: configure new location for managed entries >> [24/42]: configure dirsrv ccache and keytab >> [25/42]: enabling SASL mapping fallback >> [26/42]: restarting directory server >> [27/42]: creating DS keytab >> [28/42]: ignore time skew for initial replication >> [29/42]: setting up initial replication >> [error] DatabaseError: Operations error: The changelog directory >> [/var/lib/dirsrv/slapd-REPLICA-DOMAIN-NET/cldb] already exists and is not >> empty. Please choose a directory that does not exist or is empty. >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Operations error: The changelog directory >> [/var/lib/dirsrv/slapd-REPLICA-DOMAIN-NET/cldb] already exists and is not >> empty. Please choose a directory that does not exist or is empty. >> The ipa-replica-install command failed. See >> /var/log/ipareplica-install.log for more information >> >> I’ve since done several uninstalls and verified at each uninstall the >> /var/lib/dirsrv directory is empty. >> >> Any pointers on how to get past this issue would be great since I have >> about 10 more replicas to get back up. >> >> Thanks. >> >> Sinh >> >> ___ >> FreeIPA-users mai
[Freeipa-users] IPA RA expired, other certificates renewed
Hi there, I need some suggestions for a certificate related problem. The setup has 2 servers, let's call them ldap1 and ldap2 with ldap1 being the primary system with the CA. The certificates were to expire on june 15. I checked on june 1st and on ldap1 certmonger had renewed all certificates, on ldap2 certmonger was not running. So, I restarted the certmonger service and it began its work. `getcert list` shows three certificates (it's ipa 4.4, so that's probably correct) Quite soon, the first certificate was renewed (HTTP/ldap2, ...) I assume that's the one for the web UI. A second one (ldap/ldap2...) is still valid until december. I assume that's why all the ldap related stuff and replication is still working. But the cn=IPA RA expired one week ago (may 24th). I have no ipa-certs-fix, would setting back the system clock still work? The HTTP/ldap2 certificate was not yet valid when the IPA RA certificate expired. Or put the the other round: what happens if i don't renew this certificate - that's not quite clear to me. Currently, the system ist working fine, replication works and in 2022 the hardware will be replaced, so we will setup new replicas anyways. But, that's after the expiration date of the ldap/ldap2 certificate. I hope this is understandable and thanks in advance for any hint. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: IPA RA expired, other certificates renewed
Jan Bundesmann via FreeIPA-users wrote: > Hi there, > > I need some suggestions for a certificate related problem. > The setup has 2 servers, let's call them ldap1 and ldap2 with ldap1 being the > primary system with the CA. > The certificates were to expire on june 15. > I checked on june 1st and on ldap1 certmonger had renewed all certificates, > on ldap2 certmonger was not running. > So, I restarted the certmonger service and it began its work. `getcert list` > shows three certificates (it's ipa 4.4, so that's probably correct) > > Quite soon, the first certificate was renewed (HTTP/ldap2, ...) I assume > that's the one for the web UI. A second one (ldap/ldap2...) is still valid > until december. I assume that's why all the ldap related stuff and > replication is still working. > > But the cn=IPA RA expired one week ago (may 24th). > > I have no ipa-certs-fix, would setting back the system clock still work? The > HTTP/ldap2 certificate was not yet valid when the IPA RA certificate expired. > > Or put the the other round: what happens if i don't renew this certificate - > that's not quite clear to me. Currently, the system ist working fine, > replication works and in 2022 the hardware will be replaced, so we will setup > new replicas anyways. But, that's after the expiration date of the ldap/ldap2 > certificate. > > I hope this is understandable and thanks in advance for any hint. Only one server (CA replication master) does the renewal of the CA certificates, including the RA certificate. It puts the results into LDAP where the other servers can retrieve the updated certificates. So the RA certificate seems already renewed if the server with a CA is working (ipa cert-show 1 as a test). The impact of not having an updated RA certificate on ldap2 is that it won't be able to communicate with the CA. Can we see the tracking of this request on ldap2? getcert list -d /etc/httpd/alias -n ipaCert rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: IPA RA expired, other certificates renewed
Hi, thanks for your answer, That seems in line with not being able to communicate with the CA: ``` [root@ldap2 requests]# ipa cert-show 1 ipa: ERROR: cannot connect to 'https://ldap1:443/ca/agent/ca/displayBySerial': (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired. ``` Unfortunately, I will have no access to the system before next monday to obtain the `getcert list`. The status of the request is 'CA_WORKING' - that much I can tell. I could not see any other response in the logs. (journalctl or /var/log/messages) and the CSR does not seem to arrive at ldap1. But I understand that I could manually bring the CSR to ldap1, sign it there, bring it back... There are, however, a lot of points I'm unsure about. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: IPA RA expired, other certificates renewed
Hi, thanks for your answer, That seems in line with not being able to communicate with the CA: ``` [root@ldap2 requests]# ipa cert-show 1 ipa: ERROR: cannot connect to 'https://ldap1:443/ca/agent/ca/displayBySerial': (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired. ``` Unfortunately, I will have no access to the system before next monday to obtain the `getcert list`. The status of the request is 'CA_WORKING' - that much I can tell. I could not see any other response in the logs. (journalctl or /var/log/messages) and the CSR does not seem to arrive at ldap1. But I understand that I could manually bring the CSR to ldap1, sign it there, bring it back... There are, however, a lot of points I'm unsure about. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: IPA RA expired, other certificates renewed
Jan Bundesmann via FreeIPA-users wrote: > Hi, thanks for your answer, > > That seems in line with not being able to communicate with the CA: > ``` > [root@ldap2 requests]# ipa cert-show 1 > ipa: ERROR: cannot connect to > 'https://ldap1:443/ca/agent/ca/displayBySerial': > (SSL_ERROR_EXPIRED_CERT_ALERT) SSL peer rejected your certificate as expired. > ``` You want to do this on ldap1 to ensure that at the CA works. This does confirm that the RA cert is expired. > Unfortunately, I will have no access to the system before next monday to > obtain the `getcert list`. The status of the request is 'CA_WORKING' - that > much I can tell. > > I could not see any other response in the logs. (journalctl or > /var/log/messages) and the CSR does not seem to arrive at ldap1. But I > understand that I could manually bring the CSR to ldap1, sign it there, bring > it back... There are, however, a lot of points I'm unsure about. The tracking state is what I was looking for. CA_WORKING means that it is waiting for an updated certificate to become available. Is replication working between the two systems? Look on both LDAP servers in cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=test. There should be an entry for the RA agent there (along with the other renewed CA certificates). If the entry exists on ldap2 then getcert resubmit -d /etc/httpd/alias -n ipaCert should force it to try to pick it up. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Solve freeipa 'fragility' via orchestrated containers & whole-container upgrade?
Long time freeipa users have faced a certain 'fragility' freeipa has inherited, mostly as a result of freeipa being the 'band director' over a number of distinct subsystems maintained by various groups across the world. This or that 'little upgrade' in a seemingly small sub-part of freeipa 'suddenly breaks' major things like not being able to install a replica & etc, there's a quite a list and it's been going on for a few years at least to my knowledge. Usually one expects newer features to have bugs but none that disrupt core prior functionality. I wonder whether it would be a solution to this if free-ipa took a look at how a 'similar feeling' multi-host, multi-subsystem architecture has appeared to have solved this puzzle: ceph's 'containers' and 'orchestrator' / cephadm / 'ceph orch' concept. For some time, as freeipa, ceph relied on packages and 'dependency hell management' to operate as native packages across hosts connected on an internal network. Then in a very effective shift: they treated 'the contents of a container' much as 'one thing owned entirely by and released by ceph' and tested that -- each container housing known-good versions of dependent and third party modules as well as their own code -- 'as one thing', to the point of providing their own tool to 'download and manage upgrade installs in the proper sequence' across hosts providing this-or-that functionality. You might imagine a freeipa orchestrator upgrading masters and replicas in the correct order, freeipa devs knowing for certain-sure that no 'dnf upgrade' on the host will disrupt the setup that passed qa in the container... Will not 'corrupt a database' owing to a 'sync' with content one version understood but another did not, etc. Over these many months, while freeipa has struggled to provide consistent service and value, ceph has been working nearly flawlessly across many upgrade cycles and I think it's because ceph controls the versions of the subsystems in the containers-- and that improves QA and dramatically limits surprise breakages' that lead to the feeling of 'always catching up' under conditions of time pressure owing to down services, this or that distro's 100 package mantainers deciding when/if to include this/that patch and when to publish which new version, which are 'security updates', which are 'bug fix updates', etc. If freeipa server came in a container that was tested and QA'd as a container, deployed as a container, perhaps the 'fragility factor' would improve by 10x. My $0.02 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: ipa-replica-install failing - operations error: the changelog directory already exists and is not empty
Hi Flo - Thank you for the instructions. Everything is back to normal and I was able to bring up a new replica in the process after the steps were done. Sinh On June 2, 2021 at 12:46:22 AM, Florence Renaud (f...@redhat.com) wrote: Hi, thanks for the confirmation. In this case, you can fix the issue with the following procedure: To fix the master that was missing the "cn=changelog5,cn=config" entry follow these steps: [1] Remove the directory /var/lib/dirsrv/slapd-XXX/cldb [2] Use ldapmodify and add this entry dn: cn=changelog5,cn=config changetype: add objectclass: top objectclass: extensibleObject cn: changelog5 nsslapd-changelogdir: /var/lib/dirsrv/slapd-XXX/cldb nsslapd-changelogmaxage: 30d [3] Reinitialize this master from another "good" master, as this master is most likely out of date now. Don't forget to replace the slapd-XXX with your actual instance name. HTH, flo On Tue, Jun 1, 2021 at 7:55 PM Sinh Lam wrote: > Hi Florence - > > Thank you for your response. So to answer your question - > > 1) the directory does exist on the master > 2) the cn=changelog5,cn=config entry is missing in the dse.ldif file. > > Thanks. > > Sinh > > > On June 1, 2021 at 9:25:53 AM, Florence Renaud (f...@redhat.com) wrote: > > Hi, > the error looks similar to > https://bugzilla.redhat.com/show_bug.cgi?id=1590974 > Most of the comments are private in this BZ because they refer to customer > deployments, but the issue can happen if cn=changelog5,cn=config is missing > on the master AND the changelog directory is present. > > Can you check on the master if there is a directory: > /var/lib/dirsrv/slapd-XXX/cldb and if there is an entry > cn=changelog5,cn=config in /etc/dirsrv/slapd-XXX/dse.ldif? > flo > > On Wed, May 26, 2021 at 8:41 PM Sinh Lam via FreeIPA-users < > freeipa-users@lists.fedorahosted.org> wrote: > >> Hi Everyone - >> >> I’m running into this odd issue I can’t seem to find a resolution to. >> Long story short, my IPA master was on a system that had a power failure. >> Upon bring up, the dirsrv failed to start up due to a zero byte dse.ldif >> file. Used a “backup” of the file and my master seemed to have came back >> up ok however replication seems to have stopped working. >> >> When I noticed that replication wasn’t working from the replicas to the >> master I went digging and found this (which led me to try to recover by >> removing the old replicas and trying to do a reinstall) : >> >> replica.domain.net: replica >> last update status: Error (6) Replication error acquiring replica: >> Unable to acquire replica: there is no replicated area on the consumer >> server. Replication is aborting. (no such replica) >> last update ended: 2021-05-20 15:29:28+00:00 >> >> The above “last update” corresponds with the power outage that took down >> the IPA master. >> >> I’m trying to re-initialize the replication by doing a reinstall of the >> replica server but I’m failing with the following error : >> >> Disabled p11-kit-proxy >> Configuring directory server (dirsrv). Estimated time: 30 seconds >> [1/42]: creating directory server instance >> [2/42]: configure autobind for root >> [3/42]: tune ldbm plugin >> [4/42]: stopping directory server >> [5/42]: updating configuration in dse.ldif >> [6/42]: starting directory server >> [7/42]: adding default schema >> [8/42]: enabling memberof plugin >> [9/42]: enabling winsync plugin >> [10/42]: configure password logging >> [11/42]: configuring replication version plugin >> [12/42]: enabling IPA enrollment plugin >> [13/42]: configuring uniqueness plugin >> [14/42]: configuring uuid plugin >> [15/42]: configuring modrdn plugin >> [16/42]: configuring DNS plugin >> [17/42]: enabling entryUSN plugin >> [18/42]: configuring lockout plugin >> [19/42]: configuring topology plugin >> [20/42]: creating indices >> [21/42]: enabling referential integrity plugin >> [22/42]: configuring certmap.conf >> [23/42]: configure new location for managed entries >> [24/42]: configure dirsrv ccache and keytab >> [25/42]: enabling SASL mapping fallback >> [26/42]: restarting directory server >> [27/42]: creating DS keytab >> [28/42]: ignore time skew for initial replication >> [29/42]: setting up initial replication >> [error] DatabaseError: Operations error: The changelog directory >> [/var/lib/dirsrv/slapd-REPLICA-DOMAIN-NET/cldb] already exists and is not >> empty. Please choose a directory that does not exist or is empty. >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Operations error: The changelog directory >> [/var/lib/dirsrv/slapd-REPLICA-DOMAIN-NET/cldb] already exists and is not >> empty. Please choose a directory that does not exist or is empty. >> The ipa-replica-install command failed. See >> /var/log/ipareplica-install.log for more information >> >> I’ve since done several uninstalls and verified at each uninstall the >> /var/lib/dirsrv
[Freeipa-users] groups imported incorrectly (made compat tree look out of sync memberUid)
A few months ago, using IPA 4.8.7, I imported users and groups from OpenLDAP: ipa -v migrate-ds --with-compat \ --bind-dn="cn=Manager,dc=example,dc=com" \ --user-container="ou=People,dc=example,dc=com" \ --user-objectclass="posixAccount" \ --group-container="ou=Group,dc=example,dc=com" \ --group-objectclass="posixGroup" \ --group-overwrite-gid \ --schema=RFC2307 \ ldap://openldap-server:389 Now, I've found a problem... In addition to the expected "member" attribute list on the group dn, I also have a memberUid attribute list. These memberUid attributes are not created when using IPA to assign users to groups, just during my import. An imported user: dn: cn=wahoo,cn=groups,cn=accounts,dc=example,dc=com member: uid=fred,cn=users,cn=accounts,dc=example,dc=com memberUid: fred dn: cn=wahoo,cn=groups,cn=compat,dc=example,dc=com memberUid: fred So, no harm done yet. Then I remove fred from the group wahoo. And I end up with this: dn: cn=wahoo,cn=groups,cn=accounts,dc=example,dc=com memberUid: fred dn: cn=wahoo,cn=groups,cn=compat,dc=example,dc=com memberUid: fred Now, anything pointing to my compat tree, still thinks fred is in the wahoo group. The solution is removing the memberUids from the cn=groups,cn=accounts,dc=example,dc=com tree, and the compat tree automatically reflects that change. Question: Is this a bug or did I do something wrong on the import? Thanks, Scott PS- If someone else runs into this, I hope I saved you time. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: groups imported incorrectly (made compat tree look out of sync memberUid)
Scott Serr via FreeIPA-users wrote: > A few months ago, using IPA 4.8.7, I imported users and groups from > OpenLDAP: > > ipa -v migrate-ds --with-compat \ > --bind-dn="cn=Manager,dc=example,dc=com" \ > --user-container="ou=People,dc=example,dc=com" \ > --user-objectclass="posixAccount" \ > --group-container="ou=Group,dc=example,dc=com" \ > --group-objectclass="posixGroup" \ > --group-overwrite-gid \ > --schema=RFC2307 \ > ldap://openldap-server:389 > > Now, I've found a problem... > > In addition to the expected "member" attribute list on the group dn, I > also have a memberUid attribute list. These memberUid attributes are > not created when using IPA to assign users to groups, just during my import. > > An imported user: > > dn: cn=wahoo,cn=groups,cn=accounts,dc=example,dc=com > member: uid=fred,cn=users,cn=accounts,dc=example,dc=com > memberUid: fred > > dn: cn=wahoo,cn=groups,cn=compat,dc=example,dc=com > memberUid: fred > > So, no harm done yet. Then I remove fred from the group wahoo. And I > end up with this: > > dn: cn=wahoo,cn=groups,cn=accounts,dc=example,dc=com > memberUid: fred > > dn: cn=wahoo,cn=groups,cn=compat,dc=example,dc=com > memberUid: fred > > Now, anything pointing to my compat tree, still thinks fred is in the > wahoo group. > > The solution is removing the memberUids from the > cn=groups,cn=accounts,dc=example,dc=com tree, and the compat tree > automatically reflects that change. > > Question: > Is this a bug or did I do something wrong on the import? It seems that the memberuid are converted into member but then the attribute isn't dropped. If you pass in --group-ignore-attribute=memberuid that will probably do it as the conversion happens before the attribute is dropped. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Solve freeipa 'fragility' via orchestrated containers & whole-container upgrade?
On Wed, Jun 02, 2021 at 01:55:36PM -0500, Harry G. Coin via FreeIPA-users wrote: > Long time freeipa users have faced a certain 'fragility' freeipa has > inherited, mostly as a result of freeipa being the 'band director' over > a number of distinct subsystems maintained by various groups across the > world. > > This or that 'little upgrade' in a seemingly small sub-part of freeipa > 'suddenly breaks' major things like not being able to install a replica > & etc, there's a quite a list and it's been going on for a few years at > least to my knowledge. Usually one expects newer features to have bugs > but none that disrupt core prior functionality. > > I wonder whether it would be a solution to this if free-ipa took a look > at how a 'similar feeling' multi-host, multi-subsystem architecture has > appeared to have solved this puzzle: ceph's 'containers' and > 'orchestrator' / cephadm / 'ceph orch' concept. > > For some time, as freeipa, ceph relied on packages and 'dependency hell > management' to operate as native packages across hosts connected on an > internal network. Then in a very effective shift: they treated 'the > contents of a container' much as 'one thing owned entirely by and > released by ceph' and tested that -- each container housing known-good > versions of dependent and third party modules as well as their own code > -- 'as one thing', to the point of providing their own tool to > 'download and manage upgrade installs in the proper sequence' across > hosts providing this-or-that functionality. > > You might imagine a freeipa orchestrator upgrading masters and replicas > in the correct order, freeipa devs knowing for certain-sure that no 'dnf > upgrade' on the host will disrupt the setup that passed qa in the > container... Will not 'corrupt a database' owing to a 'sync' with > content one version understood but another did not, etc. > > Over these many months, while freeipa has struggled to provide > consistent service and value, ceph has been working nearly flawlessly > across many upgrade cycles and I think it's because ceph controls the > versions of the subsystems in the containers-- and that improves QA and > dramatically limits surprise breakages' that lead to the feeling of > 'always catching up' under conditions of time pressure owing to down > services, this or that distro's 100 package mantainers deciding when/if > to include this/that patch and when to publish which new version, which > are 'security updates', which are 'bug fix updates', etc. If freeipa > server came in a container that was tested and QA'd as a container, > deployed as a container, perhaps the 'fragility factor' would improve by > 10x. > > My $0.02 Hi Harry, There is a current effort (still in early stages) to implement something like what you describe: FreeIPA in OpenShift managed via an OpenShift Operator. Can't say much else because we still have a lot of technical and policy challenges to solve. Certainly can't give a timeframe. But rest assured we are aware of the potential benefits of container orchestration. We are also aware that it is not a panacea and that the engineering costs are orders of magnitude greater than 2c ^_^ Cheers, Fraser ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: Solve freeipa 'fragility' via orchestrated containers & whole-container upgrade?
On to, 03 kesä 2021, Fraser Tweedale via FreeIPA-users wrote: On Wed, Jun 02, 2021 at 01:55:36PM -0500, Harry G. Coin via FreeIPA-users wrote: Long time freeipa users have faced a certain 'fragility' freeipa has inherited, mostly as a result of freeipa being the 'band director' over a number of distinct subsystems maintained by various groups across the world. This or that 'little upgrade' in a seemingly small sub-part of freeipa 'suddenly breaks' major things like not being able to install a replica & etc, there's a quite a list and it's been going on for a few years at least to my knowledge. Usually one expects newer features to have bugs but none that disrupt core prior functionality. I wonder whether it would be a solution to this if free-ipa took a look at how a 'similar feeling' multi-host, multi-subsystem architecture has appeared to have solved this puzzle: ceph's 'containers' and 'orchestrator' / cephadm / 'ceph orch' concept. For some time, as freeipa, ceph relied on packages and 'dependency hell management' to operate as native packages across hosts connected on an internal network. Then in a very effective shift: they treated 'the contents of a container' much as 'one thing owned entirely by and released by ceph' and tested that -- each container housing known-good versions of dependent and third party modules as well as their own code -- 'as one thing', to the point of providing their own tool to 'download and manage upgrade installs in the proper sequence' across hosts providing this-or-that functionality. You might imagine a freeipa orchestrator upgrading masters and replicas in the correct order, freeipa devs knowing for certain-sure that no 'dnf upgrade' on the host will disrupt the setup that passed qa in the container... Will not 'corrupt a database' owing to a 'sync' with content one version understood but another did not, etc. Over these many months, while freeipa has struggled to provide consistent service and value, ceph has been working nearly flawlessly across many upgrade cycles and I think it's because ceph controls the versions of the subsystems in the containers-- and that improves QA and dramatically limits surprise breakages' that lead to the feeling of 'always catching up' under conditions of time pressure owing to down services, this or that distro's 100 package mantainers deciding when/if to include this/that patch and when to publish which new version, which are 'security updates', which are 'bug fix updates', etc. If freeipa server came in a container that was tested and QA'd as a container, deployed as a container, perhaps the 'fragility factor' would improve by 10x. My $0.02 Hi Harry, There is a current effort (still in early stages) to implement something like what you describe: FreeIPA in OpenShift managed via an OpenShift Operator. Can't say much else because we still have a lot of technical and policy challenges to solve. Certainly can't give a timeframe. But rest assured we are aware of the potential benefits of container orchestration. We are also aware that it is not a panacea and that the engineering costs are orders of magnitude greater than 2c ^_^ I would also add that it is unlikely a situation for such container would be anything better than what we already have in freeipa/freeipa-container repository because it is being built and tested against a moving target that is a distribution, anyway. Sure, you are making a fixed image for a certain period of time but any CVE fixes in any of the components which are part of that image would force you to rebuild against that moving target that a distribution is. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
