On Tue, Apr 30, 2019 at 5:42 PM Karim Bourenane <karim.bouren...@gmail.com> wrote: > > François > > I will do it as a recommandation on Redhat doc for the strategy design of > replication. > > I have another question, not related with my experience :). > > When you buid 2 separate IPA server, and after you want to synchronize them > together, > I must to install the replication with ipa-replicat-install?
Unfortunately, if those are already built separately each with ipa-server-install *and* the desired result is akin to having a replica, then: the only way is to uninstall one of them [losing all data there in the process: users, hosts, groups, sudo rules, etc], reboot, join the first domain with ipa-client-install and launch ipa-replica-install on it. It may even be better to start anew with this one (e.g. redeploy the operating system) rather than try cleaning things up. And obviously clients of the server that is destroyed will have to be enrolled again when the replica is available. > Thanks you. > > Bien à vous > > Mr Karim Bourenane > +33686464439 > +32493866354 > > > > Le mar. 30 avr. 2019 à 14:51, François Cami <fc...@redhat.com> a écrit : >> >> On Tue, Apr 30, 2019 at 2:22 PM Karim Bourenane >> <karim.bouren...@gmail.com> wrote: >> > >> > François, >> > >> > Thanks you, about the architecture redundancy strategy. >> > Is not the final architecture. The new architecture will be have more >> > redundancy with more Master and more replicat server in each site, to >> > authenticate several ipa-client. >> >> Once everything is deployed all IPA servers are identical e.g. the >> distinction between the first server and the resulting replica only >> exists at install-time. >> E.g. provided the feature set selected at install time (CA, KRA...) is >> the same all cluster members are identical. Only one CA member should >> be the CRL generation master though. >> >> > I will deploy more redundancy, but never between each branch of network. >> >> If a single replication agreement exists between those two datacenters >> / zones the risk still exists - even more so with a single server >> sitting in between. >> >> > You think that its the better architecture ? or i must manage by >> > localisation ? >> >> We can only recommend the tight cell topology. >> See "Figure 4.5. Topology Example" and "4.2.2.1. Tight Cell Topology" >> in the documentation I mentioned earlier. >> >> > Bien à vous >> > >> > Mr Karim Bourenane >> > >> > >> > >> > Le lun. 29 avr. 2019 à 23:09, François Cami <fc...@redhat.com> a écrit : >> >> >> >> On Mon, Apr 29, 2019 at 10:32 PM Karim Bourenane via FreeIPA-users >> >> <freeipa-users@lists.fedorahosted.org> wrote: >> >> > >> >> > Hello Jochen >> >> > >> >> > Thanks you or your reply. >> >> > My goal, is to authenticate differents users from each client network >> >> > interface. If the first ipa server goes down (or network unreachable), >> >> > then the admin user can access to the second network interface to make >> >> > change/correct ..... >> >> > >> >> > The goals also, is between the the IPA1 et IPA2, the servers don't have >> >> > any link. >> >> > >> >> > If i understand well, is not possible easyer, because i must change or >> >> > merge the krb5.keytab + sssd.conf right ? >> >> > >> >> > Also i have another question: >> >> > What is the website to begun the full deloyement of FreeIPA ? >> >> > Because im litle lost with blog/freeipa.org/fedora/redhat, and somes >> >> > commands was depreciated ... >> >> > Im in last version of IPA : v4.6.4 >> >> >> >> This is not the last version by a long shot: >> >> https://github.com/freeipa/freeipa/releases >> >> >> >> For IPA 4.6 you might want to use RHEL 7 documentation: >> >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/index >> >> >> >> > Regards >> >> > Bien à vous >> >> > >> >> > Mr Karim Bourenane >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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://getfedora.org/code-of-conduct.html >> >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> >> > List Archives: >> >> > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org