Re: [Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options
On 11/06/2015 10:30 AM, Martin Babinsky wrote:
https://fedorahosted.org/freeipa/ticket/5433
Attaching updated patch.
--
Martin^3 Babinsky
From 72bec020ac98095836593ae7f04c922632f5c885 Mon Sep 17 00:00:00 2001
From: Martin Babinsky
Date: Fri, 6 Nov 2015 10:05:42 +0100
Subject: [PATCH] fix error reporting when installer option is supplied with
invalid choice
https://fedorahosted.org/freeipa/ticket/5433
---
ipapython/install/cli.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ipapython/install/cli.py b/ipapython/install/cli.py
index d2250e51650b9de1c85473399e3462f42bf8770b..7cc3a9c395cb9326112f9235ec24ee38ff897eb8 100644
--- a/ipapython/install/cli.py
+++ b/ipapython/install/cli.py
@@ -218,7 +218,8 @@ class ConfigureTool(admintool.AdminTool):
if value not in value_type:
raise ValueError(
"invalid choice {0} (choose from {1})".format(
-repr(value), ', '.join(repr(value_type
+str(value), ', '.join(
+sorted(str(v) for v in value_type
return value
else:
parse = value_type
--
2.4.3
--
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 0090] show optionally configured components in server-find/show command output
On 11/06/2015 10:10 AM, Petr Spacek wrote:
On 6.11.2015 10:00, Martin Babinsky wrote:
On 11/02/2015 12:56 PM, Martin Babinsky wrote:
On 10/30/2015 11:53 AM, Martin Babinsky wrote:
On 10/26/2015 01:41 PM, Martin Babinsky wrote:
On 10/22/2015 04:13 PM, Martin Basti wrote:
On 22.10.2015 10:44, Martin Babinsky wrote:
https://fedorahosted.org/freeipa/ticket/5181
Thank you for the patch.
1)
+OPTIONAL_SERVICES = {
+'DNS',
+'CA',
+'KRA',
+'ADTRUST',
+'EXTID',
+'DNSKeyExporter',
+'DNSSEC',
+'DNSKeySync',
+}
This did not scale well, maybe we should improve it to use some general
solution for whole IPA to distinct mandratory and optionl service,
but I
do not know how (or if it is possible)
Yes this does not scale well. After some playing around with relocating
the SERVICE_LIST object in 'ipaserver/install/service.py' I found out
that more refactoring would be needed to improve the layout and
availability of LDAP service names to both server and client code. I
have put the list of core services to ipalib/constants.py for now, and I
suggest to open a separate ticket for more general solution.
2)
+search_filter=('(&(objectclass=ipaConfigObject)'
+ '(ipaConfigString=enabledService))')
Common user cannot read ipaConfigString, so this will work only for
admins, I do not see any limitations of access in code for other users.
I think that you agreed with Petr^2 that this filter is OK. I left it as
it is but I have rewritten it as a call to ldap.make_filter to improve
readability and/or potential extensibility a bit.
3)
+opt_components = [
+r['cn'][0] for r in result if r['cn'][0] in
OPTIONAL_SERVICES
+]
Probably instead of indexing, you may use result.single_value['cn']
Martin^2
Attaching updated patch.
Self-NACK, I found a bug in the patch during work on topology management
stuff.
Attaching updated patch.
Bump for review.
I apologize for the delay, ACK!
NACKed by commitee until further notice.
--
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 0090] show optionally configured components in server-find/show command output
On 11/06/2015 01:09 PM, Martin Babinsky wrote: On 11/06/2015 11:06 AM, Petr Vobornik wrote: On 11/06/2015 10:15 AM, Petr Spacek wrote: On 6.11.2015 09:25, Martin Kosek wrote: On 11/05/2015 07:02 PM, Petr Vobornik wrote: On 11/02/2015 12:37 PM, Martin Kosek wrote: On 11/02/2015 06:10 AM, Jan Cholasta wrote: Hi, On 22.10.2015 10:44, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5181 This should be handled by a separate object plugin: $ ipa servercomponent-find master.ipa.test --- 6 server components matched --- Component name: CA Enabled: TRUE Start order: 50 Component name: KDC Enabled: TRUE Start order: 10 Component name: KPASSWD Enabled: TRUE Start order: 20 Component name: MEMCACHE Enabled: TRUE Start order: 39 Component name: OTPD Enabled: TRUE Start order: 80 Component name: HTTP Enabled: TRUE Start order: 40 Number of entries returned 6 This will allow us to consolidate all the ad-hoc component-related code scattered throughout IPA (search for enable component, enable/disable component, ...) into IPA command calls. I'm not opposed to showing a summary in server-show (although we don't do anything like this for any other hierarchical objects), but it should be done just for the users' sake, not for internal use (the ticket suggests to use this for topology visualisation). BTW as far as the scalability of the current solution goes, you should have a list of all the *non*-optional components and display everything else. The API proposal should be in line with our future extensions of the API. We for example want to move "ipa-csreplica-manage" set-renewal-master command to API call. Or DNSSEC generation master. Or we may want to change some other flag/role of a master via this interface. So we will need something like $ ipa server-add-role ipa.example.com --role "ca-renewal-master" or $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master Depends on usage. If we want to internally unify manipulation with configs for component we can create low-level commands which won't be exposed to CLI. E.g. ipa servercomponent-find ipa.example.com Component name: ADTRUST Config: enabledService, startOrder 60 This is all what Web UI needs. From user perspective, for CLI, something different is better. Martin used term 'role', lets go with that. Idea 1: $ ipa server-show ipa.example.com --roles Server name: vm-073.idm.lab.eng.brq.redhat.com Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Role: dns-server, cs-server, ca-renewal-master, trust-controller --all would imply --roles I am thinking "Roles" could be printed out even in default listing. It looks as an important piece of information you want to know about your master. I also originally used that with servercomponent, you moved it to server itself. It makes also sense. We will need a design for this servercomponent/roles anyway, to agree on the API with all stakeholders. $ ipa server-add-role ipa.example.com --roles=ca-renewal-master Just keep in mind that 'role' design requires yet another layer of indirection because there is no 1:1 mapping between services and roles. E.g. 'DNSSEC key master' role consists of several services, as 'DNS server' role etc. Also, we can get into trouble because role 'DNS server' in IPA 4.2 can contain different set of services than 'DNS server' in IPA 5.0 etc. For these reasons I question necessity of 'role' abstraction. Is it worth? IMO yes. Current patch is better than nothing but roles are more friendly, components are implementation detail. Showing only CNs on components doesn't show all info. E.g. ipa server-show `hostname` Server name: ipa.example.com Managed suffix: dc=example,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA This doesn't show that the server is actually also a ca-renewal-master. What is the command I can use to solve: "show me what server is the ca-renewal-master"? In that case we would IMHO need to redesign the whole service to LDAP mapping to incorporate server roles in some sane and scalable way. I'm not sure if that fits in the 4.3 timeframe. If yes, the we should first start with first putting the plumbing in and then adding API calls on top. It is not a blocker for 4.3. Issue here is that we are discussing implementation and API purity without use-cases. The result doesn't have to be something big in the end. So far the only real use case was a consumption by Web UI for topology visualization. This definitely won't be part of 4.3. And Web UI will do exactly what I wrote here(hidden behind term "role". Just display which servers are: - vault backend (KRA) - CS - ca-renewal-master -
[Freeipa-devel] [PATCH] 0001 Refactor test_user_plugin
>From 881f5f980e820f178850307c0f64e3eb50cbc01e Mon Sep 17 00:00:00 2001
From: Filip Skola
Date: Fri, 6 Nov 2015 10:57:37 +0100
Subject: [PATCH] Refactor test_user_plugin, use UserTracker for tests
---
ipatests/test_xmlrpc/test_user_plugin.py | 2794 +-
1 file changed, 1182 insertions(+), 1612 deletions(-)
diff --git a/ipatests/test_xmlrpc/test_user_plugin.py b/ipatests/test_xmlrpc/test_user_plugin.py
index 3d7b5e6ba14e3ccb144575f52e4e503e6638037d..ede6a339a519dfd40fd7507ee644f1cab0d4503c 100644
--- a/ipatests/test_xmlrpc/test_user_plugin.py
+++ b/ipatests/test_xmlrpc/test_user_plugin.py
@@ -2,6 +2,7 @@
# Rob Crittenden
# Pavel Zuna
# Jason Gerard DeRose
+# Filip Skola
#
# Copyright (C) 2008, 2009 Red Hat
# see file 'COPYING' for use and warranty information
@@ -23,6 +24,7 @@
Test the `ipalib/plugins/user.py` module.
"""
+import pytest
import functools
import datetime
import ldap
@@ -33,40 +35,37 @@ from ipatests.test_xmlrpc import objectclasses
from ipatests.util import (
assert_equal, assert_not_equal, raises, assert_deepequal)
from xmlrpc_test import (
-XMLRPC_test, Declarative, fuzzy_digits, fuzzy_uuid, fuzzy_password,
+XMLRPC_test, fuzzy_digits, fuzzy_uuid, fuzzy_password,
fuzzy_string, fuzzy_dergeneralizedtime, add_sid, add_oc, raises_exact)
from ipapython.dn import DN
from ipatests.test_xmlrpc.ldaptracker import Tracker
-user1 = u'tuser1'
-user2 = u'tuser2'
admin1 = u'admin'
-admin2 = u'admin2'
-renameduser1 = u'tuser'
group1 = u'group1'
-admins_group = u'admins'
+admin_group = u'admins'
invaliduser1 = u'+tuser1'
invaliduser2 = u'tuser1234567890123456789012345678901234567890'
sshpubkey = (u'ssh-rsa B3NzaC1yc2EDAQABAAABAQDGAX3xAeLeaJggwTqMjxNwa6X'
- 'HBUAikXPGMzEpVrlLDCZtv00djsFTBi38PkgxBJVkgRWMrcBsr/35lq7P6w8KGI'
- 'wA8GI48Z0qBS2NBMJ2u9WQ2hjLN6GdMlo77O0uJY3251p12pCVIS/bHRSq8kHO2'
- 'No8g7KA9fGGcagPfQH+ee3t7HUkpbQkFTmbPPN++r3V8oVUk5LxbryB3UIIVzNm'
- 'cSIn3JrXynlvui4MixvrtX6zx+O/bBo68o8/eZD26QrahVbA09fivrn/4h3TM01'
- '9Eu/c2jOdckfU3cHUV/3Tno5d6JicibyaoDDK7S/yjdn5jhaz8MSEayQvFkZkiF'
- '0L public key test')
+ 'HBUAikXPGMzEpVrlLDCZtv00djsFTBi38PkgxBJVkgRWMrcBsr/35lq7P6w8KGI'
+ 'wA8GI48Z0qBS2NBMJ2u9WQ2hjLN6GdMlo77O0uJY3251p12pCVIS/bHRSq8kHO2'
+ 'No8g7KA9fGGcagPfQH+ee3t7HUkpbQkFTmbPPN++r3V8oVUk5LxbryB3UIIVzNm'
+ 'cSIn3JrXynlvui4MixvrtX6zx+O/bBo68o8/eZD26QrahVbA09fivrn/4h3TM01'
+ '9Eu/c2jOdckfU3cHUV/3Tno5d6JicibyaoDDK7S/yjdn5jhaz8MSEayQvFkZkiF'
+ '0L public key test')
sshpubkeyfp = (u'13:67:6B:BF:4E:A2:05:8E:AE:25:8B:A1:31:DE:6F:1B '
-'public key test (ssh-rsa)')
+ 'public key test (ssh-rsa)')
-validlanguage1 = u'en-US;q=0.987 , en, abcdfgh-abcdefgh;q=1, a;q=1.000'
-validlanguage2 = u'*'
+validlanguages = {
+u'en-US;q=0.987 , en, abcdfgh-abcdefgh;q=1, a;q=1.000',
+u'*'
+}
-invalidlanguage1 = u'abcdfghji-abcdfghji'
-invalidlanguage2 = u'en-us;q=0,123'
-invalidlanguage3 = u'en-us;q=0.1234'
-invalidlanguage4 = u'en-us;q=1.1'
-invalidlanguage5 = u'en-us;q=1.'
+invalidlanguages = {
+u'abcdfghji-abcdfghji', u'en-us;q=0,123',
+u'en-us;q=0.1234', u'en-us;q=1.1', u'en-us;q=1.'
+}
principal_expiration_string = "2020-12-07T19:54:13Z"
principal_expiration_date = datetime.datetime(2020, 12, 7, 19, 54, 13)
@@ -78,1581 +77,6 @@ expired_expiration_string = "1991-12-07T19:54:13Z"
isodate_re = re.compile('^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z$')
-def get_user_result(uid, givenname, sn, operation='show', omit=[],
-**overrides):
-"""Get a user result for a user-{add,mod,find,show} command
-
-This gives the result as from a user_add(uid, givenname=givenname, sn=sn);
-modifications to that can be specified in ``omit`` and ``overrides``.
-
-The ``operation`` can be one of:
-- add
-- show
-- show-all ((show with the --all flag)
-- find
-- mod
-
-Attributes named in ``omit`` are removed from the result; any additional
-or non-default values can be specified in ``overrides``.
-"""
-# sn can be None; this should only be used from `get_admin_result`
-cn = overrides.get('cn', ['%s %s' % (givenname, sn or '')])
-cn[0] = cn[0].strip()
-result = add_sid(dict(
-homedirectory=[u'/home/%s' % uid],
-loginshell=[u'/bin/sh'],
-uid=[uid],
-uidnumber=[fuzzy_digits],
-gidnumber=[fuzzy_digits],
-mail=[u'%s@%s' % (uid, api.env.domain)],
-has_keytab=False,
-has_password=False,
-))
-if sn:
-result['sn'] = [sn]
-if givenname:
-result['givenname'] = [givenname]
-if operation in ('add', 'show', 'show-all', 'find'):
-result.update(
-dn=get_user_dn(uid),
-)
-if operation in ('add', 'show-all'):
-result.upda
Re: [Freeipa-devel] upstream under RHEL7 build failure
On 11/06/2015 12:57 PM, Martin Babinsky wrote: On 11/06/2015 11:58 AM, Oleg Fayans wrote: Hi all, I am trying to build upstream packages under RHEL-7.2. All the build-time dependencies were installed from RHEL repos except python-gssapi, which was taken from fedora-22. The build fails with a pile of lint errors: https://paste.fedoraproject.org/287566/ Could someone of you help me debug this? I guess you don't have python-six package installed? I do have it. All the packages marked as BuildRequires in freeipa.spec.in are installed -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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 - POC
Hi Jan,
On 11/06/2015 09:01 AM, Jan Cholasta wrote:
Actually it might be better to keep them, but fix them to expect
ipa-server-certinstall to success.
Done. Updated patch attached.
Also in the patch 0013 I removed a trailing whitespace which caused lint
to complain
Now with domain level 0 the test output looks like this:
[11:40:51]ofayans@vm-076:~]$ ipa-run-tests test_integration/test_caless.py
test session starts
=
platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
plugins: multihost, sourceorder
collected 88 items
test_integration/test_caless.py
..xx..ss...xxssxx..ss...
= 76
passed, 6 skipped, 6 xfailed in 7871.10 seconds
=
On 6.11.2015 08:47, Jan Cholasta wrote:
Hi Oleg,
I think you can just remove
TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are
imported correctly in this case and I didn't see anything break.
Honza
On 5.11.2015 20:20, Oleg Fayans wrote:
Patch 0014 updated and passes lint
On 11/05/2015 03:41 PM, Oleg Fayans wrote:
Wait a bit, the patch has problems with pylint: it does not build :)
The updated version (without the setupmaster nonsense) is being tested
now.
On 11/05/2015 08:45 AM, Oleg Fayans wrote:
Hi Jan,
Could you take a look at these, whenever you are free?
On 10/30/2015 02:57 PM, Oleg Fayans wrote:
Hi,
The following patches contain updates to ca-less integration tests.
It's still a proof of concept: 2 tests still fail seemingly due to
the
change in target system logic (marked as xfail with "ask jcholast
comment")
The test output looks like this:
$ ipa-run-tests test_integration/test_caless.py --pdb
test session starts
=
platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
plugins: multihost, sourceorder
collected 88 items
test_integration/test_caless.py
..xx..sssss.ss.xx..ssxx.
53
passed, 29 skipped, 6 xfailed in 5620.17 seconds
=
Numerous skips correspond to the tests related to ipa-replica-prepare
(unsupported under domain level 1)
--
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
From 3142e9ab937b602a687639e7972422001e887211 Mon Sep 17 00:00:00 2001
From: Oleg Fayans
Date: Thu, 5 Nov 2015 16:25:29 +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
Re: [Freeipa-devel] [PATCH 0090] show optionally configured components in server-find/show command output
On 11/06/2015 11:06 AM, Petr Vobornik wrote: On 11/06/2015 10:15 AM, Petr Spacek wrote: On 6.11.2015 09:25, Martin Kosek wrote: On 11/05/2015 07:02 PM, Petr Vobornik wrote: On 11/02/2015 12:37 PM, Martin Kosek wrote: On 11/02/2015 06:10 AM, Jan Cholasta wrote: Hi, On 22.10.2015 10:44, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5181 This should be handled by a separate object plugin: $ ipa servercomponent-find master.ipa.test --- 6 server components matched --- Component name: CA Enabled: TRUE Start order: 50 Component name: KDC Enabled: TRUE Start order: 10 Component name: KPASSWD Enabled: TRUE Start order: 20 Component name: MEMCACHE Enabled: TRUE Start order: 39 Component name: OTPD Enabled: TRUE Start order: 80 Component name: HTTP Enabled: TRUE Start order: 40 Number of entries returned 6 This will allow us to consolidate all the ad-hoc component-related code scattered throughout IPA (search for enable component, enable/disable component, ...) into IPA command calls. I'm not opposed to showing a summary in server-show (although we don't do anything like this for any other hierarchical objects), but it should be done just for the users' sake, not for internal use (the ticket suggests to use this for topology visualisation). BTW as far as the scalability of the current solution goes, you should have a list of all the *non*-optional components and display everything else. The API proposal should be in line with our future extensions of the API. We for example want to move "ipa-csreplica-manage" set-renewal-master command to API call. Or DNSSEC generation master. Or we may want to change some other flag/role of a master via this interface. So we will need something like $ ipa server-add-role ipa.example.com --role "ca-renewal-master" or $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master Depends on usage. If we want to internally unify manipulation with configs for component we can create low-level commands which won't be exposed to CLI. E.g. ipa servercomponent-find ipa.example.com Component name: ADTRUST Config: enabledService, startOrder 60 This is all what Web UI needs. From user perspective, for CLI, something different is better. Martin used term 'role', lets go with that. Idea 1: $ ipa server-show ipa.example.com --roles Server name: vm-073.idm.lab.eng.brq.redhat.com Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Role: dns-server, cs-server, ca-renewal-master, trust-controller --all would imply --roles I am thinking "Roles" could be printed out even in default listing. It looks as an important piece of information you want to know about your master. I also originally used that with servercomponent, you moved it to server itself. It makes also sense. We will need a design for this servercomponent/roles anyway, to agree on the API with all stakeholders. $ ipa server-add-role ipa.example.com --roles=ca-renewal-master Just keep in mind that 'role' design requires yet another layer of indirection because there is no 1:1 mapping between services and roles. E.g. 'DNSSEC key master' role consists of several services, as 'DNS server' role etc. Also, we can get into trouble because role 'DNS server' in IPA 4.2 can contain different set of services than 'DNS server' in IPA 5.0 etc. For these reasons I question necessity of 'role' abstraction. Is it worth? IMO yes. Current patch is better than nothing but roles are more friendly, components are implementation detail. Showing only CNs on components doesn't show all info. E.g. ipa server-show `hostname` Server name: ipa.example.com Managed suffix: dc=example,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA This doesn't show that the server is actually also a ca-renewal-master. What is the command I can use to solve: "show me what server is the ca-renewal-master"? In that case we would IMHO need to redesign the whole service to LDAP mapping to incorporate server roles in some sane and scalable way. I'm not sure if that fits in the 4.3 timeframe. If yes, the we should first start with first putting the plumbing in and then adding API calls on top. It doesn't make much sense to push this patch first and then rework the whole thing. Then what's the difference between ADTRUST and EXTID? One is smb, second winbind but from user perspective it is the same thing - AD Trusts controller. Could there be DNS without DNSKeySync? -- 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] [PATCH] 0749 Package ipapython, ipalib, ipaplatform, ipatests for Python 3
Hello,
The Python 3 port is not 100% done, but I think the time has come to
start packaging the py3 bits. This will make it easier to plug into CI.
The existing Python 2 packages should not change, except I've added
"freeipa-common" with files that aren't Python-specific.
The new packages follow Fedora's Python guidelines a bit better. The
main thing is the names: python3-ipalib, python3-ipatests,
python3-ipap11helper.
The pure-Python ones are built as noarch.
The Makefiles are reorganized a bit, but they don't support building for
both py versions at once -- you need to do `make` followed by `make
PYTHON=/usr/bin/python3`. (The latter currently only works in the
directories that are ported so far, though.)
--
Petr Viktorin
From 158ac463bb19def552616c430d81d6b5b472cadb Mon Sep 17 00:00:00 2001
From: Petr Viktorin
Date: Tue, 3 Nov 2015 16:39:40 +0100
Subject: [PATCH] Package ipapython, ipalib, ipaplatform, ipatests for Python 3
Running make with PYTHON=/usr/bin/python3 will build/install the
bits for Python 3.
A separate setup.py is added for ipalib.
Python3 library RPMs have names according to Fedora guidelines (python3-*).
Provides are specified for all top-level Python modules.
Executable scripts in ipatests have symlinks Python version suffixes
as per Fedora guidelines. Suffix-less names point to the Python 2 versions.
Pure-Python files are packaged to noarch RPMs. The ipap11helper
module is split to its own RPM for this reason.
A new package, freeipa-common, is added for files from freeipa-python
usable by both Python versions: translations and configuration.
This package is required by both freeipa-python and python3-ipalib.
---
.gitignore | 3 +
Makefile | 7 +-
freeipa.spec.in| 209 +++--
ipalib/Makefile| 23
ipalib/cli.py | 1 +
ipalib/setup.py.in | 73
ipapython/Makefile | 18 +--
ipapython/ipap11helper/Makefile| 11 +-
ipapython/py_default_encoding/Makefile | 21 ++--
setup.py | 2 -
10 files changed, 327 insertions(+), 41 deletions(-)
create mode 100644 ipalib/Makefile
create mode 100644 ipalib/setup.py.in
diff --git a/.gitignore b/.gitignore
index fa35df85abd5b18522d2be17070c3d8aceb9bdc5..e63434b44b29fc25bf3da17e90bc0f75f5075bd6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -67,6 +67,9 @@ freeipa2-dev-doc
/ipatests/setup.py
+/ipalib/setup.py
+!/ipalib/Makefile
+
/ipapython/setup.py
/ipapython/version.py
!/ipapython/Makefile
diff --git a/Makefile b/Makefile
index 3c81466d3728022c1d9cf5bb216990f14a59b7e5..44f9420992761d6a924f44c99db1f8fc068f33fb 100644
--- a/Makefile
+++ b/Makefile
@@ -1,9 +1,10 @@
include VERSION
-SUBDIRS=asn1 daemons install ipapython ipa-client
+SUBDIRS=asn1 daemons install ipapython ipalib ipa-client
CLIENTDIRS=ipapython ipa-client asn1
PRJ_PREFIX=freeipa
+PRJ_PREFIX_PY3=python3-ipa
RPMBUILD ?= $(PWD)/rpmbuild
TARGET ?= master
@@ -135,6 +136,8 @@ version-update: release-update
> ipapython/setup.py
sed -e s/__VERSION__/$(IPA_VERSION)/ ipaplatform/setup.py.in \
> ipaplatform/setup.py
+ sed -e s/__VERSION__/$(IPA_VERSION)/ ipalib/setup.py.in \
+ > ipalib/setup.py
sed -e s/__VERSION__/$(IPA_VERSION)/ ipapython/version.py.in \
> ipapython/version.py
sed -e s/__VERSION__/$(IPA_VERSION)/ ipatests/setup.py.in \
@@ -232,6 +235,7 @@ rpms: rpmroot rpmdistdir version-update lint tarballs
cp dist/sources/$(TARBALL) $(RPMBUILD)/SOURCES/.
rpmbuild --define "_topdir $(RPMBUILD)" -ba freeipa.spec
cp $(RPMBUILD)/RPMS/*/$(PRJ_PREFIX)-*-$(IPA_VERSION)-*.rpm dist/rpms/
+ cp $(RPMBUILD)/RPMS/*/$(PRJ_PREFIX_PY3)*-$(IPA_VERSION)-*.rpm dist/rpms/
cp $(RPMBUILD)/SRPMS/$(PRJ_PREFIX)-$(IPA_VERSION)-*.src.rpm dist/srpms/
rm -rf $(RPMBUILD)
@@ -239,6 +243,7 @@ client-rpms: rpmroot rpmdistdir version-update lint tarballs
cp dist/sources/$(TARBALL) $(RPMBUILD)/SOURCES/.
rpmbuild --define "_topdir $(RPMBUILD)" --define "ONLY_CLIENT 1" -ba freeipa.spec
cp $(RPMBUILD)/RPMS/*/$(PRJ_PREFIX)-*-$(IPA_VERSION)-*.rpm dist/rpms/
+ cp $(RPMBUILD)/RPMS/*/$(PRJ_PREFIX_PY3)*-$(IPA_VERSION)-*.rpm dist/rpms/
cp $(RPMBUILD)/SRPMS/$(PRJ_PREFIX)-$(IPA_VERSION)-*.src.rpm dist/srpms/
rm -rf $(RPMBUILD)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 56c5a4d5ca2db9d299ed079be4ec4fed5747f07a..b813a17fde76fa452104a17ea86f96df38f9aff2 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -2,6 +2,12 @@
# subpackages
%{!?ONLY_CLIENT:%global ONLY_CLIENT 0}
+%if 0%{?rhel}
+%global with_python3 0
+%else
+%global with_python3 1
+%endif
+
%global alt_name ipa
%if 0%{?rhel}
%global samba_version 4.0.5-1
@@ -307,6 +313,8 @@ This package provides command-line tools for IPA administrators.
%package python
Summary: Python libraries used by IPA
Group: System Environment/Libraries
+
+Requires:
Re: [Freeipa-devel] upstream under RHEL7 build failure
On 11/06/2015 11:58 AM, Oleg Fayans wrote: Hi all, I am trying to build upstream packages under RHEL-7.2. All the build-time dependencies were installed from RHEL repos except python-gssapi, which was taken from fedora-22. The build fails with a pile of lint errors: https://paste.fedoraproject.org/287566/ Could someone of you help me debug this? I guess you don't have python-six package installed? -- 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] upstream under RHEL7 build failure
Hi all, I am trying to build upstream packages under RHEL-7.2. All the build-time dependencies were installed from RHEL repos except python-gssapi, which was taken from fedora-22. The build fails with a pile of lint errors: https://paste.fedoraproject.org/287566/ Could someone of you help me debug this? -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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 0090] show optionally configured components in server-find/show command output
On 11/06/2015 10:15 AM, Petr Spacek wrote: On 6.11.2015 09:25, Martin Kosek wrote: On 11/05/2015 07:02 PM, Petr Vobornik wrote: On 11/02/2015 12:37 PM, Martin Kosek wrote: On 11/02/2015 06:10 AM, Jan Cholasta wrote: Hi, On 22.10.2015 10:44, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5181 This should be handled by a separate object plugin: $ ipa servercomponent-find master.ipa.test --- 6 server components matched --- Component name: CA Enabled: TRUE Start order: 50 Component name: KDC Enabled: TRUE Start order: 10 Component name: KPASSWD Enabled: TRUE Start order: 20 Component name: MEMCACHE Enabled: TRUE Start order: 39 Component name: OTPD Enabled: TRUE Start order: 80 Component name: HTTP Enabled: TRUE Start order: 40 Number of entries returned 6 This will allow us to consolidate all the ad-hoc component-related code scattered throughout IPA (search for enable component, enable/disable component, ...) into IPA command calls. I'm not opposed to showing a summary in server-show (although we don't do anything like this for any other hierarchical objects), but it should be done just for the users' sake, not for internal use (the ticket suggests to use this for topology visualisation). BTW as far as the scalability of the current solution goes, you should have a list of all the *non*-optional components and display everything else. The API proposal should be in line with our future extensions of the API. We for example want to move "ipa-csreplica-manage" set-renewal-master command to API call. Or DNSSEC generation master. Or we may want to change some other flag/role of a master via this interface. So we will need something like $ ipa server-add-role ipa.example.com --role "ca-renewal-master" or $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master Depends on usage. If we want to internally unify manipulation with configs for component we can create low-level commands which won't be exposed to CLI. E.g. ipa servercomponent-find ipa.example.com Component name: ADTRUST Config: enabledService, startOrder 60 This is all what Web UI needs. From user perspective, for CLI, something different is better. Martin used term 'role', lets go with that. Idea 1: $ ipa server-show ipa.example.com --roles Server name: vm-073.idm.lab.eng.brq.redhat.com Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Role: dns-server, cs-server, ca-renewal-master, trust-controller --all would imply --roles I am thinking "Roles" could be printed out even in default listing. It looks as an important piece of information you want to know about your master. I also originally used that with servercomponent, you moved it to server itself. It makes also sense. We will need a design for this servercomponent/roles anyway, to agree on the API with all stakeholders. $ ipa server-add-role ipa.example.com --roles=ca-renewal-master Just keep in mind that 'role' design requires yet another layer of indirection because there is no 1:1 mapping between services and roles. E.g. 'DNSSEC key master' role consists of several services, as 'DNS server' role etc. Also, we can get into trouble because role 'DNS server' in IPA 4.2 can contain different set of services than 'DNS server' in IPA 5.0 etc. For these reasons I question necessity of 'role' abstraction. Is it worth? IMO yes. Current patch is better than nothing but roles are more friendly, components are implementation detail. Showing only CNs on components doesn't show all info. E.g. ipa server-show `hostname` Server name: ipa.example.com Managed suffix: dc=example,dc=com, o=ipaca Min domain level: 0 Max domain level: 1 Optional components: CA, DNS, DNSKeySync, ADTRUST, EXTID, KRA This doesn't show that the server is actually also a ca-renewal-master. What is the command I can use to solve: "show me what server is the ca-renewal-master"? Then what's the difference between ADTRUST and EXTID? One is smb, second winbind but from user perspective it is the same thing - AD Trusts controller. Could there be DNS without DNSKeySync? -- 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
[Freeipa-devel] [PATCH 0094] Fix bogus error message in choice-type installer options
https://fedorahosted.org/freeipa/ticket/5433
--
Martin^3 Babinsky
From 330cbc92b9785e68b5d5c72177fe45326c1baa86 Mon Sep 17 00:00:00 2001
From: Martin Babinsky
Date: Fri, 6 Nov 2015 10:05:42 +0100
Subject: [PATCH] fix error reporting when installer option is supplied with
invalid choice
https://fedorahosted.org/freeipa/ticket/5433
---
ipapython/install/cli.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ipapython/install/cli.py b/ipapython/install/cli.py
index d2250e51650b9de1c85473399e3462f42bf8770b..e02445a8f6edf1335c813f4f30563d7edbd88fd0 100644
--- a/ipapython/install/cli.py
+++ b/ipapython/install/cli.py
@@ -218,7 +218,8 @@ class ConfigureTool(admintool.AdminTool):
if value not in value_type:
raise ValueError(
"invalid choice {0} (choose from {1})".format(
-repr(value), ', '.join(repr(value_type
+repr(value), ', '.join(
+repr(v) for v in value_type)))
return value
else:
parse = value_type
--
2.4.3
--
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 0090] show optionally configured components in server-find/show command output
On 6.11.2015 09:25, Martin Kosek wrote: > On 11/05/2015 07:02 PM, Petr Vobornik wrote: >> > On 11/02/2015 12:37 PM, Martin Kosek wrote: >>> >> On 11/02/2015 06:10 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 22.10.2015 10:44, Martin Babinsky wrote: > https://fedorahosted.org/freeipa/ticket/5181 >>> >>> This should be handled by a separate object plugin: >>> >>> $ ipa servercomponent-find master.ipa.test >>> --- >>> 6 server components matched >>> --- >>>Component name: CA >>>Enabled: TRUE >>>Start order: 50 >>> >>>Component name: KDC >>>Enabled: TRUE >>>Start order: 10 >>> >>>Component name: KPASSWD >>>Enabled: TRUE >>>Start order: 20 >>> >>>Component name: MEMCACHE >>>Enabled: TRUE >>>Start order: 39 >>> >>>Component name: OTPD >>>Enabled: TRUE >>>Start order: 80 >>> >>>Component name: HTTP >>>Enabled: TRUE >>>Start order: 40 >>> >>> Number of entries returned 6 >>> >>> >>> This will allow us to consolidate all the ad-hoc component-related code >>> scattered throughout IPA (search for enable component, enable/disable >>> component, ...) into IPA command calls. >>> >>> I'm not opposed to showing a summary in server-show (although we don't >>> do >>> anything like this for any other hierarchical objects), but it should >>> be done >>> just for the users' sake, not for internal use (the ticket suggests to >>> use this >>> for topology visualisation). >>> >>> BTW as far as the scalability of the current solution goes, you should >>> have a >>> list of all the *non*-optional components and display everything else. >>> >> >>> >> The API proposal should be in line with our future extensions of the >>> >> API. We >>> >> for example want to move "ipa-csreplica-manage" set-renewal-master >>> >> command to >>> >> API call. Or DNSSEC generation master. Or we may want to change some >>> >> other >>> >> flag/role of a master via this interface. >>> >> >>> >> So we will need something like >>> >> $ ipa server-add-role ipa.example.com --role "ca-renewal-master" >>> >> or >>> >> $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master >> > >> > Depends on usage. If we want to internally unify manipulation with configs >> > for >> > component we can create low-level commands which won't be exposed to CLI. >> > >> > E.g. ipa servercomponent-find ipa.example.com >> > Component name: ADTRUST >> > Config: enabledService, startOrder 60 >> > >> > >> > >> > This is all what Web UI needs. >> > >> > >> > From user perspective, for CLI, something different is better. Martin used >> > term >> > 'role', lets go with that. >> > >> > Idea 1: >> > $ ipa server-show ipa.example.com --roles >> > Server name: vm-073.idm.lab.eng.brq.redhat.com >> > Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca >> > Min domain level: 0 >> > Max domain level: 1 >> > Role: dns-server, cs-server, ca-renewal-master, trust-controller >> > >> > --all would imply --roles > I am thinking "Roles" could be printed out even in default listing. It looks > as > an important piece of information you want to know about your master. I also > originally used that with servercomponent, you moved it to server itself. It > makes also sense. > > We will need a design for this servercomponent/roles anyway, to agree on the > API with all stakeholders. > >> > $ ipa server-add-role ipa.example.com --roles=ca-renewal-master Just keep in mind that 'role' design requires yet another layer of indirection because there is no 1:1 mapping between services and roles. E.g. 'DNSSEC key master' role consists of several services, as 'DNS server' role etc. Also, we can get into trouble because role 'DNS server' in IPA 4.2 can contain different set of services than 'DNS server' in IPA 5.0 etc. For these reasons I question necessity of 'role' abstraction. Is it worth? -- Petr^2 Spacek -- 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 0090] show optionally configured components in server-find/show command output
On 6.11.2015 10:00, Martin Babinsky wrote:
> On 11/02/2015 12:56 PM, Martin Babinsky wrote:
>> On 10/30/2015 11:53 AM, Martin Babinsky wrote:
>>> On 10/26/2015 01:41 PM, Martin Babinsky wrote:
On 10/22/2015 04:13 PM, Martin Basti wrote:
>
>
> On 22.10.2015 10:44, Martin Babinsky wrote:
>> https://fedorahosted.org/freeipa/ticket/5181
>>
>>
>>
>
> Thank you for the patch.
>
> 1)
> +OPTIONAL_SERVICES = {
> +'DNS',
> +'CA',
> +'KRA',
> +'ADTRUST',
> +'EXTID',
> +'DNSKeyExporter',
> +'DNSSEC',
> +'DNSKeySync',
> +}
>
> This did not scale well, maybe we should improve it to use some general
> solution for whole IPA to distinct mandratory and optionl service,
> but I
> do not know how (or if it is possible)
>
Yes this does not scale well. After some playing around with relocating
the SERVICE_LIST object in 'ipaserver/install/service.py' I found out
that more refactoring would be needed to improve the layout and
availability of LDAP service names to both server and client code. I
have put the list of core services to ipalib/constants.py for now, and I
suggest to open a separate ticket for more general solution.
> 2)
> +search_filter=('(&(objectclass=ipaConfigObject)'
> + '(ipaConfigString=enabledService))')
>
> Common user cannot read ipaConfigString, so this will work only for
> admins, I do not see any limitations of access in code for other users.
>
I think that you agreed with Petr^2 that this filter is OK. I left it as
it is but I have rewritten it as a call to ldap.make_filter to improve
readability and/or potential extensibility a bit.
> 3)
> +opt_components = [
> +r['cn'][0] for r in result if r['cn'][0] in
> OPTIONAL_SERVICES
> +]
> Probably instead of indexing, you may use result.single_value['cn']
>
> Martin^2
Attaching updated patch.
>>> Self-NACK, I found a bug in the patch during work on topology management
>>> stuff.
>>>
>>
>> Attaching updated patch.
>>
>>
>>
> Bump for review.
I apologize for the delay, ACK!
--
Petr^2 Spacek
--
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 0090] show optionally configured components in server-find/show command output
On 11/02/2015 12:56 PM, Martin Babinsky wrote:
On 10/30/2015 11:53 AM, Martin Babinsky wrote:
On 10/26/2015 01:41 PM, Martin Babinsky wrote:
On 10/22/2015 04:13 PM, Martin Basti wrote:
On 22.10.2015 10:44, Martin Babinsky wrote:
https://fedorahosted.org/freeipa/ticket/5181
Thank you for the patch.
1)
+OPTIONAL_SERVICES = {
+'DNS',
+'CA',
+'KRA',
+'ADTRUST',
+'EXTID',
+'DNSKeyExporter',
+'DNSSEC',
+'DNSKeySync',
+}
This did not scale well, maybe we should improve it to use some general
solution for whole IPA to distinct mandratory and optionl service,
but I
do not know how (or if it is possible)
Yes this does not scale well. After some playing around with relocating
the SERVICE_LIST object in 'ipaserver/install/service.py' I found out
that more refactoring would be needed to improve the layout and
availability of LDAP service names to both server and client code. I
have put the list of core services to ipalib/constants.py for now, and I
suggest to open a separate ticket for more general solution.
2)
+search_filter=('(&(objectclass=ipaConfigObject)'
+ '(ipaConfigString=enabledService))')
Common user cannot read ipaConfigString, so this will work only for
admins, I do not see any limitations of access in code for other users.
I think that you agreed with Petr^2 that this filter is OK. I left it as
it is but I have rewritten it as a call to ldap.make_filter to improve
readability and/or potential extensibility a bit.
3)
+opt_components = [
+r['cn'][0] for r in result if r['cn'][0] in
OPTIONAL_SERVICES
+]
Probably instead of indexing, you may use result.single_value['cn']
Martin^2
Attaching updated patch.
Self-NACK, I found a bug in the patch during work on topology management
stuff.
Attaching updated patch.
Bump for review.
--
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 0090] show optionally configured components in server-find/show command output
On 11/05/2015 07:02 PM, Petr Vobornik wrote: > On 11/02/2015 12:37 PM, Martin Kosek wrote: >> On 11/02/2015 06:10 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 22.10.2015 10:44, Martin Babinsky wrote: https://fedorahosted.org/freeipa/ticket/5181 >>> >>> This should be handled by a separate object plugin: >>> >>> $ ipa servercomponent-find master.ipa.test >>> --- >>> 6 server components matched >>> --- >>>Component name: CA >>>Enabled: TRUE >>>Start order: 50 >>> >>>Component name: KDC >>>Enabled: TRUE >>>Start order: 10 >>> >>>Component name: KPASSWD >>>Enabled: TRUE >>>Start order: 20 >>> >>>Component name: MEMCACHE >>>Enabled: TRUE >>>Start order: 39 >>> >>>Component name: OTPD >>>Enabled: TRUE >>>Start order: 80 >>> >>>Component name: HTTP >>>Enabled: TRUE >>>Start order: 40 >>> >>> Number of entries returned 6 >>> >>> >>> This will allow us to consolidate all the ad-hoc component-related code >>> scattered throughout IPA (search for enable component, enable/disable >>> component, ...) into IPA command calls. >>> >>> I'm not opposed to showing a summary in server-show (although we don't do >>> anything like this for any other hierarchical objects), but it should be >>> done >>> just for the users' sake, not for internal use (the ticket suggests to use >>> this >>> for topology visualisation). >>> >>> BTW as far as the scalability of the current solution goes, you should have >>> a >>> list of all the *non*-optional components and display everything else. >> >> The API proposal should be in line with our future extensions of the API. We >> for example want to move "ipa-csreplica-manage" set-renewal-master command to >> API call. Or DNSSEC generation master. Or we may want to change some other >> flag/role of a master via this interface. >> >> So we will need something like >> $ ipa server-add-role ipa.example.com --role "ca-renewal-master" >> or >> $ ipa servercomponent-add-role ipa.example.com CA --role=renewal-master > > Depends on usage. If we want to internally unify manipulation with configs for > component we can create low-level commands which won't be exposed to CLI. > > E.g. ipa servercomponent-find ipa.example.com > Component name: ADTRUST > Config: enabledService, startOrder 60 > > > > This is all what Web UI needs. > > > From user perspective, for CLI, something different is better. Martin used > term > 'role', lets go with that. > > Idea 1: > $ ipa server-show ipa.example.com --roles > Server name: vm-073.idm.lab.eng.brq.redhat.com > Managed suffix: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com, o=ipaca > Min domain level: 0 > Max domain level: 1 > Role: dns-server, cs-server, ca-renewal-master, trust-controller > > --all would imply --roles I am thinking "Roles" could be printed out even in default listing. It looks as an important piece of information you want to know about your master. I also originally used that with servercomponent, you moved it to server itself. It makes also sense. We will need a design for this servercomponent/roles anyway, to agree on the API with all stakeholders. > $ ipa server-add-role ipa.example.com --roles=ca-renewal-master > > This is not good because this add operation will also remove a role from > different master which could be unexpected. I.e. set-renewal-master might be a > separate command. Same would apply to DNSSec generation masters. I am not sure if having a separate command for every role scale well, but I am not that strong opposed. > Idea 2: > $ ipa serverrole-add ipa.example.com ca-renewal-master > $ ipa serverrole-find ipa.example.com > Role: dns-server > Role: cs-server > Role: ca-renewal-master > Role: trust-controller > > All variants alone are fine for Web UI. -- 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 - POC
Actually it might be better to keep them, but fix them to expect
ipa-server-certinstall to success.
On 6.11.2015 08:47, Jan Cholasta wrote:
Hi Oleg,
I think you can just remove
TestCertinstall.test_{http,ds}_intermediate_ca, the certificates are
imported correctly in this case and I didn't see anything break.
Honza
On 5.11.2015 20:20, Oleg Fayans wrote:
Patch 0014 updated and passes lint
On 11/05/2015 03:41 PM, Oleg Fayans wrote:
Wait a bit, the patch has problems with pylint: it does not build :)
The updated version (without the setupmaster nonsense) is being tested
now.
On 11/05/2015 08:45 AM, Oleg Fayans wrote:
Hi Jan,
Could you take a look at these, whenever you are free?
On 10/30/2015 02:57 PM, Oleg Fayans wrote:
Hi,
The following patches contain updates to ca-less integration tests.
It's still a proof of concept: 2 tests still fail seemingly due to the
change in target system logic (marked as xfail with "ask jcholast
comment")
The test output looks like this:
$ ipa-run-tests test_integration/test_caless.py --pdb
test session starts
=
platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4
plugins: multihost, sourceorder
collected 88 items
test_integration/test_caless.py
..xx..sssss.ss.xx..ssxx.
53
passed, 29 skipped, 6 xfailed in 5620.17 seconds
=
Numerous skips correspond to the tests related to ipa-replica-prepare
(unsupported under domain level 1)
--
Jan Cholasta
--
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
