Re: [Freeipa-devel] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows
Petr Viktorin wrote: > On 04/07/2016 10:12 PM, Niranjan wrote: > > Petr Viktorin wrote: > >> On 04/06/2016 10:55 AM, Niranjan wrote: > >>> Greetings, > >>> > >>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have > >>> proposed > >>> a patch, I think this patch is more of a workaround , than a solution. I > >>> would > >>> like to get more inputs on how to use pytest-multihost to execute > >>> commands > >>> on Windows. The method i am using requires cygwin with openssh/bash to be > >>> installed. > >> > >> Wow. I'm surprised the only problem on Windows is the "set -e". > >> > >> Regarding the patch: > >> > >> - Why is get_winhost_class needed? I don't see it called anywhere. > >> - Similarly, why is host_type needed? Your patch only sets it. > >> > >> If run_command of WinHost and Unix hosts are this similar, I would put > >> the 'set -e\n' for Unix (and an empty string for Windows) in a class > >> attribute named e.g. "command_prelude", use it in run_command, and move > >> run_command from Host to BaseHost. > >> Would that work, or am I missing something? > > yes, that would work. > > OK. Can you write a patch? yes, i will come up with a patch, > > > But there are few more suggestions, right now > > test_dir is global and for windows test_dir should be set to > > ~/$ssh_username/username. So can that also be set ? > > Yes. Add a configuration option to Host (in __init__, from_dict and > to_dict), and take the global default if not used. > > Then you can let Windows hosts default to either a hard-coded path, or > to a new global config option like "windows_test_dir". Okay , thanks for this input. > > > -- > Petr Viktorin pgp5Tgi9za4pc.pgp Description: PGP signature -- 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] 0051 Allow CustodiaClient to be used by arbitrary principals
On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote:
> On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote:
> > -name = gssapi.Name('host@%s' % (self.client,),
> >
> > - gssapi.NameType.hostbased_service)
>
> If you remove this then on a serve that has nfs keys in the keytab you
> may end up acquiring the wrong credentials.
> You need to pass down what credentials you want to use to initialize the
> cred store, we canot rely on ordering in the system keytab case.
>
> Simo.
>
Thanks Simo; updated patch attached.
From cfa2d1d95508c5ea9bb9bf59df6ae0c165f8fbde Mon Sep 17 00:00:00 2001
From: Fraser Tweedale
Date: Fri, 8 Apr 2016 15:21:19 +1000
Subject: [PATCH] Allow CustodiaClient to be used by arbitrary principals
Currently CustodiaClient assumes that the client is the host
principal, and it is hard-coded to read the host keytab and server
keys.
For the Lightweight CAs feature, Dogtag on CA replicas will use
CustodiaClient to retrieve signing keys from the originating
replica. Because this process runs as 'pkiuser', the host keys
cannot be used; instead, each Dogtag replica will have a service
principal to use for Custodia authentication.
Update CustodiaClient to allow specifying the keytab and Custodia
keyfile to use. Avoid hard-coding the service name to find in the
keytab. Also add an ACI to allow authenticated users to read and
search for Custodia server public keys.
Part of: https://fedorahosted.org/freeipa/ticket/4559
---
install/updates/20-aci.update | 3 +++
ipapython/secrets/client.py | 17 ++---
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index
4802ae0458e8b870bf3127764ebabac1a48f7cf2..16e3b7ab9d6cdcc1de0490f42447a17f8b769524
100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -136,3 +136,6 @@ add:aci: (target =
"ldap:///cn=replication,cn=etc,$SUFFIX";)(targetattr = "nsDS5R
dn: cn=ipa,cn=etc,$SUFFIX
add:aci: (target =
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA
server hosts can create own Custodia secrets"; allow(add) groupdn =
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX"; and userdn =
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
add:aci: (target =
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr =
"ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia
secrets"; allow(write) groupdn =
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX"; and userdn =
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+
+# Anyone can search Custodia public keys
+add:aci: (target =
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr =
"ipaPublicKey || ipaKeyUsage || memberPrincipal")(version 3.0; acl "Anyone can
search Custodia public keys"; allow(read, search, compare) userdn =
"ldap:///all";;)
diff --git a/ipapython/secrets/client.py b/ipapython/secrets/client.py
index
5b671988ddc66eedd9ae1cd4ddec0e1308bc5a93..a15057ae67c377a782db3642d14384e0bf11b5a2
100644
--- a/ipapython/secrets/client.py
+++ b/ipapython/secrets/client.py
@@ -41,16 +41,19 @@ class CustodiaClient(object):
return iSecStore(config)
-def __init__(self, client, server, realm, ldap_uri=None, auth_type=None):
-self.client = client
-self.creds = None
+def __init__(self, client, server, realm, ldap_uri=None, auth_type=None,
+client_servicename='host', keyfile=None, keytab=None):
+self.client_service = '%s@%s' % (client_servicename, client)
+self.keytab = keytab or paths.KRB5_KEYTAB
+self.creds = self.init_creds()
self.service_name = gssapi.Name('HTTP@%s' % (server,),
gssapi.NameType.hostbased_service)
self.server = server
-keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys')
-self.ikk = IPAKEMKeys({'server_keys': keyfile})
+if keyfile is None:
+keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys')
+self.ikk = IPAKEMKeys({'server_keys': keyfile, 'ldap_uri': ldap_uri})
self.kemcli = KEMClient(self._server_keys(server, realm),
self._client_keys())
@@ -61,9 +64,9 @@ class CustodiaClient(object):
requests.packages.urllib3.disable_warnings()
def init_creds(self):
-name = gssapi.Name('host@%s' % (self.client,),
+name = gssapi.Name(self.client_service,
gssapi.NameType.hostbased_service)
-store = {'client_keytab': paths.KRB5_KEYTAB,
+store = {'client_keytab': self.keytab,
'ccache': 'MEMORY:Custodia_%s' % b64encode(os.urandom(8))}
return gssapi.Credentials(name=name, store=store, usage='initiate')
--
2.5.5
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.
Re: [Freeipa-devel] [DESIGN] Server Roles
On 04/07/2016 10:28 AM, Petr Spacek wrote: On 6.4.2016 16:37, Martin Babinsky wrote: On 03/21/2016 09:28 AM, Jan Cholasta wrote: On 17.3.2016 18:16, Martin Babinsky wrote: Hi list, here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP design document concerning the concept of Server Roles as a user-friendly abstraction of the services running on IPA masters. The main aim of this feature is to provide a higher level interface to query and manipulate service-related information stored in dirsrv backend. I have not touched the design much from the post-Devconf session, mainly because there are some points to clarify and agree upon. I have the following points to discuss: 1.) the design assumes that there is a distinction between roles such as DNS server, CA, etc. and the more specific sub-roles such as DNSSec key master, CRL master, etc. Now in the hindsight I think this distinction is quite artificial and just clutters the interface unnecessarily. We might implement this kind of hierarchy in the code itself but that is something the user needs not be aware of. These shouldn't be (sub-)roles at all - they are inherently a one-to-many relationship between the logical services and servers, whereas roles are many-to-many relationship between the logical services and servers. I would rather see them exposed in the global service config, such as: $ ipa dnsconfig-mod --sec-master=ipa12.example.com DNSSEC master: ipa12.example.com 2.) I guess the role names should be case insensitive so that users are not hindered by trying to get the case right. +1 3.) Do we need an internal API call which will add all services belonging to a role to the corresponding master entry? (basically a 'server_add_role' type of command). Currently, each service instance adds its own service entry during service installation so we probably do not need to duplicate this functionality. +1, we don't need more duplicate code. That is all I can think of right now. I had many more questions popping up during this night's bout of insomnia, but they got lost during the day. How are we going to expose the different states of server roles? They can be: a) available/unavailable (the package providing the role was/was not installed on the server) b) configured/unconfigured (the installer for the role was/was not successfully run on the server, LDAP service entries exist) c) enabled/disabled My preference would be to make server-role commands work on top of available services, like this: # ipa server-role-show $HOSTNAME DNS ipa: ERROR: DNS: server role not found # dnf install freeipa-server-dns ... # ipa server-role-show $HOSTNAME DNS Name: DNS Configured: False Enabled: False # ipa-dns-install ... # ipa server-role-show $HOSTNAME DNS Name: DNS Configured: True Enabled: True Do not be afraid to bring up other questions/remarks/comments. This is my first design documents so I expect them to be plenty. The CLI commands are a little bit self-inconsistent, see any other plugin for how the general layout of arguments should look like. I have updated the design page[1] according to the comments gathered in this thread and offline discussion with principal reviewer, e.g. Jan. Again comments are welcome. [1] http://www.freeipa.org/page/V4/Server_Roles Hi, I wonder if proposed service list->role and ipaConfigString value->server attribute mappings will work for DNSSEC key master. DNS server consist of named-pkcs11 and ipa-dnskeysyncd services. DNSSEC key master adds opendnssec and ipa-ods-exporter services. Can this be represented in the described model? I'm not sure. Yes that is something I was not quite sure about whether DNSSec master is more defined by the presence of ipaConfigString or by presence of relevant service entries. We can do both approaches since the mapping between roles/attributes and service entries has to be quite flexible anyway. -- Martin^3 Babinsky -- 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 0143-0144] different errors/warnings for different LDAP limit type exceeded
On 04/01/2016 05:37 PM, Martin Babinsky wrote:
On 03/24/2016 04:14 PM, Martin Babinsky wrote:
On 03/22/2016 04:28 PM, Rob Crittenden wrote:
Martin Babinsky wrote:
On 03/21/2016 12:25 PM, Jan Cholasta wrote:
On 21.3.2016 10:17, Petr Spacek wrote:
On 18.3.2016 13:49, Rob Crittenden wrote:
Martin Babinsky wrote:
These patches implement behavior agreed upon during discussion of
https://fedorahosted.org/freeipa/ticket/5677
However I'm not sure if we want to push them into 4-3 branch (the
ticket
is triaged into 4.3.2 milestone) since they modify the framework
behavior quite a bit.
If there is no need to have it there (CC'ing Milan since he is the
reporter), I would retriage it into 4.4 milestone.
+ desc="while getting entries (search base: '{}',"
+ "filter: {})".format(base_dn, filter))
This is going to expose parts of the DIT in an error message to
users. We have
tried in the past to hide the implementation. I'd propose logging
the
error
and making the exception less verbose.
I agree with Rob here, we shouldn't expose internal stuff in error
messages for users.
In this particular case, even if we included internal stuff in the
error
message, it should be the error message returned by the server rather
than this ad-hoc message.
IMHO it actually helps to print the DN. At very least the user can
see
if the
error is happening always with the same DN or if it keeps changing.
In other words, for user it is not that important to understand
meaning of the
DN but it might be important to see if it is the same or not.
I can't imagine a situation where it would actually be useful for the
user (as opposed to the admin, who has access to logs) to know the
base
DN of some arbitrary LDAP search operation. Could you give an example?
Right, attaching updated patches.
I may have suggested debug logging the detailed error. I was wrong. This
should log at the error level so it always appears in the logs. This may
be a spurious error and having the user turn on debug logging to capture
the reasons would be asking a lot.
rob
That's right, the user would then have to enable debug mode and re-run
the command. I have changed the log level to error as you suggested.
Bump for review.
Moar bumps.
--
Martin^3 Babinsky
--
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
[Freeipa-devel] [DESIGN] Kerberos principal alias handling
Hi list, I have put together a draft [1] outlining the effort to reimplement the handling of Kerberos principals in both backend and frontend layers of FreeIPA so that we may have multiple aliases per user, host or service and thus implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and https://fedorahosted.org/freeipa/ticket/5413 . Since much of the plumbing was already implemented,[2] the document mainly describes what the patches do. Some parts required by other use cases may be missing so please point these out. I would also be happy if you could correct all factual inacurracies, I did research on this issue a long time ago and my knowledge turned a bit rusty. [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html -- Martin^3 Babinsky -- 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] 0051 Allow CustodiaClient to be used by arbitrary principals
On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote:
> -name = gssapi.Name('host@%s' % (self.client,),
>
> - gssapi.NameType.hostbased_service)
If you remove this then on a serve that has nfs keys in the keytab you
may end up acquiring the wrong credentials.
You need to pass down what credentials you want to use to initialize the
cred store, we canot rely on ordering in the system keytab case.
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] ca-less tests updated
Hi all,
It's been a while, and now the patch seems to be stable. It does hit one
known issue with replica installation occationally [1], but other than
that works fine on both domain levels.
[1] https://fedorahosted.org/freeipa/ticket/5758
From a773c297f37340f36cf257a2b5b75eb8199bd47d Mon Sep 17 00:00:00 2001
From: Oleg Fayans
Date: Tue, 8 Dec 2015 10:49:18 +0100
Subject: [PATCH] Updated the script creating test certificate chains
https://fedorahosted.org/freeipa/ticket/4589
---
.../test_integration/scripts/caless-create-pki | 29 ++
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/ipatests/test_integration/scripts/caless-create-pki b/ipatests/test_integration/scripts/caless-create-pki
index f428ebae16e05644a875a35faf192f75eb149740..4c37077ffdecfb0c70663c7c4817f102154d3b26 100644
--- a/ipatests/test_integration/scripts/caless-create-pki
+++ b/ipatests/test_integration/scripts/caless-create-pki
@@ -3,7 +3,17 @@
profile_ca=(-t CT,C,C -v 120)
profile_server=(-t ,, -v 12)
-crl_path=${crl_path-$(readlink -f $dbdir)}
+# crl_path=${crl_path-$(readlink -f $dbdir)}
+profile_ca_request_options=(-1 -2 -4)
+profile_ca_request_input="\$'0\n1\n5\n6\n9\ny\ny\n\ny\n1\n7\nfile://'\$(readlink -f \$dbdir)/\$ca.crl\$'\n-1\n-1\n-1\nn\nn\n'"
+profile_ca_create_options=(-v 120)
+profile_ca_add_options=(-t ,,)
+
+profile_server_request_options=(-4)
+profile_server_request_input="\$'1\n7\nfile://'\$(readlink -f \$dbdir)/\$ca.crl\$'\n-1\n-1\n-1\nn\nn\n'"
+profile_server_create_options=(-v 12)
+profile_server_add_options=(-t ,,)
+
serial_number=0
@@ -18,7 +28,11 @@ gen_cert() {
ca="$nick"
fi
+echo $profile
eval "options=(\"\${profile_$profile[@]}\")"
+eval "request_options=(\"\${profile_${profile}_request_options[@]}\")"
+eval "eval request_input=(\"\${profile_${profile}_request_input[@]}\")"
+
if [ "$ca" = "$nick" ]; then
options=("${options[@]}" -x -m 1)
else
@@ -38,16 +52,7 @@ gen_cert() {
csr="$(mktemp)"
crt="$(mktemp)"
-certutil -R -d "$dbdir" -s "$subject" -f "$pwfile" -z "$noise" -o "$csr" -4 >/dev/null
[Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals
Hi all,
The attached patch (first of many for long-awaited sub-CAs feature)
makes it possible to use CustodiaClient without root privileges, as
an arbitrary principal.
Cheers,
Fraser
From 8e6cab0e47dd4e3152d8bbd84c8675353aa2cb4a Mon Sep 17 00:00:00 2001
From: Fraser Tweedale
Date: Fri, 8 Apr 2016 15:21:19 +1000
Subject: [PATCH] Allow CustodiaClient to be used by arbitrary principals
Currently CustodiaClient assumes that the client is the host
principal, and it is hard-coded to read the host keytab and server
keys.
For the Lightweight CAs feature, Dogtag on CA replicas will use
CustodiaClient to retrieve signing keys from the originating
replica. Because this process runs as 'pkiuser', the host keys
cannot be used; instead, each Dogtag replica will have a service
principal to use for Custodia authentication.
Update CustodiaClient to allow specifying the keytab and Custodia
keyfile to use. Avoid hard-coding the GSS-API name; use the name
read from the keytab during credential acquisition. Also add an ACI
to allow authenticated users to read and search for Custodia server
public keys.
Part of: https://fedorahosted.org/freeipa/ticket/4559
---
install/updates/20-aci.update | 3 +++
ipapython/secrets/client.py | 17 +
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index
4802ae0458e8b870bf3127764ebabac1a48f7cf2..16e3b7ab9d6cdcc1de0490f42447a17f8b769524
100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -136,3 +136,6 @@ add:aci: (target =
"ldap:///cn=replication,cn=etc,$SUFFIX";)(targetattr = "nsDS5R
dn: cn=ipa,cn=etc,$SUFFIX
add:aci: (target =
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA
server hosts can create own Custodia secrets"; allow(add) groupdn =
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX"; and userdn =
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
add:aci: (target =
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr =
"ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia
secrets"; allow(write) groupdn =
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX"; and userdn =
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+
+# Anyone can search Custodia public keys
+add:aci: (target =
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr =
"ipaPublicKey || ipaKeyUsage || memberPrincipal")(version 3.0; acl "Anyone can
search Custodia public keys"; allow(read, search, compare) userdn =
"ldap:///all";;)
diff --git a/ipapython/secrets/client.py b/ipapython/secrets/client.py
index
5b671988ddc66eedd9ae1cd4ddec0e1308bc5a93..33172e58095fcfd2469c0ea5ea597fd1a01c2907
100644
--- a/ipapython/secrets/client.py
+++ b/ipapython/secrets/client.py
@@ -41,16 +41,19 @@ class CustodiaClient(object):
return iSecStore(config)
-def __init__(self, client, server, realm, ldap_uri=None, auth_type=None):
+def __init__(self, client, server, realm, ldap_uri=None, auth_type=None,
+keyfile=None, keytab=None):
self.client = client
-self.creds = None
+self.keytab = keytab or paths.KRB5_KEYTAB
+self.creds = self.init_creds()
self.service_name = gssapi.Name('HTTP@%s' % (server,),
gssapi.NameType.hostbased_service)
self.server = server
-keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys')
-self.ikk = IPAKEMKeys({'server_keys': keyfile})
+if keyfile is None:
+keyfile = os.path.join(paths.IPA_CUSTODIA_CONF_DIR, 'server.keys')
+self.ikk = IPAKEMKeys({'server_keys': keyfile, 'ldap_uri': ldap_uri})
self.kemcli = KEMClient(self._server_keys(server, realm),
self._client_keys())
@@ -61,11 +64,9 @@ class CustodiaClient(object):
requests.packages.urllib3.disable_warnings()
def init_creds(self):
-name = gssapi.Name('host@%s' % (self.client,),
- gssapi.NameType.hostbased_service)
-store = {'client_keytab': paths.KRB5_KEYTAB,
+store = {'client_keytab': self.keytab,
'ccache': 'MEMORY:Custodia_%s' % b64encode(os.urandom(8))}
-return gssapi.Credentials(name=name, store=store, usage='initiate')
+return gssapi.Credentials(store=store, usage='initiate')
def _auth_header(self):
if not self.creds or self.creds.lifetime < 300:
--
2.5.5
--
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] [python-pytest-multihost]-Ticket-6 run_command produces exit code 1 on windows
On 04/07/2016 10:12 PM, Niranjan wrote: > Petr Viktorin wrote: >> On 04/06/2016 10:55 AM, Niranjan wrote: >>> Greetings, >>> >>> For https://fedorahosted.org/python-pytest-multihost/ticket/6 , i have >>> proposed >>> a patch, I think this patch is more of a workaround , than a solution. I >>> would >>> like to get more inputs on how to use pytest-multihost to execute commands >>> on Windows. The method i am using requires cygwin with openssh/bash to be >>> installed. >> >> Wow. I'm surprised the only problem on Windows is the "set -e". >> >> Regarding the patch: >> >> - Why is get_winhost_class needed? I don't see it called anywhere. >> - Similarly, why is host_type needed? Your patch only sets it. >> >> If run_command of WinHost and Unix hosts are this similar, I would put >> the 'set -e\n' for Unix (and an empty string for Windows) in a class >> attribute named e.g. "command_prelude", use it in run_command, and move >> run_command from Host to BaseHost. >> Would that work, or am I missing something? > yes, that would work. OK. Can you write a patch? > But there are few more suggestions, right now > test_dir is global and for windows test_dir should be set to > ~/$ssh_username/username. So can that also be set ? Yes. Add a configuration option to Host (in __init__, from_dict and to_dict), and take the global default if not used. Then you can let Windows hosts default to either a hard-coded path, or to a new global config option like "windows_test_dir". -- Petr Viktorin -- 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
[Freeipa-devel] [TESTS][PATCH] Ping module tests in a non-declarative way
From c985749e3e380df75c83f0233808c31229bc9162 Mon Sep 17 00:00:00 2001
From: root
Date: Fri, 8 Apr 2016 10:04:14 +0200
Subject: [PATCH] Ping module tests.
Test for ping module rewritten using non-declarative way.
No new functionality has been added.
---
ipatests/test_xmlrpc/test_ping_plugin.py | 49
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/ipatests/test_xmlrpc/test_ping_plugin.py b/ipatests/test_xmlrpc/test_ping_plugin.py
index afd34fa1482735ac802b57a5d6cd387b18574f89..46cfaceeddf6625f1cea0e36bc4303a54467565e 100644
--- a/ipatests/test_xmlrpc/test_ping_plugin.py
+++ b/ipatests/test_xmlrpc/test_ping_plugin.py
@@ -1,7 +1,8 @@
# Authors:
# Petr Viktorin
+# Peter Lacko
#
-# Copyright (C) 2012 Red Hat
+# Copyright (C) 2016 Red Hat
# see file 'COPYING' for use and warranty information
#
# This program is free software; you can redistribute it and/or modify
@@ -21,34 +22,32 @@
Test the `ipalib/plugins/ping.py` module, and XML-RPC in general.
"""
-from ipalib import errors, _
-from ipatests.util import Fuzzy
-from ipatests.test_xmlrpc.xmlrpc_test import Declarative
import pytest
+from ipalib import errors, _
+from ipatests.test_xmlrpc.tracker.base import Tracker
+from ipatests.util import assert_equal, Fuzzy
+from xmlrpc_test import XMLRPC_test, raises_exact
+
@pytest.mark.tier1
-class test_ping(Declarative):
+class TestPing(XMLRPC_test):
+"""Test functionality of the `ipalib/plugins/ping.py` module."""
+tracker = Tracker()
-tests = [
-dict(
-desc='Ping the server',
-command=('ping', [], {}),
-expected=dict(
-summary=Fuzzy('IPA server version .*. API version .*')),
-),
+def test_ping(self):
+"""Ping the server."""
+result = self.tracker.run_command('ping')
+exp = {'summary': Fuzzy('IPA server version .*. API version .*')}
+assert_equal(result, exp)
-dict(
-desc='Try to ping with an argument',
-command=('ping', ['bad_arg'], {}),
-expected=errors.ZeroArgumentError(name='ping'),
-),
+def test_ping_with_argument(self):
+"""Try to ping with an argument."""
+with raises_exact(errors.ZeroArgumentError(name='ping')):
+self.tracker.run_command('ping', ['argument'])
-dict(
-desc='Try to ping with an option',
-command=('ping', [], dict(bad_arg=True)),
-expected=errors.OptionError(_('Unknown option: %(option)s'),
-option='bad_arg'),
-),
-
-]
+def test_ping_with_option(self):
+"""Try to ping with an option."""
+with raises_exact(errors.OptionError(
+_('Unknown option: %(option)s'), option='bad_arg')):
+self.tracker.run_command('ping', bad_arg=True)
--
2.5.5
--
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
