Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/03/2015 04:10 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: replicas installed from older versions do not have a binddn group just accept the errror ACK Pushed to master: 8457edc14dade724b486540800bcdafb7d9a6f76 Note that this group will be populated later. IMHO it should be done as a part of domain-level raise procedure before setting the new level. As said in other mail, I am not sure why we should be overloading domain-level raise command that way. I thought, we will create this group when the first replica upgrades to 4.2. Whenever a new replica is added/upgraded, it's principal will be added to the group also (even if Domain Level is 0). Domain Level 1 means that all replicas are 4.2 and thus the group is fully populated and Topology can be used. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: replicas installed from older versions do not have a binddn group just accept the errror ACK Pushed to master: 8457edc14dade724b486540800bcdafb7d9a6f76 Note that this group will be populated later. IMHO it should be done as a part of domain-level raise procedure before setting the new level. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/03/2015 04:10 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: replicas installed from older versions do not have a binddn group just accept the errror ACK Pushed to master: 8457edc14dade724b486540800bcdafb7d9a6f76 Note that this group will be populated later. if you start with 4.2 the group is created and populated when the ldap principals are added to the replica as binddns. Only if you install the replica from an older version the database is initialized from the older master and it is gone. so it has to be populated later. IMHO it should be done as a part of domain-level raise procedure before setting the new level. It could also be populated as soon as the first 4.2 replica is installed, it doesn't require any schema changes and can be added/replicated to older serevrs as well -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On Wed, 2015-06-03 at 16:10 +0200, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: replicas installed from older versions do not have a binddn group just accept the errror ACK Pushed to master: 8457edc14dade724b486540800bcdafb7d9a6f76 Note that this group will be populated later. IMHO it should be done as a part of domain-level raise procedure before setting the new level. Creating this group and populating it should be part of ipa-ldap-update (sorry forgot the right name) and should be done when we install new rpms. Each server must care by itself to populate this group with its own membership. In particular this *should* not be done when the domain level is raised, it is already late then. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On Wed, 2015-06-03 at 16:50 +0200, Martin Kosek wrote: On 06/03/2015 04:10 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: replicas installed from older versions do not have a binddn group just accept the errror ACK Pushed to master: 8457edc14dade724b486540800bcdafb7d9a6f76 Note that this group will be populated later. IMHO it should be done as a part of domain-level raise procedure before setting the new level. As said in other mail, I am not sure why we should be overloading domain-level raise command that way. +1 I thought, we will create this group when the first replica upgrades to 4.2. Whenever a new replica is added/upgraded, it's principal will be added to the group also (even if Domain Level is 0). +1 Domain Level 1 means that all replicas are 4.2 and thus the group is fully populated and Topology can be used. +1 -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg the topology plugin needs a replica binddngroup to be able to setup agrements without having to modify cn=config. If the replica is installed from an older version, this group doesn't exist and adding members to it fails. The attached patch should handle this Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]: importing CA chain to RA certificate database [11/21]: fixing RA database permissions [12/21]: setting up signing cert profile [13/21]: set certificate subject base [14/21]: enabling Subject Key Identifier [15/21]: enabling Subject Alternative Name [16/21]: enabling CRL and OCSP extensions for certificates [17/21]: setting audit signing renewal to 2 years [18/21]:
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? There should be a moment where all the DNs are added. root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg the topology plugin needs a replica binddngroup to be able to setup agrements without having to modify cn=config. If the replica is installed from an older version, this group doesn't exist and adding members to it fails. The attached patch should handle this Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate server instance [3/21]: stopping certificate server instance to update CS.cfg [4/21]: backing up CS.cfg [5/21]: disabling nonces [6/21]: set up CRL publishing [7/21]: enable PKIX certificate path discovery and validation [8/21]: starting certificate server instance [9/21]: creating RA agent certificate database [10/21]:
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. I see you created cn=replication managers,cn=etc,SUFFIX group. I think this should work, with couple changes: - it should rather be in cn=sysaccounts,cn=etc,SUFFIX, where other similar groups are. See for example cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX used for Trusts (populated by ipa-adtrust-install), it is exactly the same case, so it should follow the similar/same location and structure. Yep, see my another email with an example. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it root@localhost:/home/ofayans/rpms]$ ipa-replica-install --setup-ca --setup-dns --forwarder 10.38.5.26 /var/lib/ipa/replica-info-replica1.zaeba.li.gpg the topology plugin needs a replica binddngroup to be able to setup agrements without having to modify cn=config. If the replica is installed from an older version, this group doesn't exist and adding members to it fails. The attached patch should handle this Directory Manager (existing master) password: Existing BIND configuration detected, overwrite? [no]: yes Adding [192.168.122.210 replica1.zaeba.li] to your /etc/hosts file Checking forwarders, please wait ... Using reverse zone(s) 122.168.192.in-addr.arpa. Run connection check to master Check connection from replica to remote master 'upgrademaster.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@zaeba.li password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'replica1.zaeba.li': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/37]: creating directory server user [2/37]: creating directory server instance [3/37]: adding default schema [4/37]: enabling memberof plugin [5/37]: enabling winsync plugin [6/37]: configuring replication version plugin [7/37]: enabling IPA enrollment plugin [8/37]: enabling ldapi [9/37]: configuring uniqueness plugin [10/37]: configuring uuid plugin [11/37]: configuring modrdn plugin [12/37]: configuring DNS plugin [13/37]: enabling entryUSN plugin [14/37]: configuring lockout plugin [15/37]: configuring topology plugin [16/37]: creating indices [17/37]: enabling referential integrity plugin [18/37]: configuring ssl for ds instance [19/37]: configuring certmap.conf [20/37]: configure autobind for root [21/37]: configure new location for managed entries [22/37]: configure dirsrv ccache [23/37]: enable SASL mapping fallback [24/37]: restarting directory server [25/37]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 7 seconds elapsed Update succeeded [26/37]: updating schema [27/37]: setting Auto Member configuration [28/37]: enabling S4U2Proxy delegation [29/37]: importing CA certificates from LDAP [30/37]: initializing group membership [31/37]: adding master entry ipa : CRITICAL Failed to load master-entry.ldif: Command ''/usr/bin/ldapmodify' '-v' '-f' '/tmp/tmpFlM3mD' '-H' 'ldap://replica1.zaeba.li:389' '-x' '-D' 'cn=Directory Manager' '-y' '/tmp/tmpk_R0Lm'' returned non-zero exit status 68 [32/37]: initializing domain level [33/37]: configuring Posix uid/gid generation [34/37]: adding replication acis [35/37]: enabling compatibility plugin [36/37]: tuning directory server [37/37]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/21]: creating certificate server user [2/21]: configuring certificate
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. I see you created cn=replication managers,cn=etc,SUFFIX group. I think this should work, with couple changes: - it should rather be in cn=sysaccounts,cn=etc,SUFFIX, where other similar groups are. See for example cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX used for Trusts (populated by ipa-adtrust-install), it is exactly the same case, so it should follow the similar/same location and structure. Yep, see my another email with an example. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. I see you created cn=replication managers,cn=etc,SUFFIX group. I think this should work, with couple changes: - it should rather be in cn=sysaccounts,cn=etc,SUFFIX, where other similar groups are. See for example cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX used for Trusts (populated by ipa-adtrust-install), it is exactly the same case, so it should follow the similar/same location and structure. - the group should be populated during new installation of 4.2 or upgrade to 4.2 so that Domain Level raise does not need to be overloaded and generate this group by itself. If this group is populated from FreeIPA 4.2+, raising to Domain Level 1 would mean no operation needed on FreeIPA side. This is part of the ticket https://fedorahosted.org/freeipa/ticket/3416 This looks as another change that should make it to the Alpha, no? Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? If this group is populated from FreeIPA 4.2+, raising to Domain Level 1 would mean no operation needed on FreeIPA side. This is part of the ticket https://fedorahosted.org/freeipa/ticket/3416 This looks as another change that should make it to the Alpha, no? Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. If this group is populated from FreeIPA 4.2+, raising to Domain Level 1 would mean no operation needed on FreeIPA side. This is part of the ticket https://fedorahosted.org/freeipa/ticket/3416 This looks as another change that should make it to the Alpha, no? Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. They should be fqdn=ipa.master,... For example, this is how cn=adtrust agents looks like for upcoming one-way trust: # adtrust agents, sysaccounts, etc, t.vda.li dn: cn=adtrust agents,cn=sysaccounts,cn=etc,dc=t,dc=vda,dc=li objectClass: GroupOfNames objectClass: top objectClass: nestedgroup cn: adtrust agents memberOf: cn=ADTrust Agents,cn=privileges,cn=pbac,dc=t,dc=vda,dc=li memberOf: cn=System: Read system trust accounts,cn=permissions,cn=pbac,dc=t,dc =vda,dc=li member: krbprincipalname=cifs/ipa-01.t.vda...@t.vda.li,cn=services,cn=accounts ,dc=t,dc=vda,dc=li member: fqdn=ipa-01.t.vda.li,cn=computers,cn=accounts,dc=t,dc=vda,dc=li As you can see, cifs/ipa.master and host/ipa.master are members of the group through their respective DNs -- for host/ipa.master the DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On Tue, 02 Jun 2015, Simo Sorce wrote: On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. I'm fine to have that too, we rely on it in trusts case so just follow the pattern. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 06:00 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Simo Sorce wrote: On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. I'm fine to have that too, we rely on it in trusts case so just follow the pattern. Cool! Who will do the work and make sure the group and the members are properly set on installation and upgrades? Petr1, Jan or anyone else? (The group should also move to sysaccounts container with this change). -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0010] KeyError raised upon replica installation
On 06/02/2015 06:53 PM, Martin Kosek wrote: On 06/02/2015 06:00 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Simo Sorce wrote: On Tue, 2015-06-02 at 17:45 +0200, Martin Kosek wrote: On 06/02/2015 05:41 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:32 PM, Alexander Bokovoy wrote: On Tue, 02 Jun 2015, Martin Kosek wrote: On 06/02/2015 05:24 PM, Ludwig Krispenz wrote: On 06/02/2015 05:16 PM, Martin Kosek wrote: On 06/02/2015 05:08 PM, Ludwig Krispenz wrote: On 06/02/2015 03:53 PM, Petr Vobornik wrote: On 06/02/2015 02:20 PM, Ludwig Krispenz wrote: On 06/02/2015 12:09 PM, Oleg Fayans wrote: Hi all, The following error was caught during replica installation (I used all the latest patches from Ludwig and Martin Basti): -except ldap.TYPE_OR_VALUE_EXISTS: +except (ldap.TYPE_OR_VALUE_EXISTS, ldap.NO_SUCH_OBJECT): What happens if all replicas are updated and domain level is raised? I don't think that the group will be populated. Or will it be? Without it, topology plugin won't work, right? good point, it will be limited, when adding a new segment a replication agreement will be created, but it will not have the credentials to replicate. There should be a moment where all the DNs are added. yes, there could probably be a check when topology plugin gets active if the binddn group exists and if not create and populate it Should we finally start maintaining by default IPA Masters hostgroup? *That* should be the BIND DN group which Topology plugins works with, no? what would be the members of this group ? the binddn group needs all the ldap principals in it so that a replica can do gssapi replication to another replica. Ah. Hosts would be members of the group, i.e. host/server1.example.test principals. If this is the case, the IPA Masters group does not look that helpful. No, host's DN is fqdn=ipa.master,cn=computers,cn=accounts,$SUFFIX. This is exception in the way Kerberos services addressed. Sure. But my point here was that host principals (and a hostgroup) are not helpful here as DS will be authenticating with ldap/... principals. Correct, so you need to go one step more and simply add krbprincipalname=ldap/ipa.master,... to the list. You know that if the host from IPA Masters hostgroup, then it has to have ldap service and if it is not, then it is not a master, so you'd skip that one. Ah, so this is what you though. I am not sure here, I do not think we made services members of host group in the past. And I am not convinced we want to start with it now. CCing Simo for reference. Wouldn't a system group (sysaccounts) of replication managers with just the ldap/ principals cleaner and perfectly inline with what we did with cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX? I do not have a strong preference, the advantage of a host group is that admins can see and manipulate it ... and that is also the disadvantage in this case. As it is a great way to break replication. So perhaps, yes, having a masters groups under sysaccount may be safer for now. I'm fine to have that too, we rely on it in trusts case so just follow the pattern. Cool! Who will do the work and make sure the group and the members are properly set on installation and upgrades? Petr1, Jan or anyone else? (The group should also move to sysaccounts container with this change). I will do it. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
