Re: [Freeipa-devel] [TESTS][PATCH 0011] WebUI: Creating user without private group

[Martin Basti]

On 01.04.2016 14:34, Pavel Vomacka wrote:



On 03/31/2016 04:16 PM, Lenka Doudova wrote:



On 03/31/2016 12:42 PM, Pavel Vomacka wrote:



On 03/18/2016 11:24 AM, Lenka Doudova wrote:



On 03/10/2016 06:58 PM, Petr Vobornik wrote:

On 03/08/2016 01:17 PM, Lenka Doudova wrote:



On 03/08/2016 12:59 PM, Petr Vobornik wrote:

On 03/07/2016 04:29 PM, Pavel Vomacka wrote:



On 02/25/2016 03:08 PM, Lenka Doudova wrote:

Hi,

here's a patch for webUI tests that provides test for creating 
user

without private group.
Related to ticket https://fedorahosted.org/freeipa/ticket/4986

Since the option to specify GID when creating a user is not 
available
https://fedorahosted.org/freeipa/ticket/5505 the test creates 
a new
posix group, makes it a default user group instead of 
'ipausers' and

then attemps to create the user without private group. Returning
default user group value to 'ipausers' is provided even for 
cases when

the test fails so it would not block other tests from performing
properly.

Lenka



Hi,

ACK, works well.

Pavel^3 Vomacka



NACK, don't use naked except, specify at least 'Exception'
  +except:



Thanks, patch fixed according to Petr's review attached.

Lenka


Ticket 5505 was pushed. So the workaround can be removed. Do you 
prefer to do it in this patch?


Also, maybe it would be good to test both cases and check if the 
error is actually the right one.


Hi,

attaching patch fixed according to recently pushed changes.

Lenka

Hi,

NACK,

1) The data definition for user3 (user.DATA3) is not used anywhere. 
And the definition is actually the same as definition of user4. So, 
I think that it could be removed.


2) This is just a detail, but I would rather use 'combobox_input' or 
'combobox_textbox' as parameter name because the parameter actually 
doesn't represent the value of combobox.


Otherwise it works as expected.

--
Pavel^3 Vomacka


Hi,

thanks for comments, updated patch attached.

Lenka



Thank you, ACK.

--
Pavel^3 Vomacka



Ticket is in closed milestone, this patch cannot be attached to closed 
milestone, please create a new ticket/or post the proper ticket.
-- 
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] [TEST][patch-0033] Added assertion errors to topology tests, track N 5772

[Martin Babinsky]

On 03/31/2016 05:15 PM, Oleg Fayans wrote:

Hi Martin,

Thanks for the review. The updated patch(es) are included

Testrun output can be found here:

http://fpaste.org/347800/59421745/

On 03/31/2016 01:10 PM, Martin Basti wrote:



On 31.03.2016 12:07, Oleg Fayans wrote:

Please, disregard it for a while, it does not pass lint.

On 03/31/2016 12:05 PM, Oleg Fayans wrote:




NACK

Please send unrelated changes in separate patches. I do not see relation
between changing variable names, adding assertion messages and setting
replication sleep-a-bit wait.


Agreed. There are two necessary bugfixes for the testsuite to run. They
were put into a separate patch



IMO to the ticket in the patch only assertion changes are related.

For the pylint related errors:
assert ('any value', 'in tuple')
is always true.
right syntax is
assert (any test), ('error msg')


thank you!



Martin^2





Hi Oleg,

Patch 0033:

1.)
First of all, the commit message does not tell much about what the patch 
does, I would prefer something like "Improve reporting of failed tests 
in topology test suite".


2.) Since what you are doing is basically comparing the contents of a 
list of dicts containing expected data with a list of dicts with data 
parsed from test results, why are you not using "assert_deepequal" 
function from 'ipatests/util.py' module? It is also used in e.g. XMLRPC 
tests and it reports the failures fairly well (e.g. redundant keys, 
missing keys, expected value mismatch, container length mismatch etc.)


Patch 034:

I think this is a good use case for 'wait_for_replication' function from 
'ipatests/test_integration/tasks.py' module. You need to establish LDAP 
connection to the host but this is very easy, see how it's done in 
'test_simple_replication' suite[1].


I would prefer this approach (if applicable) instead of using sleep().

In any way, your formatting of assertions is wrong and makes the code 
nearly unreadable. See the attached patch for an example of pep8 
compliant and pleasant formatting


[1] 
https://git.fedorahosted.org/cgit/freeipa.git/tree/ipatests/test_integration/test_simple_replication.py#n42


--
Martin^3 Babinsky
diff --git a/ipatests/test_integration/test_topology.py b/ipatests/test_integration/test_topology.py
index 39e03ee..6799e26 100644
--- a/ipatests/test_integration/test_topology.py
+++ b/ipatests/test_integration/test_topology.py
@@ -72,15 +72,15 @@ class TestTopologyOptions(IntegrationTest):
 output1 = result1.stdout_text
 firstsegment = self.tokenize_topologies(output1)[0]
 num_of_entries = self.noentries_re.search(output1).group(1)
-assert(firstsegment['name'] == first_segment_name),\
-"A segment with non-standard name was created: %s" % \
-firstsegment['name']
-assert(num_of_entries == "1"),\
-"Unexpected number of segments found: %s" % num_of_entries
-assert(firstsegment['leftnode'] == master.hostname),\
-"Incorrect leftnode: %s" % firstsegment['leftnode']
-assert(firstsegment['rightnode'] == replica1.hostname),\
-"Incorrect rightnode: %s" % firstsegment['rightnode']
+assert(firstsegment['name'] == first_segment_name), (
+"A segment with non-standard name was created: %s"
+%firstsegment['name'])
+assert(num_of_entries == "1"), (
+"Unexpected number of segments found: %s" % num_of_entries)
+assert(firstsegment['leftnode'] == master.hostname), (
+"Incorrect leftnode: %s" % firstsegment['leftnode'])
+assert(firstsegment['rightnode'] == replica1.hostname), (
+"Incorrect rightnode: %s" % firstsegment['rightnode'])
 tasks.install_replica(master, replica2, setup_ca=False,
   setup_dns=False)
 # We need to make sure topology information is consistent across all
@@ -92,14 +92,14 @@ class TestTopologyOptions(IntegrationTest):
 result4 = replica2.run_command(['ipa', 'topologysegment-find',
 DOMAIN_SUFFIX_NAME])
 segments = self.tokenize_topologies(result2.stdout_text)
-assert(len(segments) == 2),\
-"Unexpected number of segments found: %i" % len(segments)
-assert(result2.stdout_text == result3.stdout_text),\
-"Failed replication between %s and %s" % (master.hostname,
-  replica1.hostname)
-assert(result3.stdout_text == result4.stdout_text),\
+assert(len(segments) == 2), (
+"Unexpected number of segments found: %i" % len(segments))
+assert(result2.stdout_text == result3.stdout_text), (
+"Failed replication between %s and %s" % (master.hostname,
+  replica1.hostname))
+assert(result3.stdout_text == result4.stdout_text), (
 "Failed replication between %s and %s" % (replica1.hostname,
- 

Re: [Freeipa-devel] [PATCH 0452] Add missing pre_common_callback to stageuser-add

[Martin Babinsky]

On 03/31/2016 09:49 AM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/5759

Patch attached.



ACK.

--
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 0088-0095] Add --forward-policy option into installers

[Petr Spacek]

On 31.3.2016 13:45, Martin Basti wrote:
> 
> 
> On 21.03.2016 16:51, Petr Spacek wrote:
>> On 10.3.2016 22:17, Lukas Slebodnik wrote:
>>> On (10/03/16 22:14), Petr Spacek wrote:
 Hello,

 I forgot to send a patches before I leave, so here it is:

 Auto-detect default value for --forward-policy option in installers

 See
 https://fedorahosted.org/freeipa/ticket/5710
 commit messages, and design page
 https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones



 I did not have time to test it thoroughly but it LGTM :-D

 Please note that this is first part, it does not solve upgrade (yet) and
 warnings in forwardzone-* interface.

 This can be solved in another patch set, this can be pushed if it passes
 review.

>>> ENOPATH
>> LOL, here it is.
>>
>>
>>
>  * Remove function ipapython.ipautil.host_exists() *
> ACK
> 
> 
> * Extend installers with --forward-policy option *
> 1)
> There is no --forward-policy option in ipa-dns-install
> 
> 
> * Move automatic empty zone list into ipapython.dnsutil and make it reusable *
> ACK
> 
> 
> * Add assert_absolute_dnsname() helper to ipapython.dnsutil *
> ACK
> 
> 
> * Move function is_auto_empty_zone() into ipapython.dnsutil *
> ACK
> 
> 
> * Use shared sanity check and tests ipapython.dnsutil.is_auto_empty_zone() *
> ACK
> 
> * Add function ipapython.dnsutil.inside_auto_empty_zone() *
> ACK
> 
> * Auto-detect default value for --forward-policy option in installers *
> LGTM, but ipa-dns-install is missing option --forward-policy
> 
> # ipa-dns-install
> ...
> Unexpected error - see /var/log/ipaserver-install.log for details:
> AttributeError: Values instance has no attribute 'forward_policy'
> 
> 
> Summary: 6 ACKs, 1 LGTM, 1 NACK => NACK

Thank you very much for review.

Here is my second attempt :-)

-- 
Petr^2 Spacek
From 57f64495c645d3c7b82b1d91b2b66b8b651bd114 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 7 Mar 2016 10:52:35 +0100
Subject: [PATCH] Remove function ipapython.ipautil.host_exists()

The function duplicated ipalib.util.verify_host_resolvable() in slightly
incompatible way because it used NSS while rest of IPA is using only DNS.
---
 install/tools/ipa-replica-manage | 12 
 ipapython/ipautil.py | 14 --
 2 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/install/tools/ipa-replica-manage b/install/tools/ipa-replica-manage
index 6d1fc93c4c8499dcb4cd0924ff837a0216395821..3d2a467afd1c8552a64dd0f1c72efb92d9789bf1 100755
--- a/install/tools/ipa-replica-manage
+++ b/install/tools/ipa-replica-manage
@@ -38,7 +38,7 @@ from ipaserver.install import opendnssecinstance, dnskeysyncinstance
 from ipapython import version, ipaldap
 from ipalib import api, errors
 from ipalib.constants import CACERT
-from ipalib.util import has_managed_topology
+from ipalib.util import has_managed_topology, verify_host_resolvable
 from ipapython.ipa_log_manager import root_logger, standard_logging_setup
 from ipapython.dn import DN
 from ipapython.config import IPAOptionParser
@@ -743,10 +743,14 @@ def check_last_link(delrepl, realm, dirman_passwd, force):
 
 
 def enforce_host_existence(host, message=None):
-if host is not None and not ipautil.host_exists(host):
+if host is None:
+return
+
+try:
+verify_host_resolvable(host, root_logger)
+except errors.DNSNotARecordError as ex:
 if message is None:
-message = "Unknown host %s" % host
-
+message = "Unknown host %s: %s" % (host, ex)
 sys.exit(message)
 
 def ensure_last_services(conn, hostname, masters, options):
diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index d705c51f8d1937ffe57e52cce4b590951653c37b..c2e68e177f7f2c0af7af13605dee728b63fe8cb4 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -1014,20 +1014,6 @@ def bind_port_responder(port, socket_type=socket.SOCK_STREAM, socket_timeout=Non
 raise last_socket_error # pylint: disable=E0702
 
 
-def host_exists(host):
-"""
-Resolve the host to see if it exists.
-
-Returns True/False
-"""
-try:
-socket.getaddrinfo(host, 80)
-except socket.gaierror:
-return False
-else:
-return True
-
-
 def reverse_record_exists(ip_address):
 """
 Checks if IP address have some reverse record somewhere.
-- 
2.5.5

From b0145d16f3f3bab451533edfb17774dc44ca08ce Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Tue, 1 Mar 2016 11:13:18 +0100
Subject: [PATCH] Extend installers with --forward-policy option

This option specified forward policy for global forwarders.
The value is put inside /etc/named.conf.

https://fedorahosted.org/freeipa/ticket/5710
---
 install/share/bind.named.conf.template  | 2 +-
 install/tools/ipa-dns-install   | 3 +++
 install/tools/man/ipa-dns-install.1 | 3 +++
 install/tools/man/ipa-replica-install.1 | 3 +++
 

Re: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides

[Jan Cholasta]

Hi,

On 1.4.2016 16:53, Tomas Babej wrote:

Hi,

this extends the user ID overrides with capability to store the user
certificate.

https://fedorahosted.org/freeipa/ticket/4955


The preferred way of managing certificates nowadays is using 
$OBJ-add-cert and $OBJ-remove-cert commands, you should add them here as 
well.


I would even go as far as not allowing to modify certificates using 
idoverrideuser-mod - in user-mod and host-mod, it's there just for 
backward compatibility, which is not the case here. But I don't have a 
strong opinion on that.


For consistency with user-find and host-find, the full certificate blob 
should not be shown in idoverrideuser-find. You can do that by setting 
search_display_attributes attribute on the idoverrideuser class 
appropriately.


Honza

--
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

Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface

[Petr Spacek]

On 4.4.2016 13:39, Martin Basti wrote:
> 
> 
> On 31.03.2016 09:58, Petr Spacek wrote:
>> On 26.2.2016 15:37, Petr Spacek wrote:
>>> On 25.2.2016 16:46, Simo Sorce wrote:
 On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote:
> On 25.2.2016 15:28, Simo Sorce wrote:
>> On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote:
>>> Variant C
>>> -
>>> An alternative is to be lazy and dumb. Maybe it would be enough for
>>> the first
>>> round ...
>>>
>>> We would retain
>>> [first step - no change from variant A]
>>> * create locations
>>> * assign 'main' (aka 'primary' aka 'home') servers to locations
>>> ++ specify weights for the 'main' servers in given location, i.e.
>>> manually
>>> input (server, weight) tuples
>>>
>>> Then, backups would be auto-generated set of all remaining servers
>>> from all
>>> other locations.
>>>
>>> Additional storage complexity: 0
>>>
>>> This covers the scenario "always prefer local servers and use remote
>>> only as
>>> fallback" easily. It does not cover any other scenario.
>>>
>>> This might be sufficient for the first run and would allow us to
>>> gather some
>>> feedback from the field.
>>>
>>> Now I'm inclined to this variant :-)
>> To be honest, this is all I always had in mind, for the first step.
>>
>> To recap:
>> - define a location with the list of servers (perhaps location is a
>> property of server objects so you can have only one location per server,
>> and if you remove the server it is automatically removed from the
>> location w/o additional work or referential integrity necessary), if
>> weight is not defined (default) then they all have the same weight.
> Agreed.
>
>
>> - Allow to specify backup locations in the location object, priorities
>> are calculated automatically and all backup locations have same weight.
> Hmm, weights have to be inherited form the original location in all
> cases. Did
> you mean that all backup locations have the same *priority*?
 Yes, sorry.

> Anyway, explicit configuration of backup locations is introducing API and
> schema for variant A and that is what I'm questioning above. It is hard to
> make it extensible so we do not have headache in future when somebody
> decides
> that more flexibility is needed OR that link-based approach is better.
 I think no matter we do we'll need to allow admins to override backup
 locations, in future if we can calculate them automatically admins will
 simply not set any backup location explicitly (or set some special value
 like "autogenerate" and the system will do it for them.

 Forcing admins to mentally calculate weights to force the system to
 autogenerate the configuration they want would be a bad experience, I
 personally would find it very annoying.

> In other words, for doing what you propose above we would have to design
> complete schema and API for variant A anyway to make sure we do not lock
> ourselves, so we are not getting any saving by doing so.
 A seemed much more complicated to me, as you wanted to define a ful
 matrix for weights of servers when they are served as backups and all
 that.

>> - Define a *default* location, which is the backup for any other
>> location but always with lower priority to any other explicitly defined
>> backup locations.
> I would rather *always* use the default location as backup for all other
> locations. It does not require any API or schema (as it equals to "all
> servers" except "servers in this location" which can be easily calculated
> on fly).
 We can start with this, but it works well only in a stellar topology
 where you have a central location all other location connect to.
 As soon as you have a super-stellar topology where you have hub location
 to which regional locations connect to, then this is wasteful.

> This can be later on extended in whatever direction we want without any
> upgrade/migration problem.
>
> More importantly, all the schema and API will be common for all other
> variants
> anyway so we can start doing so and see how much time is left when it is
> done.
 I am ok with this for the first step.
 After all location is mostly about the "normal" case where clients want
 to reach the local servers, the backup part is only an additional
 feature we can keep simple for now. It's a degraded mode of operation
 anyway so it is probably ok to have just one default backup location as
 a starting point.
>>> Okay, now we are in agreement. I will think about minimal schema and API 
>>> over
>>> the weekend.
>> Well, it took longer than one weekend.
>>
>> There was couple of changes in the design document:
>> * ‎Feature Management: CLI proposal
>> 

Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface

[Martin Basti]

On 31.03.2016 09:58, Petr Spacek wrote:

On 26.2.2016 15:37, Petr Spacek wrote:

On 25.2.2016 16:46, Simo Sorce wrote:

On Thu, 2016-02-25 at 15:54 +0100, Petr Spacek wrote:

On 25.2.2016 15:28, Simo Sorce wrote:

On Thu, 2016-02-25 at 14:45 +0100, Petr Spacek wrote:

Variant C
-
An alternative is to be lazy and dumb. Maybe it would be enough for
the first
round ...

We would retain
[first step - no change from variant A]
* create locations
* assign 'main' (aka 'primary' aka 'home') servers to locations
++ specify weights for the 'main' servers in given location, i.e.
manually
input (server, weight) tuples

Then, backups would be auto-generated set of all remaining servers
from all
other locations.

Additional storage complexity: 0

This covers the scenario "always prefer local servers and use remote
only as
fallback" easily. It does not cover any other scenario.

This might be sufficient for the first run and would allow us to
gather some
feedback from the field.

Now I'm inclined to this variant :-)

To be honest, this is all I always had in mind, for the first step.

To recap:
- define a location with the list of servers (perhaps location is a
property of server objects so you can have only one location per server,
and if you remove the server it is automatically removed from the
location w/o additional work or referential integrity necessary), if
weight is not defined (default) then they all have the same weight.

Agreed.



- Allow to specify backup locations in the location object, priorities
are calculated automatically and all backup locations have same weight.

Hmm, weights have to be inherited form the original location in all cases. Did
you mean that all backup locations have the same *priority*?

Yes, sorry.


Anyway, explicit configuration of backup locations is introducing API and
schema for variant A and that is what I'm questioning above. It is hard to
make it extensible so we do not have headache in future when somebody decides
that more flexibility is needed OR that link-based approach is better.

I think no matter we do we'll need to allow admins to override backup
locations, in future if we can calculate them automatically admins will
simply not set any backup location explicitly (or set some special value
like "autogenerate" and the system will do it for them.

Forcing admins to mentally calculate weights to force the system to
autogenerate the configuration they want would be a bad experience, I
personally would find it very annoying.


In other words, for doing what you propose above we would have to design
complete schema and API for variant A anyway to make sure we do not lock
ourselves, so we are not getting any saving by doing so.

A seemed much more complicated to me, as you wanted to define a ful
matrix for weights of servers when they are served as backups and all
that.


- Define a *default* location, which is the backup for any other
location but always with lower priority to any other explicitly defined
backup locations.

I would rather *always* use the default location as backup for all other
locations. It does not require any API or schema (as it equals to "all
servers" except "servers in this location" which can be easily calculated on 
fly).

We can start with this, but it works well only in a stellar topology
where you have a central location all other location connect to.
As soon as you have a super-stellar topology where you have hub location
to which regional locations connect to, then this is wasteful.


This can be later on extended in whatever direction we want without any
upgrade/migration problem.

More importantly, all the schema and API will be common for all other variants
anyway so we can start doing so and see how much time is left when it is done.

I am ok with this for the first step.
After all location is mostly about the "normal" case where clients want
to reach the local servers, the backup part is only an additional
feature we can keep simple for now. It's a degraded mode of operation
anyway so it is probably ok to have just one default backup location as
a starting point.

Okay, now we are in agreement. I will think about minimal schema and API over
the weekend.

Well, it took longer than one weekend.

There was couple of changes in the design document:
* ‎Feature Management: CLI proposal
* ‎Feature Management: web UI - idea with topology graph replaced original
complicated table
* Feature Management: described necessary configuration outside of IPA DNS
* Version 1 parts which were moved into separate document:
V4/DNS_Location_Mechanism_with_per_client_override
* ‎Assumptions: removed misleading reference to DHCP, clarified role of DNS 
views
* Assumptions: removed misleading mention of 'different networks' and added
summary explaining how Location is defined
* Implementation: high-level outline added

Current version:
http://www.freeipa.org/page/V4/DNS_Location_Mechanism

Full diff:

Re: [Freeipa-devel] [DESIGN] Server Roles

[Martin Babinsky]

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)
How would we query whether the package providing the role was installed? 
By trying to import the module(s) providing the package on the server 
side and catching the error? That could be manageable IMHO.



b) configured/unconfigured (the installer for the role was/was not
successfully run on the server, LDAP service entries exist)
Presence of LDAP entry would indicate that installer was run 
succesfully, although this is not guaranteed since the installer could 
crash *after* the entry was added to the service container.



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.


Ok I will fix that.

--
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