[Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword
Hi,
Adds support for host definition by a environment variables of the
following form:
KEYWORDHOST__envX, where X is the number of the environment
for which host referenced by a keyword should be defined.
You can also optionally use KEYWORDHOST__IP_envX to define
the IP address directly, otherwise the framework will try to resolve
the hostname.
Adds a required_keyword_hosts attribute to the IntegrationTest class,
which can test developer use to specify the keyword hosts that this
particular test requires. If not all required keyword hosts are
available, the test will be skipped.
All keyword hosts are accessible to the IntegrationTests via the
keyword_hosts attribute, which contains a dictionary keyed by the
keywords.
Part of: https://fedorahosted.org/freeipa/ticket/3833
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 5c3527b3008fb0512e93b985c8cb486087c8a9e4 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 16 Oct 2013 13:54:26 +0200
Subject: [PATCH] ipatests: Add support for hosts referenced by a keyword
Adds support for host definition by a environment variables of the
following form:
KEYWORDHOST_keyword_envX, where X is the number of the environment
for which host referenced by a keyword keyword should be defined.
You can also optionally use KEYWORDHOST_keyword_IP_envX to define
the IP address directly, otherwise the framework will try to resolve
the hostname.
Adds a required_keyword_hosts attribute to the IntegrationTest class,
which can test developer use to specify the keyword hosts that this
particular test requires. If not all required keyword hosts are
available, the test will be skipped.
All keyword hosts are accessible to the IntegrationTests via the
keyword_hosts attribute, which contains a dictionary keyed by the
keywords.
Part of: https://fedorahosted.org/freeipa/ticket/3833
---
ipatests/ipa-test-config| 19 +++--
ipatests/man/ipa-test-config.1 | 17 +++
ipatests/test_integration/base.py | 16 ++-
ipatests/test_integration/config.py | 57 +
ipatests/test_integration/host.py | 22 +-
5 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/ipatests/ipa-test-config b/ipatests/ipa-test-config
index 538ae3530d5b3959dd4516ac78f5a85d6f2bfaf4..288dbeeae1fa40a51010e091dacbf8b184e60788 100755
--- a/ipatests/ipa-test-config
+++ b/ipatests/ipa-test-config
@@ -55,6 +55,9 @@ def main(argv):
parser.add_argument('--client', type=int,
help='Print config for the client with this number')
+parser.add_argument('--keyword', type=str,
+help='Print config for machine with this keyword')
+
parser.add_argument('--no-simple', dest='simple', action='store_false',
help='Do not print Simple Vars '
'(normally included backwards-compatibility)')
@@ -121,18 +124,30 @@ def get_object(conf, args):
if args.master:
return domain.master
+
elif args.replica:
num = int(args.replica) - 1
try:
return domain.replicas[args.replica]
except LookupError:
-exit('Domain %s not found in domain %s' % (args.replica, domain.name))
+exit('Domain %s not found in domain %s' % (args.replica,
+ domain.name))
+
elif args.client:
num = int(args.client) - 1
try:
return domain.replicas[args.client]
except LookupError:
-exit('Client %s not found in domain %s' % (args.client, domain.name))
+exit('Client %s not found in domain %s' % (args.client,
+ domain.name))
+
+elif args.keyword:
+try:
+return domain.keyword_hosts[args.keyword]
+except LookupError:
+exit('Keyword host %s not found in domain %s' % (args.keyword,
+ domain.name))
+
else:
return domain
diff --git a/ipatests/man/ipa-test-config.1 b/ipatests/man/ipa-test-config.1
index c0fad910326b0aa897336ac3fdf530461ce2c4e8..893a72bad4a41ddc8f5a1391a9df4fa6ed22521c 100644
--- a/ipatests/man/ipa-test-config.1
+++ b/ipatests/man/ipa-test-config.1
@@ -65,6 +65,9 @@ Output configuration for the replica with the given number
\fB\-\-replica\fR
Output configuration for the client with the given number
.TP
+\fB\-\-keyword\fR
+Output configuration for the host with the given keyword.
+.TP
\fB\-\-no\-simple\fR
Do not output Simple Vars.
These are normally included for backwards compatibility.
@@ -95,6 +98,20 @@ Host configuration:
\fB$BEAKER\fRrolenum\fB_IP_env\fRe, e.g.
Re: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword
On 10/22/2013 09:20 AM, Tomas Babej wrote: Hi, Adds support for host definition by a environment variables of the following form: KEYWORDHOST__envX, where X is the number of the environment for which host referenced by a keyword should be defined. You can also optionally use KEYWORDHOST__IP_envX to define the IP address directly, otherwise the framework will try to resolve the hostname. Adds a required_keyword_hosts attribute to the IntegrationTest class, which can test developer use to specify the keyword hosts that this particular test requires. If not all required keyword hosts are available, the test will be skipped. All keyword hosts are accessible to the IntegrationTests via the keyword_hosts attribute, which contains a dictionary keyed by the keywords. Why is this necessary? What's wrong with just extending the current scheme with more roles? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword
On 10/22/2013 09:54 AM, Petr Viktorin wrote: On 10/22/2013 09:20 AM, Tomas Babej wrote: Hi, Adds support for host definition by a environment variables of the following form: KEYWORDHOST__envX, where X is the number of the environment for which host referenced by a keyword should be defined. You can also optionally use KEYWORDHOST__IP_envX to define the IP address directly, otherwise the framework will try to resolve the hostname. Adds a required_keyword_hosts attribute to the IntegrationTest class, which can test developer use to specify the keyword hosts that this particular test requires. If not all required keyword hosts are available, the test will be skipped. All keyword hosts are accessible to the IntegrationTests via the keyword_hosts attribute, which contains a dictionary keyed by the keywords. Why is this necessary? What's wrong with just extending the current scheme with more roles? The need for keyword hosts arised with the implementation of the legacy client test suite. As each of these tests needs a precise type (pre-defined and pre-configured) of VM, and not a generic client, you need to restrict the test case to specific host type. One test might be restricted to RHEL 5.10 with nss-pam-ldapd, another to FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with old version of SSSD... Each testcase that needs a new type of preconfigured host, we would need to introduce a new role, which would need to be integrated in the framework. In such implementation, we would lose loose coupling between the test framework and the test themselves, and make them less pluggable. HTH, -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests
Replying to one part only: On 10/21/2013 04:50 PM, Tomas Babej wrote: On 10/16/2013 03:44 PM, Petr Viktorin wrote: I still think it would be simpler if IPA and AD domains shared the numbering namespace (users would need to define $AD_env2; if they had $MASTER_env1 and $AD_env1 they would be in the same Domain). But if we use _env1 for both the AD and the IPA domain, they need to be separated in Domain.from_env. With patch 0101 both MASTER_env1 and AD_env1 will be in both domains[0] and ad_domains[0]. I would rather not join IPA and AD domains as they even cannot be in the same domain, as the service records would clash. So these will always be separate / sub / super domain relationship. You're right that they should never share the same domain. But you should never say never, especially in testing -- what if we'll want to, in the future, test that the records *do* clash, or that IPA refuses to install in an AD domain? Another problem is that they are now separate namespaces. In all code that deals with domains you have to deal separately with the list of AD domains and separately with IPA domains. This makes every piece of code that doesn't care much about what type of domain it's dealing with (configuration, listing, possible automation scripts for turning on the VMs, etc.) more complicated. Also, in this scheme, adding a new type of domain would be quite hard, especially after more code is written with this split in mind. Do keep the domain type, though. tl;dr I'd really prefer domain 1 (IPA); domain 2 (AD) rather than IPA domain 1; AD domain 1. If needed we can have a special check that would reject IPA masters in AD domains and vice versa, if that really turns out to be necessary. As we already pass ad_domain flag to Domain.from_env, I did incorporate code that joins the machines to the domain depending on the their role. Is that a viable solution for you? Sorry. I think this design is less sustainable than having a shared namespace for the domains. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][DOC] Configure sudo for FreeIPA 3.1.5
On 10/22/2013 02:41 AM, Dean Hunter wrote: This patch is only for the FreeIPA 3.1.5 User Guide. The 3.1.5 User Guide currently has a procedure carried over from the 2.2 User Guide. And the procedure will be different, again, for the 3.4 User Guide. The procedure is based on http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. https://fedorahosted.org/freeipa/ticket/3756 Hi Dean, Thanks for the patch! I have few comments though. 1) ipa-client-install in the first paragraph should be in code. I also think there should be a short introduction of the section instead of directly jumping to editing configs. I think that a modification of the previous one would work. Something like that: ~~~ Actually implementing sudo policies is more complicated than simply creating the rules in FreeIPA. Those rules need to be applied to every local machine, which means that each system in the FreeIPA domain has to be configured to refer to FreeIPA for its policies. This example specifically configures a Fedora client for sudo rules. The sudo on client is configured to use SSSD as a source of the policies: ... ~~~ 2) I see that in the configuration examples you already pasted executable scripts from your automation. However, I think that the echo and sed like examples will not bring enough clarity for the users. I would rather prefer the standard examples (as in other places in the guide) showing how the file should look like and leave the automation on user (if he needs it), i.e. ~~~ vim /etc/nsswitch.conf sudoers: files ldap ~~~ instead of ~~~ [root@ipaclient] ~]# echo sudoers:files sss /etc/nsswitch.conf ~~~ or ~~~ [domain/example.com] krb5_server = ipa.example.com ldap_sasl_authid = host/hostname.example.com ldap_sasl_mech = GSSAPI ldap_sasl_realm = EXAMPLE.COM ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_uri = ldap://ipa.example.com sudo_provider = ldap ~~~ instead of ~~~ [root@ipaclient] ~]# sed /^\[domain\/example.com\]/ a\\ krb5_server = ipa.example.com\\ ldap_sasl_authid = host/hostname.example.com\\ ldap_sasl_mech = GSSAPI\\ ldap_sasl_realm = EXAMPLE.COM\\ ldap_sudo_search_base = ou=sudoers,dc=example,dc=com\\ ldap_uri = ldap://ipa.example.com\\ sudo_provider = ldap /etc/sssd/sssd.conf ~~~ etc. This will make the examples easier to read and consistent with the rest of the guide. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword
On 10/22/2013 10:09 AM, Tomas Babej wrote: On 10/22/2013 09:54 AM, Petr Viktorin wrote: On 10/22/2013 09:20 AM, Tomas Babej wrote: Hi, Adds support for host definition by a environment variables of the following form: KEYWORDHOST__envX, where X is the number of the environment for which host referenced by a keyword should be defined. You can also optionally use KEYWORDHOST__IP_envX to define the IP address directly, otherwise the framework will try to resolve the hostname. Adds a required_keyword_hosts attribute to the IntegrationTest class, which can test developer use to specify the keyword hosts that this particular test requires. If not all required keyword hosts are available, the test will be skipped. All keyword hosts are accessible to the IntegrationTests via the keyword_hosts attribute, which contains a dictionary keyed by the keywords. Why is this necessary? What's wrong with just extending the current scheme with more roles? The need for keyword hosts arised with the implementation of the legacy client test suite. As each of these tests needs a precise type (pre-defined and pre-configured) of VM, and not a generic client, you need to restrict the test case to specific host type. One test might be restricted to RHEL 5.10 with nss-pam-ldapd, another to FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with old version of SSSD... Each testcase that needs a new type of preconfigured host, we would need to introduce a new role, which would need to be integrated in the framework. In such implementation, we would lose loose coupling between the test framework and the test themselves, and make them less pluggable. The framework itself (excluding the configuration part) should be able to handle this nicely using the existing role mechanism. It's true that in some places it's currently hard-wired to just a few roles, but supporting completely custom roles shouldn't be a problem. I'd prefer if this system was used, rather than basically adding a second role system, which we'd have to support even if we get rid of the current config part. The envvar-based configuration is not as flexible, but I'd rather make this part somewhat unpleasant than making the framework complex. We plan to move to a simpler configuration method anyway. That said, you can basically keep the variable name scheme you use in this patch; just maybe use TESTHOST rather than KEYWORDHOST. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][DOC] Configure sudo for FreeIPA 3.1.5
On Tue, 2013-10-22 at 10:39 +0200, Martin Kosek wrote: On 10/22/2013 02:41 AM, Dean Hunter wrote: This patch is only for the FreeIPA 3.1.5 User Guide. The 3.1.5 User Guide currently has a procedure carried over from the 2.2 User Guide. And the procedure will be different, again, for the 3.4 User Guide. The procedure is based on http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. https://fedorahosted.org/freeipa/ticket/3756 Hi Dean, Thanks for the patch! I have few comments though. 1) ipa-client-install in the first paragraph should be in code. I also think there should be a short introduction of the section instead of directly jumping to editing configs. I suggest to use commandipa-client-install/command. I think that a modification of the previous one would work. Something like that: ~~~ Actually implementing sudo policies is more complicated than simply creating the rules in FreeIPA. Those rules need to be applied to every local machine, which means that each system in the FreeIPA domain has to be configured to refer to FreeIPA for its policies. This example specifically configures a Fedora client for sudo rules. The sudo on client is configured to use SSSD as a source of the policies: ... ~~~ Here is something from SSSD presentation which can helps you too: The SSSD works as a middleman between sudo command and the FreeIPA server. The SSSD caches sudo rules for a period of time, what makes sudo works even if the network is offline. 2) I see that in the configuration examples you already pasted executable scripts from your automation. However, I think that the echo and sed like examples will not bring enough clarity for the users. I would rather prefer the standard examples (as in other places in the guide) showing how the file should look like and leave the automation on user (if he needs it), i.e. ~~~ vim /etc/nsswitch.conf sudoers: files ldap ~~~ instead of ~~~ [root@ipaclient] ~]# echo sudoers:files sss /etc/nsswitch.conf ~~~ or ~~~ [domain/example.com] krb5_server = ipa.example.com ldap_sasl_authid = host/hostname.example.com ldap_sasl_mech = GSSAPI ldap_sasl_realm = EXAMPLE.COM ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_uri = ldap://ipa.example.com sudo_provider = ldap ~~~ instead of ~~~ [root@ipaclient] ~]# sed /^\[domain\/example.com\]/ a\\ krb5_server = ipa.example.com\\ ldap_sasl_authid = host/hostname.example.com\\ ldap_sasl_mech = GSSAPI\\ ldap_sasl_realm = EXAMPLE.COM\\ ldap_sudo_search_base = ou=sudoers,dc=example,dc=com\\ ldap_uri = ldap://ipa.example.com\\ sudo_provider = ldap /etc/sssd/sssd.conf ~~~ etc. This will make the examples easier to read and consistent with the rest of the guide. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests
On 10/22/2013 10:37 AM, Petr Viktorin wrote: Replying to one part only: On 10/21/2013 04:50 PM, Tomas Babej wrote: On 10/16/2013 03:44 PM, Petr Viktorin wrote: I still think it would be simpler if IPA and AD domains shared the numbering namespace (users would need to define $AD_env2; if they had $MASTER_env1 and $AD_env1 they would be in the same Domain). But if we use _env1 for both the AD and the IPA domain, they need to be separated in Domain.from_env. With patch 0101 both MASTER_env1 and AD_env1 will be in both domains[0] and ad_domains[0]. I would rather not join IPA and AD domains as they even cannot be in the same domain, as the service records would clash. So these will always be separate / sub / super domain relationship. You're right that they should never share the same domain. But you should never say never, especially in testing -- what if we'll want to, in the future, test that the records *do* clash, or that IPA refuses to install in an AD domain? You could still set AD_env1 and MASTER_env1 to have the same domain. Another problem is that they are now separate namespaces. In all code that deals with domains you have to deal separately with the list of AD domains and separately with IPA domains. This makes every piece of code that doesn't care much about what type of domain it's dealing with (configuration, listing, possible automation scripts for turning on the VMs, etc.) more complicated. Also, in this scheme, adding a new type of domain would be quite hard, especially after more code is written with this split in mind. Do keep the domain type, though. tl;dr I'd really prefer domain 1 (IPA); domain 2 (AD) rather than IPA domain 1; AD domain 1. This will, however, require filtering the domains depending on the fact whether they contain AD or not. If a testcase wants to access an AD domain, it will still need to loop over the list of domains to see which ones are of AD type. Any code that does not care what domain type it's dealing with, can easily access all the domains by chaining the respective iterables. We could have a wrapper in the Config class for that, along the lines of get_all_domains(). So what I see here is that we're trading one complexity over another. I think we can agree on your approach since it hides the complexity from the user, especially in the ipa-test-config, which I admit is getting rather ugly, as we need to introduce new option there and that causes splitting. If needed we can have a special check that would reject IPA masters in AD domains and vice versa, if that really turns out to be necessary. With this check we should be fine. As we already pass ad_domain flag to Domain.from_env, I did incorporate code that joins the machines to the domain depending on the their role. Is that a viable solution for you? Sorry. I think this design is less sustainable than having a shared namespace for the domains. I'll send revised patchset soon. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH][DOC] Configure sudo for FreeIPA 3.1.5
On Tue, 2013-10-22 at 10:39 +0200, Martin Kosek wrote: On 10/22/2013 02:41 AM, Dean Hunter wrote: This patch is only for the FreeIPA 3.1.5 User Guide. The 3.1.5 User Guide currently has a procedure carried over from the 2.2 User Guide. And the procedure will be different, again, for the 3.4 User Guide. The procedure is based on http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. https://fedorahosted.org/freeipa/ticket/3756 Hi Dean, Thanks for the patch! I have few comments though. 1) ipa-client-install in the first paragraph should be in code. I also think there should be a short introduction of the section instead of directly jumping to editing configs. I think that a modification of the previous one would work. Something like that: ~~~ Actually implementing sudo policies is more complicated than simply creating the rules in FreeIPA. Those rules need to be applied to every local machine, which means that each system in the FreeIPA domain has to be configured to refer to FreeIPA for its policies. This example specifically configures a Fedora client for sudo rules. The sudo on client is configured to use SSSD as a source of the policies: ... ~~~ For this reason I considered moving the entire section to chapter 3, Setting up Systems as FreeIPA Clients. 2) I see that in the configuration examples you already pasted executable scripts from your automation. However, I think that the echo and sed like examples will not bring enough clarity for the users. I would rather prefer the standard examples (as in other places in the guide) showing how the file should look like and leave the automation on user (if he needs it), i.e. ~~~ vim /etc/nsswitch.conf sudoers: files ldap ~~~ instead of ~~~ [root@ipaclient] ~]# echo sudoers:files sss /etc/nsswitch.conf ~~~ or ~~~ [domain/example.com] krb5_server = ipa.example.com ldap_sasl_authid = host/hostname.example.com ldap_sasl_mech = GSSAPI ldap_sasl_realm = EXAMPLE.COM ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_uri = ldap://ipa.example.com sudo_provider = ldap ~~~ instead of ~~~ [root@ipaclient] ~]# sed /^\[domain\/example.com\]/ a\\ krb5_server = ipa.example.com\\ ldap_sasl_authid = host/hostname.example.com\\ ldap_sasl_mech = GSSAPI\\ ldap_sasl_realm = EXAMPLE.COM\\ ldap_sudo_search_base = ou=sudoers,dc=example,dc=com\\ ldap_uri = ldap://ipa.example.com\\ sudo_provider = ldap /etc/sssd/sssd.conf ~~~ etc. This will make the examples easier to read and consistent with the rest of the guide. What instead of How, got it. So even vim /etc/nsswitch.conf should not be specified, just list the changed lines of the affected file. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests
On 10/22/2013 12:27 PM, Tomas Babej wrote: On 10/22/2013 10:37 AM, Petr Viktorin wrote: Replying to one part only: On 10/21/2013 04:50 PM, Tomas Babej wrote: On 10/16/2013 03:44 PM, Petr Viktorin wrote: I still think it would be simpler if IPA and AD domains shared the numbering namespace (users would need to define $AD_env2; if they had $MASTER_env1 and $AD_env1 they would be in the same Domain). But if we use _env1 for both the AD and the IPA domain, they need to be separated in Domain.from_env. With patch 0101 both MASTER_env1 and AD_env1 will be in both domains[0] and ad_domains[0]. I would rather not join IPA and AD domains as they even cannot be in the same domain, as the service records would clash. So these will always be separate / sub / super domain relationship. You're right that they should never share the same domain. But you should never say never, especially in testing -- what if we'll want to, in the future, test that the records *do* clash, or that IPA refuses to install in an AD domain? You could still set AD_env1 and MASTER_env1 to have the same domain. Another problem is that they are now separate namespaces. In all code that deals with domains you have to deal separately with the list of AD domains and separately with IPA domains. This makes every piece of code that doesn't care much about what type of domain it's dealing with (configuration, listing, possible automation scripts for turning on the VMs, etc.) more complicated. Also, in this scheme, adding a new type of domain would be quite hard, especially after more code is written with this split in mind. Do keep the domain type, though. tl;dr I'd really prefer domain 1 (IPA); domain 2 (AD) rather than IPA domain 1; AD domain 1. This will, however, require filtering the domains depending on the fact whether they contain AD or not. If a testcase wants to access an AD domain, it will still need to loop over the list of domains to see which ones are of AD type. Any code that does not care what domain type it's dealing with, can easily access all the domains by chaining the respective iterables. We could have a wrapper in the Config class for that, along the lines of get_all_domains(). So what I see here is that we're trading one complexity over another. I think we can agree on your approach since it hides the complexity from the user, especially in the ipa-test-config, which I admit is getting rather ugly, as we need to introduce new option there and that causes splitting. If needed we can have a special check that would reject IPA masters in AD domains and vice versa, if that really turns out to be necessary. With this check we should be fine. As we already pass ad_domain flag to Domain.from_env, I did incorporate code that joins the machines to the domain depending on the their role. Is that a viable solution for you? Sorry. I think this design is less sustainable than having a shared namespace for the domains. I'll send revised patchset soon. Updated patchset attached. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From a23c379a865d5005539b7eb0ada76e36768b0f53 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Mon, 14 Oct 2013 16:37:55 +0200 Subject: [PATCH 106/107] ipatests: Add AD integration test case Part of: https://fedorahosted.org/freeipa/ticket/3834 --- ipatests/test_integration/test_trust.py | 182 1 file changed, 182 insertions(+) create mode 100644 ipatests/test_integration/test_trust.py diff --git a/ipatests/test_integration/test_trust.py b/ipatests/test_integration/test_trust.py new file mode 100644 index ..343c9785b0bd74b891638443e9699268e1366254 --- /dev/null +++ b/ipatests/test_integration/test_trust.py @@ -0,0 +1,182 @@ +# Authors: +# Tomas Babej tba...@redhat.com +# +# Copyright (C) 2013 Red Hat +# see file 'COPYING' for use and warranty information +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +import re + +from ipatests.test_integration.base import IntegrationTest +from ipatests.test_integration import tasks +from ipatests.test_integration import util + + +class ADTrustBase(IntegrationTest): +Provides common checks for the AD trust integration testing. + +topology = 'line' +
Re: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests
On 10/22/2013 02:15 PM, Tomas Babej wrote: On 10/22/2013 12:27 PM, Tomas Babej wrote: On 10/22/2013 10:37 AM, Petr Viktorin wrote: Replying to one part only: On 10/21/2013 04:50 PM, Tomas Babej wrote: On 10/16/2013 03:44 PM, Petr Viktorin wrote: I still think it would be simpler if IPA and AD domains shared the numbering namespace (users would need to define $AD_env2; if they had $MASTER_env1 and $AD_env1 they would be in the same Domain). But if we use _env1 for both the AD and the IPA domain, they need to be separated in Domain.from_env. With patch 0101 both MASTER_env1 and AD_env1 will be in both domains[0] and ad_domains[0]. I would rather not join IPA and AD domains as they even cannot be in the same domain, as the service records would clash. So these will always be separate / sub / super domain relationship. You're right that they should never share the same domain. But you should never say never, especially in testing -- what if we'll want to, in the future, test that the records *do* clash, or that IPA refuses to install in an AD domain? You could still set AD_env1 and MASTER_env1 to have the same domain. Another problem is that they are now separate namespaces. In all code that deals with domains you have to deal separately with the list of AD domains and separately with IPA domains. This makes every piece of code that doesn't care much about what type of domain it's dealing with (configuration, listing, possible automation scripts for turning on the VMs, etc.) more complicated. Also, in this scheme, adding a new type of domain would be quite hard, especially after more code is written with this split in mind. Do keep the domain type, though. tl;dr I'd really prefer domain 1 (IPA); domain 2 (AD) rather than IPA domain 1; AD domain 1. This will, however, require filtering the domains depending on the fact whether they contain AD or not. If a testcase wants to access an AD domain, it will still need to loop over the list of domains to see which ones are of AD type. Any code that does not care what domain type it's dealing with, can easily access all the domains by chaining the respective iterables. We could have a wrapper in the Config class for that, along the lines of get_all_domains(). So what I see here is that we're trading one complexity over another. I think we can agree on your approach since it hides the complexity from the user, especially in the ipa-test-config, which I admit is getting rather ugly, as we need to introduce new option there and that causes splitting. If needed we can have a special check that would reject IPA masters in AD domains and vice versa, if that really turns out to be necessary. With this check we should be fine. As we already pass ad_domain flag to Domain.from_env, I did incorporate code that joins the machines to the domain depending on the their role. Is that a viable solution for you? Sorry. I think this design is less sustainable than having a shared namespace for the domains. I'll send revised patchset soon. Updated patchset attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Attaching the patch 100 I missed. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From 6f2dc306542540f0db1c27f4efc301574bfdcf60 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 4 Sep 2013 14:12:28 +0200 Subject: [PATCH 100/107] ipatests: Add Active Directory support to configuration Part of: https://fedorahosted.org/freeipa/ticket/3834 --- ipatests/man/ipa-test-config.1 | 20 +++- ipatests/test_integration/config.py | 30 -- 2 files changed, 47 insertions(+), 3 deletions(-) diff --git a/ipatests/man/ipa-test-config.1 b/ipatests/man/ipa-test-config.1 index 4b998adb4f65265f4b0cfc49cac2979740562db5..a2fa96b57129b5adad3c15cfe7e97b8a6c9724d0 100644 --- a/ipatests/man/ipa-test-config.1 +++ b/ipatests/man/ipa-test-config.1 @@ -69,6 +69,11 @@ These are normally included for backwards compatibility. .SH ENVIRONMENT VARIABLES .TP +Domain configuration: +Domain is implicitly defined by _envX suffix of the environment variables, +if either AD_envX or MASTER_envX is defined. + +.TP Host configuration: .TP @@ -81,9 +86,14 @@ Host configuration: \fB$CLIENT\fR FQDNs of IPA clients (space-separated) .TP -\fB$MASTER_env2\fR, \fB$REPLICA_env2\fR, \fB$CLIENT_env2\fR, \fB$MASTER_env3\fR, ... +\fB$MASTER_env2\fR, \fB$REPLICA_env2\fR, \fB$CLIENT_env2\fR, \fB$MASTER_env3\fR, \fB$AD_env4\fR,... can be used for additional domains when needed .TP +\fB$AD_env1\fR, \fB$AD_env2\fR, \fB$AD_env3\fR, \fB$AD_env4\fR, ... +can be used to define Active Directory domains. Please note that these +domains are not separate from the IPA domains, so please
[Freeipa-devel] FreeIPA.org/Documentation improvements: request for comments
Hello list, here is never-ending discussion about freeipa.org wiki and documentation. Any opinions are more than welcome! (Each participating user will receive e-thank-you e-mail, I promise! :-D) We started the discussion privately and then realized that we should move it to mailing list, so some ideas are on the table. This doesn't mean that we have to stick with any of current proposals! Bring you ideas! On 22.10.2013 15:00, Simo Sorce wrote: On Tue, 2013-10-22 at 13:29 +0200, Martin Kosek wrote: On 10/21/2013 06:14 PM, Petr Spacek wrote: On 21.10.2013 16:24, Martin Kosek wrote: On 10/21/2013 03:54 PM, Dmitri Pal wrote: On 10/21/2013 04:28 AM, Petr Spacek wrote: [snip] http://www.freeipa.org/page/Documentation needs significant improvement, I agree. [snip] Sure. Though I am already tracking this page. Since summer, I have been continuously working on merging the documentation on FreeIPA (like some obscure Tips or three different FAQ sections), obsoleting information that is obsolete and adding warnings or moving v1/v2 development-specific documentation to specific name spaces to avoid them interfering with standard doc and other changes. I think the Documentation page is easier to digest already, compared to what was there before: http://www.freeipa.org/index.php?title=Documentationdiff=6912oldid=6203 So instead of FreeIPA.org wiki is wrong, awful and eats little puppies I would prefer to see some concrete ideas for improvements or better UX so that I can follow up on them and continue driving it to be better. Sure :-) Here are my proposals: Thank you! - move Developer Documentation away from /Documentation to separate page Why? It will make it less visible. I think that it contain a lot of useful information, even for users/power-users. I agree this will plunge us back to the old wiki which was bad. I don't belive that regular users search/read design docs. Is the design valueable for normal user? Then a) relevant information should be extracted to a article for users AND/OR b) the design page should be linked directly from Components/FAQ/how-to - move section By Component to the end of the page - it is mostly empty ... (of course, we can move it back to the beginning after some time!) Can be done, though it would be even better to simply add the component documentation - otherwise we are just hiding a missing doc, not fixing it. Indeed, my aim in creating the section was to highlight what people would like to see and entice some of us in producing more content. It is time we do. If we do it right we'll have great value for our users. And right is not hard, perhaps a bit tedious, but it is just about describing with medium level details the various components with particular care in describing how they interact with others (9bonus point if links between the various pages are provided when we mention interactions. Seem a good project for a new engineer that needs to go through and understand what is going on. By writing these pages he'll have to ask the right questions to older engineers and put them into words, I found it is an invaluable way to actually get to understand the big picture. My point is that the wiki should expose useful information *at the beginning*. I definitelly agree that filling the wiki with information is much better than hidding empty pages, but this great idea doesn't help to users looking for help right now. I propose to move Components to the end (or before Devel docs) for now - simply to make more valuable sections more visible. My intention is to make the /Documentation page more useful right now and I belive that this trivial re-ordering will help with that. Sure, we can move Components back as soon as it will contain some useful information. Does it explain my intention? - merge Additional Resources section with FreeIPA Training Series section and Public Presentations section How FAQ or HOWTOs relate to Training Series or Public Presentations? Or you just meant placing them close together? I also failed to understand this, they are completely different categories. The videos and presentations are for people that want generic info. The HowTo/Faqs are for peopl that have a specific problem and are looking for a solution. Exactly. That is what I proposed below - separate sections 'marketing' (high level stuff) and 'get your hands dirty' (the useful stuff). See below. - pull all how-tos to /Documentation I am not sure that placing all these articles directly to /Documentation would make it simpler. I understand /Documentation rather as a focal point of all documentation, which can lead you directly to the information you seek. I can see you point. The reply to this matter continues at the end of e-mail, I noticed that you wrote some other points about how-tos there. They should be in a Troubleshooting section at most, but they are clearly Documentation. I'm not following you. How is How to
[Freeipa-devel] [PATCH] 0076 Add test for external CA installation
Hello,
This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3819
--
Regards,
Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.
From 0bc373fe9a8d6f7ed1cc2cd82bf9a69f0a8613d5 Mon Sep 17 00:00:00 2001
From: Ana Krivokapic akriv...@redhat.com
Date: Tue, 22 Oct 2013 20:00:18 +0200
Subject: [PATCH] Add test for external CA installation
https://fedorahosted.org/freeipa/ticket/3819
---
ipatests/test_integration/test_external_ca.py | 107 ++
1 file changed, 107 insertions(+)
create mode 100644 ipatests/test_integration/test_external_ca.py
diff --git a/ipatests/test_integration/test_external_ca.py b/ipatests/test_integration/test_external_ca.py
new file mode 100644
index ..747990cff5d93a481a8032ed0e7be13cdb6f8d55
--- /dev/null
+++ b/ipatests/test_integration/test_external_ca.py
@@ -0,0 +1,107 @@
+# Authors:
+# Ana Krivokapic akriv...@redhat.com
+#
+# Copyright (C) 2013 Red Hat
+# see file 'COPYING' for use and warranty information
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+import os
+
+from ipatests.test_integration import tasks
+from ipatests.test_integration.base import IntegrationTest
+
+
+class TestExternalCA(IntegrationTest):
+
+Test of FreeIPA server installation with exernal CA
+
+def test_external_ca(self):
+# Step 1 of ipa-server-install
+self.master.run_command([
+'ipa-server-install', '-U',
+'-a', self.master.config.admin_password,
+'-p', self.master.config.dirman_password,
+'--setup-dns', '--no-forwarders',
+'-r', self.master.domain.name,
+'--external-ca'
+])
+
+nss_db = os.path.join(self.master.config.test_dir, 'testdb')
+external_cert_file = os.path.join(nss_db, 'ipa.crt')
+external_ca_file = os.path.join(nss_db, 'ca.crt')
+noisefile = os.path.join(self.master.config.test_dir, 'noise.txt')
+pwdfile = os.path.join(self.master.config.test_dir, 'pwdfile.txt')
+
+# Create noise and password files for NSS database
+self.master.run_command('date | sha256sum %s' % noisefile)
+self.master.run_command('echo %s %s' %
+(self.master.config.admin_password, pwdfile))
+
+# Create NSS database
+self.master.run_command(['mkdir', nss_db])
+self.master.run_command([
+'certutil', '-N',
+'-d', nss_db,
+'-f', pwdfile
+])
+
+# Create external CA
+self.master.run_command([
+'certutil', '-S',
+'-d', nss_db,
+'-f', pwdfile,
+'-n', 'external',
+'-s', 'CN=External CA, O=%s' % self.master.domain.name,
+'-x',
+'-t', 'CTu,CTu,CTu',
+'-g', '2048',
+'-m', '0',
+'-v', '60',
+'-z', noisefile,
+'-2', '-1', '-5'
+], stdin_text='5\n9\nn\ny\n10\ny\n5\n6\n7\n9\nn\n')
+
+# Sign IPA cert request using the external CA
+self.master.run_command([
+'certutil', '-C',
+'-d', nss_db,
+'-f', pwdfile,
+'-c', 'external',
+'-m', '1',
+'-v', '60',
+'-2', '-1', '-5',
+'-i', '/root/ipa.csr',
+'-o', external_cert_file,
+'-a'
+], stdin_text='0\n1\n5\n9\ny\ny\n\ny\n5\n6\n7\n9\nn\n')
+
+# Export external CA file
+self.master.run_command(
+'certutil -L -d %s -n external -a %s' %
+(nss_db, external_ca_file)
+)
+
+# Step 2 of ipa-server-install
+self.master.run_command([
+'ipa-server-install',
+'-a', self.master.config.admin_password,
+'-p', self.master.config.dirman_password,
+'--external_cert_file', external_cert_file,
+'--external_ca_file', external_ca_file
+])
+
+# Make sure IPA server is working properly
+tasks.kinit_admin(self.master)
+result = self.master.run_command(['ipa', 'user-show', 'admin'])
+assert 'User login: admin' in result.stdout_text
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
