date:20141201

Re: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods

2014-12-01 Thread Petr Vobornik


On 12/01/2014 02:33 PM, Jan Cholasta wrote:

Hi,

Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a):

`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab

in order to allow hosts to retrieve keytab of their services or related
hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval
design page

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


Since groups of users are supported with "group" members, we should
probably also support groups of hosts with "hostgroup" members, for
consistency.


--hostgroup options added.






I'm pondering how to handle Web UI. I'm not font of adding a third pair
of tables to host and service details pages because the amount of space
on the page required for the keytab management is much bigger than its
importance compared to other fields.


Honza


--
Petr Vobornik
From aed7cb6a62ee55a982dcf8aca7da9ac1cd747833 Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Mon, 1 Dec 2014 10:15:21 +0100
Subject: [PATCH] add --hosts and --hostgroup options to allow/retrieve keytab
 methods

`--hosts` and `--hostgroup` options added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab

in order to allow hosts to retrieve keytab of their services or related hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval design page

https://fedorahosted.org/freeipa/ticket/4777
---
 API.txt |  32 ++--
 VERSION |   4 +-
 ipalib/plugins/host.py  |  28 +--
 ipalib/plugins/service.py   |  28 +--
 ipatests/test_xmlrpc/test_host_plugin.py| 109 ++--
 ipatests/test_xmlrpc/test_service_plugin.py |  92 ---
 6 files changed, 257 insertions(+), 36 deletions(-)

diff --git a/API.txt b/API.txt
index 2a63f1e2349f0df69433fa7cb742e269cd42d79f..e9768bf1e87d6679c439b98ed696b720937099d2 100644
--- a/API.txt
+++ b/API.txt
@@ -1826,10 +1826,12 @@ output: Output('completed', , None)
 output: Output('failed', , None)
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 command: host_allow_create_keytab
-args: 1,6,3
+args: 1,8,3
 arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
+option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True)
 option: Flag('no_members', autofill=True, default=False, exclude='webui')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1838,10 +1840,12 @@ output: Output('completed', , None)
 output: Output('failed', , None)
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 command: host_allow_retrieve_keytab
-args: 1,6,3
+args: 1,8,3
 arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
+option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True)
 option: Flag('no_members', autofill=True, default=False, exclude='webui')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1866,10 +1870,12 @@ output: Output('result', , None)
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
 command: host_disallow_create_keytab
-args: 1,6,3
+args: 1,8,3
 arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
+option: Str('hostgroup*', alwaysask=True, cli_name='hostgroups', csv=True)
 option: Flag('no_members', autofill=True, default=False, exclude='webui')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1

Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable

2014-12-01 Thread thierry bordaz


On 11/12/2014 11:37 PM, Nathaniel McCallum wrote:

On Mon, 2014-11-10 at 08:28 +0100, Martin Kosek wrote:

On 11/07/2014 04:44 PM, Petr Vobornik wrote:

On 7.11.2014 08:58, Martin Kosek wrote:

On 11/04/2014 05:17 PM, Nathaniel McCallum wrote:

On Wed, 2014-10-29 at 09:34 -0400, Nathaniel McCallum wrote:

On Wed, 2014-10-29 at 12:21 +0100, Petr Viktorin wrote:

On 10/29/2014 10:37 AM, Martin Kosek wrote:

On 10/28/2014 09:59 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-23 at 18:07 -0400, Nathaniel McCallum wrote:

This patch gives the administrator variables to control the size of
the authentication and synchronization windows for OTP tokens.

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

NOTE: There is one known issue with this patch which I don't know
how to
solve. This patch changes the schema in
install/share/60ipaconfig.ldif.
On an upgrade, all of the new attributeTypes appear correctly.
However,
the modifications to the pre-existing objectClass do not show up
on the
server. What am I doing wrong?

After modifying ipaGuiConfig manually, everything in this patch
works
just fine.

This new version takes into account the new (proper) OIDs and
attribute
names.

Thanks Nathaniel!


The above known issue still remains.

Petr3, any idea what could have gone wrong? ObjectClass MAY list
extension
should work just fine, AFAIK.

You added a blank line to the LDIF file. This is an entry separator, so
the objectClasses after the blank line don't belong to cn=schema, so
they aren't considered in the update.
Without the blank line it works fine.

Thanks for the catch!

Here is a version without the blank line.

I forgot to remove the old steps defines. This patch performs this
cleanup.

I am now wondering, is the global config object really the nest place to
add these OTP specific settings?

I would prefer not to overload the object and instead:
- create new ipaOTPConfig objectclass
- add it to cn=otp,$SUFFIX
- create otpconfig-mod and otpconfig-show commands to follow an example
of dnsconfig-* and trustconfig-* commands

IMO, this would allow more flexibility for the OTP settings and would
also scale better for the future updates.

+1

I will comment the patch as if ^^ would not exist because it will still be
needed in the new plugin.

Because of ^^ I did not test, just read.

1. Got:
install/ui/src/freeipa/serverconfig.js(135): lint warning: extra comma is not
recommended in array initializers

Please run:
   jsl -nofilelisting -nosummary -nologo -conf jsl.conf
in install/ui directory

The goal is no have no warnings and errors.

2. new attrs should be added to 'System: Read Global Configuration' managed
permission

+1. Though if we go with OTP config, it should be called

System: Read OTP Configuration

Martin

Attached is a new set of patches that replaces this single patch. This
now fixes multiple issues.

I now create two new entries:
  * cn=TOTP,cn=Token Config,cn=etc,$SUFFIX
  * cn=HOTP,cn=Token Config,cn=etc,$SUFFIX

There are two corresponding CLI commands:
  * totpconfig-(show|mod)
  * hotpconfig-(show|mod)

There is no UI support for this yet (pointers welcome).

This is designed so that eventually tokens can grow a per-token
override, but I have not yet implemented this feature (it should be easy
in the future).

Additionally, I had to do some shared refactoring to address issues in
ipa-otp-lasttoken, which is why all of these are now merged into a
single patch set.

Nathaniel


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Hello Nathaniel,

Sorry for this long delay.
The patch 0001 is fine for me. Ack

I have a question regarding 0002.
The function 'otp_config_update' is called in postop in order to 
'update' the configuration in case of successful op.

In 'update' it can updates 'config_record->value.
In case the SLAPI_ENTRY_POST_OP sdn is not the the config_rec->sdn  but 
the SLAPI_TARGET_SDN sdn is the config_rec->sdn , it resets 
'config_record'->value to 'config_record->dflt'. Is that the expected 
effect ?


thanks
thierry


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration

2014-12-01 Thread Petr Spacek

On 1.12.2014 14:39, Martin Basti wrote:
> On 24/11/14 17:24, Petr Spacek wrote:
>> Hello!
>>
>> Thank you for the patch. It is not ready yet but the overall direction seems
>> good. Please see my comments in-line.
>>
>> On 24.11.2014 14:35, Martin Basti wrote:
>>> Ticket: https://fedorahosted.org/freeipa/ticket/4721
>>> Patch attached
>>>
>>> -- 
>>> Martin Basti
>>>
>>>
>>> freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch
>>>
>>>
>>>  From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001
>>> From: Martin Basti 
>>> Date: Fri, 21 Nov 2014 16:54:09 +0100
>>> Subject: [PATCH] Detect and warn about invalid DNS forward zone 
>>> configuration
>>>
>>> Shows warning if forward and parent authoritative zone do not have
>>> proper NS record delegation, which can cause the forward zone will be
>>> ineffective and forwarding will not work.
>>>
>>> The chande in the test was required due python changes order of elemnts
>>> in dict (python doesnt guarantee an order in dict)
>>>
>>> Ticket: https://fedorahosted.org/freeipa/ticket/4721
>>> ---
>>>   ipalib/messages.py  |  12 +++
>>>   ipalib/plugins/dns.py   | 147
>>> +---
>>>   ipatests/test_xmlrpc/test_dns_plugin.py |   2 +-
>>>   3 files changed, 149 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/ipalib/messages.py b/ipalib/messages.py
>>> index
>>> 102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f
>>> 100644
>>> --- a/ipalib/messages.py
>>> +++ b/ipalib/messages.py
>>> @@ -200,6 +200,18 @@ class
>>> DNSServerDoesNotSupportDNSSECWarning(PublicMessage):
>>>  u"If DNSSEC validation is enabled on IPA server(s), "
>>>  u"please disable it.")
>>>   +class ForwardzoneIsNotEffectiveWarning(PublicMessage):
>>> +"""
>>> +**13008** Forwardzone is not effective, forwarding will not work 
>>> because
>>> +there is authoritative parent zone, without proper NS delegation
>>> +"""
>>> +
>>> +errno = 13008
>>> +type = "warning"
>>> +format = _(u"forward zone \"%(fwzone)s\" is not effective (missing
>>> proper "
>>> +   u"NS delegation in authoritative zone \"%(authzone)s\"). "
>>> +   u"Forwarding may not work.")
>> I think that the error message could be made mode useful:
>>
>> "Forwarding will not work. Please add NS record 
>> 
>> to parent zone %(authzone)s" (or something like that).
>>
>>> +
>>> def iter_messages(variables, base):
>>>   """Return a tuple with all subclasses
>>> diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
>>> index
>>> c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229
>>> 100644
>>> --- a/ipalib/plugins/dns.py
>>> +++ b/ipalib/plugins/dns.py
>>> @@ -1725,6 +1725,79 @@ def _normalize_zone(zone):
>>>   return zone
>>> +def _find_zone_which_makes_fw_zone_ineffective(fwzonename):
>> Generally, this method finds an authoritative zone for given "fwzonename".
>> What about method name _find_auth_zone_ldap(name) ?
>>
>>> +"""
>>> +Check if forward zone is effective.
>>> +
>>> +If parent zone exists as authoritative zone, forward zone will not
>>> +forward queries. It is necessary to delegate authority of forward zone
>> I would clarify it: "forward queries by default."
>>
>>
>>> +to another server (non IPA DNS server).
>> I would personally omit "(non IPA DNS server)" because this mechanism is not
>> related to IPA domain at all.
>>
>>> +Example:
>>> +
>>> +Forward zone: sub.example.com
>>> +Zone: example.com
>>> +
>>> +Forwarding will not work, because server thinks it is authoritative
>>> +and returns NXDOMAIN
>>> +
>>> +Adding record: sub.example.com NS nameserver.out.of.ipa.domain.
>> Again, this is not related to IPA domain at all. I propose this text:
>> "Adding record: sub.example.com NS ns.sub.example.com."
>>
>>> +will delegate authority to another server, and IPA DNS server will
>>> +forward DNS queries.
>>> +
>>> +:param fwzonename: forwardzone
>>> +:return: None if effective, name of authoritative zone otherwise
>>> +"""
>>> +assert isinstance(fwzonename, DNSName)
>>> +
>>> +# get all zones
>>> +zones = api.Command.dnszone_find(pkey_only=True,
>>> +sizelimit=0)['result']
>> Ooooh, are you serious? :-) I don't like this approach, I would rather chop
>> left-most labels from "name" and so dnszone_find() one by one. What if you
>> have many DNS zones?
>>
>>
>> This could be thrown away if you iterate only over relevant zones.
>>> +zonenames = [zone['idnsname'][0].make_absolute() for zone in zones]
>>> +zonenames.sort(reverse=True, key=len)  # sort, we need longest match
>>> +
>>> +# check if is there a zone which can cause the forward zone will
>>> +# be ineffective
>>> +sub_of_auth_zone = None
>>> +for name in zonenames:
>>> +

Re: [Freeipa-devel] FreeIPA integration with external DNS services

2014-12-01 Thread Alexander Bokovoy


On Mon, 01 Dec 2014, Simo Sorce wrote:

On Mon, 01 Dec 2014 16:17:54 +0100
Petr Spacek  wrote:


On 14.11.2014 17:31, Petr Spacek wrote:
> On 14.11.2014 02:22, Simo Sorce wrote:
>> On Tue, 11 Nov 2014 16:29:51 +0100
>> Petr Spacek  wrote:
>>
>>> Hello,
>>>
>>> this thread is about RFE
>>> "IPA servers when installed should register themselves in the
>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424
>>>
>>> It is not a complete design, just a raw idea.
>>>
>>>
>>> Use case
>>> 
>>> FreeIPA installation to a network with existing DNS
>>> infrastructure + network administrator who is not willing to
>>> add/maintain new DNS servers "just for FreeIPA".
>>>
>>>
>>> High-level idea
>>> ===
>>> - Transform dns* commands from FreeIPA framework to equivalent
>>> "nsupdate" commands and send DNS updates to existing DNS servers.
>>> - Provide necessary encryption/signing keys to nsupdate.
>>>
>>>
>>> 1) Integration to FreeIPA framework
>>> ===
>>> First of all, we need to decide if "external DNS integration" can
>>> be used at the same time with FreeIPA-integrated DNS or not.
>>> Side-question is what to do if a first server is installed with
>>> external-DNS but another replica is being installed with
>>> integrated-DNS and so on.
>>
>> I think being able to integrate with an external DNS is important,
>> and not just at the server level, being able to distribute TSIG
>> keys to client would be nice too, though a lot less important,
>> than getting server integration..
>
> Using TSIG on many clients is very problematic. Keep in mind that
> TSIG is basically HMAC computed using symmetric key so:
> a) Every client would have to use the same key - this is a security
> nightmare. b) We would have to distribute and maintain many keys
> for many^2 clients, which is an administrative nightmare.
>
> For *clients* I would rather stay with GSS-TSIG which is much more
> manageable because we can use Kerberos trust and Keytab
> distribution is already solved by ipa-client-install.
>
> Alternative for clients would be to use FreeIPA server as proxy
> which encapsulates TSIG keys and issues update requests on behalf
> of clients. This would be FreeIPA-specific but any
> TSIG-distribution mechanism will be FreeIPA-specific anyway.
>
> TSIG standard explicitly says that there is no standardized
> distribution mechanism.
>
>>> In other words, the question is if current "dns.py" plugin shipped
>>> with FreeIPA framework should be:
>>>
>>> a) Extended dns.py with dnsexternal-* commands
>>> --
>>> Disadvantages:
>>> - It complicate FreeIPA DNS interface which is a complex beast
>>> even now.
>>> - We would have add condition to every DNS API call in installers
>>> which would increase horribleness of the installer code even more
>>> (or add another layer of abstraction...).
>>
>> I agree having a special command is undesirable.
>>>
>>> - I don't see a point in using integrated-DNS with external-DNS at
>>> the same time. To use integrated-DNS you have to get a proper DNS
>>> delegation from parent domain - and if you can get the delegation
>>> then there is no point in using external DNS ...
>>
>> I disagree on this point, it makes a lot of sense to have some
>> zones maintained by IPA and ... some not.
>>
>>> Advantages:
>>> - You can use external & integrated DNS at the same time.
>>
>> We can achieve the same w/o a new ipa level command.
>
> This needs to be decided by FreeIPA framework experts ...
>
> Petr^3 came up with clever 'proxy' idea for IPA-commands. This
> proxy would provide all ipa dns* commands and dispatch user-issued
> commands to appropriate FreeIPA-plugin (internal-dns or
> external-dns). This decision could depend on some values in LDAP.
>
>>> b) Replace dns.py with another implementation of current
>>> dnszone-* & dnsrecord-* API.
>>> -
>>> This seems like a cleaner approach to me. It could be shipped as
>>> ipa-server-dns-external package (opposed to "standard"
>>> ipa-server-dns package).
>>>
>>> Advantages:
>>> - It could seamlessly work with FreeIPA client installer because
>>> the dns*->nsupdate command transformation would be done on
>>> FreeIPA server and client doesn't need to know about it.
>>> - Does not require re-training/not much new documentation because
>>> commands are the same.
>>>
>>> Disadvantages:
>>> - You can't use integrated & external DNS at the same time (but I
>>> don't think it justifies the added complexity).
>>
>> I disagree.
>>
>> One of the reason to use a mix is to allow smooth migrations where
>> zones are moved into (or out of) IPA one by one.
>
> Good point, I agree. I will focus on supporting both (internal and
> external) DNS at the same time.
>
>>> Petr^3 or anyone else, what do you propose?
>>
>> I think what I'd like to see is to be able to configure a DNS zone
>> in LDAP and mark it external.
>> The z

Re: [Freeipa-devel] FreeIPA integration with external DNS services

2014-12-01 Thread Simo Sorce

On Mon, 01 Dec 2014 16:17:54 +0100
Petr Spacek  wrote:

> On 14.11.2014 17:31, Petr Spacek wrote:
> > On 14.11.2014 02:22, Simo Sorce wrote:
> >> On Tue, 11 Nov 2014 16:29:51 +0100
> >> Petr Spacek  wrote:
> >>
> >>> Hello,
> >>>
> >>> this thread is about RFE
> >>> "IPA servers when installed should register themselves in the
> >>> external DNS" https://fedorahosted.org/freeipa/ticket/4424
> >>>
> >>> It is not a complete design, just a raw idea.
> >>>
> >>>
> >>> Use case
> >>> 
> >>> FreeIPA installation to a network with existing DNS
> >>> infrastructure + network administrator who is not willing to
> >>> add/maintain new DNS servers "just for FreeIPA".
> >>>
> >>>
> >>> High-level idea
> >>> ===
> >>> - Transform dns* commands from FreeIPA framework to equivalent
> >>> "nsupdate" commands and send DNS updates to existing DNS servers.
> >>> - Provide necessary encryption/signing keys to nsupdate.
> >>>
> >>>
> >>> 1) Integration to FreeIPA framework
> >>> ===
> >>> First of all, we need to decide if "external DNS integration" can
> >>> be used at the same time with FreeIPA-integrated DNS or not.
> >>> Side-question is what to do if a first server is installed with
> >>> external-DNS but another replica is being installed with
> >>> integrated-DNS and so on.
> >>
> >> I think being able to integrate with an external DNS is important,
> >> and not just at the server level, being able to distribute TSIG
> >> keys to client would be nice too, though a lot less important,
> >> than getting server integration..
> > 
> > Using TSIG on many clients is very problematic. Keep in mind that
> > TSIG is basically HMAC computed using symmetric key so:
> > a) Every client would have to use the same key - this is a security
> > nightmare. b) We would have to distribute and maintain many keys
> > for many^2 clients, which is an administrative nightmare.
> > 
> > For *clients* I would rather stay with GSS-TSIG which is much more
> > manageable because we can use Kerberos trust and Keytab
> > distribution is already solved by ipa-client-install.
> > 
> > Alternative for clients would be to use FreeIPA server as proxy
> > which encapsulates TSIG keys and issues update requests on behalf
> > of clients. This would be FreeIPA-specific but any
> > TSIG-distribution mechanism will be FreeIPA-specific anyway.
> > 
> > TSIG standard explicitly says that there is no standardized
> > distribution mechanism.
> > 
> >>> In other words, the question is if current "dns.py" plugin shipped
> >>> with FreeIPA framework should be:
> >>>
> >>> a) Extended dns.py with dnsexternal-* commands
> >>> --
> >>> Disadvantages:
> >>> - It complicate FreeIPA DNS interface which is a complex beast
> >>> even now.
> >>> - We would have add condition to every DNS API call in installers
> >>> which would increase horribleness of the installer code even more
> >>> (or add another layer of abstraction...).
> >>
> >> I agree having a special command is undesirable.
> >>>
> >>> - I don't see a point in using integrated-DNS with external-DNS at
> >>> the same time. To use integrated-DNS you have to get a proper DNS
> >>> delegation from parent domain - and if you can get the delegation
> >>> then there is no point in using external DNS ...
> >>
> >> I disagree on this point, it makes a lot of sense to have some
> >> zones maintained by IPA and ... some not.
> >>
> >>> Advantages:
> >>> - You can use external & integrated DNS at the same time.
> >>
> >> We can achieve the same w/o a new ipa level command.
> > 
> > This needs to be decided by FreeIPA framework experts ...
> > 
> > Petr^3 came up with clever 'proxy' idea for IPA-commands. This
> > proxy would provide all ipa dns* commands and dispatch user-issued
> > commands to appropriate FreeIPA-plugin (internal-dns or
> > external-dns). This decision could depend on some values in LDAP.
> > 
> >>> b) Replace dns.py with another implementation of current
> >>> dnszone-* & dnsrecord-* API.
> >>> -
> >>> This seems like a cleaner approach to me. It could be shipped as
> >>> ipa-server-dns-external package (opposed to "standard"
> >>> ipa-server-dns package).
> >>>
> >>> Advantages:
> >>> - It could seamlessly work with FreeIPA client installer because
> >>> the dns*->nsupdate command transformation would be done on
> >>> FreeIPA server and client doesn't need to know about it.
> >>> - Does not require re-training/not much new documentation because
> >>> commands are the same.
> >>>
> >>> Disadvantages:
> >>> - You can't use integrated & external DNS at the same time (but I
> >>> don't think it justifies the added complexity).
> >>
> >> I disagree.
> >>
> >> One of the reason to use a mix is to allow smooth migrations where
> >> zones are moved into (or out of) IPA one by one.
> > 
> > Good point, I agree. I will focus on supporting both (internal a

Re: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade

2014-12-01 Thread Martin Basti


On 01/12/14 08:46, Jan Cholasta wrote:

Hi,

Dne 27.11.2014 v 14:24 Martin Basti napsal(a):

Ticket: https://fedorahosted.org/freeipa/ticket/4676
Replaces current workaround. Should go to 4.1.3.
Patch attached.


When constructing URLs with host:port, please use 
ipautil.format_netloc().


wget should be added as a dependency of freeipa-python in the spec file.

Honza


Updated patch attached.

--
Martin Basti

From daf56e4e4a0126f0dd528876a209f0687ca3ad06 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Tue, 18 Nov 2014 19:49:15 +0100
Subject: [PATCH] Using wget to get status of CA

This is just workaround

Ticket: https://fedorahosted.org/freeipa/ticket/4676
---
 freeipa.spec.in |  1 +
 install/tools/ipa-upgradeconfig |  4 
 ipaplatform/redhat/services.py  | 27 ++-
 ipapython/dogtag.py | 18 +++---
 4 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 95ec6210a157fd158d81d97efbd46f3d35facbc6..39166057ecd0d5a4bacef4e79bed49135f72fff4 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -292,6 +292,7 @@ Requires: python-qrcode-core >= 5.0.0
 Requires: python-pyasn1
 Requires: python-dateutil
 Requires: python-yubico
+Requires: wget
 
 Conflicts: %{alt_name}-python
 Obsoletes: %{alt_name}-python < %{version}
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index 32fea4d0a42ac7607fffaa17339b23267f2760f6..628fe20d7c7dbdc5aaae5cd60eb357694a3b51a5 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -1486,10 +1486,6 @@ def main():
 ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME)
 except ipautil.CalledProcessError, e:
 root_logger.error("Failed to restart %s: %s", ca.service_name, e)
-# FIXME https://fedorahosted.org/freeipa/ticket/4676
-# workaround
-except RuntimeError as e:
-root_logger.warning(str(e))
 
 set_sssd_domain_option('ipa_server_mode', 'True')
 
diff --git a/ipaplatform/redhat/services.py b/ipaplatform/redhat/services.py
index 58ffebc48477193c7203161d2578b3040862b4e6..20d0adec421ecd3285464e2a51b9d5c61a0e3d92 100644
--- a/ipaplatform/redhat/services.py
+++ b/ipaplatform/redhat/services.py
@@ -24,6 +24,7 @@ Contains Red Hat OS family-specific service class implementations.
 
 import os
 import time
+import xml.dom.minidom
 
 from ipaplatform.tasks import tasks
 from ipaplatform.base import services as base_services
@@ -185,7 +186,31 @@ class RedHatCAService(RedHatService):
 op_timeout = time.time() + timeout
 while time.time() < op_timeout:
 try:
-status = dogtag.ca_status(use_proxy=use_proxy)
+# FIXME https://fedorahosted.org/freeipa/ticket/4716
+# workaround
+#
+# status = dogtag.ca_status(use_proxy=use_proxy)
+#
+port = 8443
+if use_proxy:
+port = 443
+
+url = "https://%(host_port)s%(path)s" % {
+"host_port": ipautil.format_netloc(api.env.ca_host, port),
+"path": "/ca/admin/ca/getStatus"
+}
+
+args = [
+paths.BIN_WGET,
+'-S', '-O', '-',
+'--timeout=30',
+url
+]
+
+stdout, stderr, returncode = ipautil.run(args)
+
+status = dogtag._parse_ca_status(stdout)
+# end of workaround
 except Exception:
 status = 'check interrupted'
 root_logger.debug('The CA status is: %s' % status)
diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py
index 0e0aacca798377517244075ed6b07dff63e87358..675d2a77fe30b9109c17089f129b189282ffa57b 100644
--- a/ipapython/dogtag.py
+++ b/ipapython/dogtag.py
@@ -191,6 +191,16 @@ def get_ca_certchain(ca_host=None, dogtag_constants=None):
 return chain
 
 
+def _parse_ca_status(body):
+doc = xml.dom.minidom.parseString(body)
+try:
+item_node = doc.getElementsByTagName("XMLResponse")[0]
+item_node = item_node.getElementsByTagName("Status")[0]
+return item_node.childNodes[0].data
+except IndexError:
+raise error_from_xml(doc, _("Retrieving CA status failed: %s"))
+
+
 def ca_status(ca_host=None, use_proxy=True):
 """Return the status of the CA, and the httpd proxy in front of it
 
@@ -214,13 +224,7 @@ def ca_status(ca_host=None, use_proxy=True):
 elif status != 200:
 raise errors.RemoteRetrieveError(
 reason=_("Retrieving CA status failed: %s") % reason)
-doc = xml.dom.minidom.parseString(body)
-try:
-item_node = doc.getElementsByTagName("XMLResponse")[0]
-item_node = item_node.getElementsByTagName("Status")[0]
-return item_node.childNodes[0].data
-except IndexError:
-

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

2014-12-01 Thread Martin Kosek

On 12/01/2014 04:25 PM, Rob Crittenden wrote:
> Gabe Alford wrote:
>>
>> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek > > wrote:
>>
>> On 11/30/2014 03:28 AM, Gabe Alford wrote:
>> > Ignore the last patch. Updated patch attached.
>> >
>> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford
>> mailto:redhatri...@gmail.com>> wrote:
>> >
>> >> This patch removes the app_PYTHON usage.
>> >>
>> >> Thanks,
>> >>
>> >> Gabe
>> >>
>> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek > > wrote:
>> >>
>> >>> Exactly, this was the message from Martin :-) I did not test it
>> myself,
>> >>> but
>> >>> removing all app_PYTHON should be benign given we use Python
>> setup.py
>> >>> packaging.
>> >>>
>> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote:
>>  Thanks guys. Sounds like it would be better to submit a patch that
>> >>> removes
>>  app_PYTHON if it is considered dead code.
>> 
>>  Gabe
>> 
>>  On Thursday, November 27, 2014, Petr Spacek > > wrote:
>> 
>> > On 27.11.2014 11:00, Martin Basti wrote:
>> >> On 27/11/14 00:50, Gabe Alford wrote:
>> >>> Hello,
>> >>>
>> >>>Wondering if I could get a review. Updated patch
>> attached.
>> >>>
>> >>> Thanks,
>> >>> Gabe
>> >>>
>> >>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford
>> mailto:redhatri...@gmail.com>
>> > 
>> >>> 
>> >> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> Fix for https://fedorahosted.org/freeipa/ticket/4700
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Gabe
>> >>>
>> >>>
>> >>>
>> >> Hello,
>> >>
>> >> sorry for late response.
>> >>
>> >> We push this ticket to backlog, as it would be part of build
>> system
>> > refactoring.
>> >> The "app_PYTHON" statement is not used anymore in IPA, the better
>> > solution is
>> >> remove it, instead of keeping dead code up-to-date.
>> >
>> > Just to clarify:
>> > It can be pushed if it works, there is no need to postpone
>> accepting
>> >>> patch
>> > if
>> > the patch seems okay and doesn't break anything.
>> >
>> > Martin, please keep in mind that contributions are welcome at
>> any time.
>> >
>> > Milestones in Trac reflect our view of priorities but it doesn't
>> >>> prevent us
>> > from accepting correct patches from contributions at any time, no
>> >>> matter
>> > which
>> > priority is stated in Trac (or even if there is no ticket for
>> it ...).
>> >
>> > --
>> > Petr^2 Spacek
>>
>> Worked in my tests, I did not see any breakage. I guess we can also
>> remove the
>> ipa-client/ipaclient/Makefile.am while we are at it.
>>
>> Martin
>>
>>
>> It looks like the ipaclient/Makefile.am is still being used. I tried
>> removing it and there were errors in the build, but maybe I am wrong?
> 
> It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab.
> 
> Feel free to rip out the outdated hg ChangeLog stuff though.
> 
> rob

I think Gabe was asking about ipa-client/ipaclient/Makefile.am and not about
ipa-client/Makefile.am - we still need this one as Rob correctly said.

The failure that Gabe hit in build probably comes from the the SUBDIR reference
in ipa-client/Makefile.am file. I assume that if the reference is removed, the
removal should work.

And yes, you can remove the Changelog too if you are OK with it :)

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

2014-12-01 Thread Rob Crittenden

Gabe Alford wrote:
> 
> On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek  > wrote:
> 
> On 11/30/2014 03:28 AM, Gabe Alford wrote:
> > Ignore the last patch. Updated patch attached.
> >
> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford
> mailto:redhatri...@gmail.com>> wrote:
> >
> >> This patch removes the app_PYTHON usage.
> >>
> >> Thanks,
> >>
> >> Gabe
> >>
> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek  > wrote:
> >>
> >>> Exactly, this was the message from Martin :-) I did not test it
> myself,
> >>> but
> >>> removing all app_PYTHON should be benign given we use Python
> setup.py
> >>> packaging.
> >>>
> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote:
>  Thanks guys. Sounds like it would be better to submit a patch that
> >>> removes
>  app_PYTHON if it is considered dead code.
> 
>  Gabe
> 
>  On Thursday, November 27, 2014, Petr Spacek  > wrote:
> 
> > On 27.11.2014 11:00, Martin Basti wrote:
> >> On 27/11/14 00:50, Gabe Alford wrote:
> >>> Hello,
> >>>
> >>>Wondering if I could get a review. Updated patch
> attached.
> >>>
> >>> Thanks,
> >>> Gabe
> >>>
> >>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford
> mailto:redhatri...@gmail.com>
> > 
> >>> 
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Fix for https://fedorahosted.org/freeipa/ticket/4700
> >>>
> >>> Thanks,
> >>>
> >>> Gabe
> >>>
> >>>
> >>>
> >> Hello,
> >>
> >> sorry for late response.
> >>
> >> We push this ticket to backlog, as it would be part of build
> system
> > refactoring.
> >> The "app_PYTHON" statement is not used anymore in IPA, the better
> > solution is
> >> remove it, instead of keeping dead code up-to-date.
> >
> > Just to clarify:
> > It can be pushed if it works, there is no need to postpone
> accepting
> >>> patch
> > if
> > the patch seems okay and doesn't break anything.
> >
> > Martin, please keep in mind that contributions are welcome at
> any time.
> >
> > Milestones in Trac reflect our view of priorities but it doesn't
> >>> prevent us
> > from accepting correct patches from contributions at any time, no
> >>> matter
> > which
> > priority is stated in Trac (or even if there is no ticket for
> it ...).
> >
> > --
> > Petr^2 Spacek
> 
> Worked in my tests, I did not see any breakage. I guess we can also
> remove the
> ipa-client/ipaclient/Makefile.am while we are at it.
> 
> Martin
> 
> 
> It looks like the ipaclient/Makefile.am is still being used. I tried
> removing it and there were errors in the build, but maybe I am wrong?

It is needed to build ipa-join, ipa-getkeytab and ipa-rmkeytab.

Feel free to rip out the outdated hg ChangeLog stuff though.

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

2014-12-01 Thread Gabe Alford

On Mon, Dec 1, 2014 at 6:05 AM, Martin Kosek  wrote:

> On 11/30/2014 03:28 AM, Gabe Alford wrote:
> > Ignore the last patch. Updated patch attached.
> >
> > On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford 
> wrote:
> >
> >> This patch removes the app_PYTHON usage.
> >>
> >> Thanks,
> >>
> >> Gabe
> >>
> >> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek 
> wrote:
> >>
> >>> Exactly, this was the message from Martin :-) I did not test it myself,
> >>> but
> >>> removing all app_PYTHON should be benign given we use Python setup.py
> >>> packaging.
> >>>
> >>> On 11/27/2014 04:27 PM, Gabe Alford wrote:
>  Thanks guys. Sounds like it would be better to submit a patch that
> >>> removes
>  app_PYTHON if it is considered dead code.
> 
>  Gabe
> 
>  On Thursday, November 27, 2014, Petr Spacek 
> wrote:
> 
> > On 27.11.2014 11:00, Martin Basti wrote:
> >> On 27/11/14 00:50, Gabe Alford wrote:
> >>> Hello,
> >>>
> >>>Wondering if I could get a review. Updated patch attached.
> >>>
> >>> Thanks,
> >>> Gabe
> >>>
> >>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford <
> redhatri...@gmail.com
> > 
> >>> > wrote:
> >>>
> >>> Hello,
> >>>
> >>> Fix for https://fedorahosted.org/freeipa/ticket/4700
> >>>
> >>> Thanks,
> >>>
> >>> Gabe
> >>>
> >>>
> >>>
> >> Hello,
> >>
> >> sorry for late response.
> >>
> >> We push this ticket to backlog, as it would be part of build system
> > refactoring.
> >> The "app_PYTHON" statement is not used anymore in IPA, the better
> > solution is
> >> remove it, instead of keeping dead code up-to-date.
> >
> > Just to clarify:
> > It can be pushed if it works, there is no need to postpone accepting
> >>> patch
> > if
> > the patch seems okay and doesn't break anything.
> >
> > Martin, please keep in mind that contributions are welcome at any
> time.
> >
> > Milestones in Trac reflect our view of priorities but it doesn't
> >>> prevent us
> > from accepting correct patches from contributions at any time, no
> >>> matter
> > which
> > priority is stated in Trac (or even if there is no ticket for it
> ...).
> >
> > --
> > Petr^2 Spacek
>
> Worked in my tests, I did not see any breakage. I guess we can also remove
> the
> ipa-client/ipaclient/Makefile.am while we are at it.
>
> Martin
>

It looks like the ipaclient/Makefile.am is still being used. I tried
removing it and there were errors in the build, but maybe I am wrong?

Gabe
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] FreeIPA integration with external DNS services

2014-12-01 Thread Petr Spacek

On 14.11.2014 17:31, Petr Spacek wrote:
> On 14.11.2014 02:22, Simo Sorce wrote:
>> On Tue, 11 Nov 2014 16:29:51 +0100
>> Petr Spacek  wrote:
>>
>>> Hello,
>>>
>>> this thread is about RFE
>>> "IPA servers when installed should register themselves in the
>>> external DNS" https://fedorahosted.org/freeipa/ticket/4424
>>>
>>> It is not a complete design, just a raw idea.
>>>
>>>
>>> Use case
>>> 
>>> FreeIPA installation to a network with existing DNS infrastructure +
>>> network administrator who is not willing to add/maintain new DNS
>>> servers "just for FreeIPA".
>>>
>>>
>>> High-level idea
>>> ===
>>> - Transform dns* commands from FreeIPA framework to equivalent
>>> "nsupdate" commands and send DNS updates to existing DNS servers.
>>> - Provide necessary encryption/signing keys to nsupdate.
>>>
>>>
>>> 1) Integration to FreeIPA framework
>>> ===
>>> First of all, we need to decide if "external DNS integration" can be
>>> used at the same time with FreeIPA-integrated DNS or not.
>>> Side-question is what to do if a first server is installed with
>>> external-DNS but another replica is being installed with
>>> integrated-DNS and so on.
>>
>> I think being able to integrate with an external DNS is important, and
>> not just at the server level, being able to distribute TSIG keys to
>> client would be nice too, though a lot less important, than getting
>> server integration..
> 
> Using TSIG on many clients is very problematic. Keep in mind that TSIG is
> basically HMAC computed using symmetric key so:
> a) Every client would have to use the same key - this is a security nightmare.
> b) We would have to distribute and maintain many keys for many^2 clients,
> which is an administrative nightmare.
> 
> For *clients* I would rather stay with GSS-TSIG which is much more manageable
> because we can use Kerberos trust and Keytab distribution is already solved
> by ipa-client-install.
> 
> Alternative for clients would be to use FreeIPA server as proxy which
> encapsulates TSIG keys and issues update requests on behalf of clients. This
> would be FreeIPA-specific but any TSIG-distribution mechanism will be
> FreeIPA-specific anyway.
> 
> TSIG standard explicitly says that there is no standardized distribution
> mechanism.
> 
>>> In other words, the question is if current "dns.py" plugin shipped
>>> with FreeIPA framework should be:
>>>
>>> a) Extended dns.py with dnsexternal-* commands
>>> --
>>> Disadvantages:
>>> - It complicate FreeIPA DNS interface which is a complex beast even
>>> now.
>>> - We would have add condition to every DNS API call in installers
>>> which would increase horribleness of the installer code even more (or
>>> add another layer of abstraction...).
>>
>> I agree having a special command is undesirable.
>>>
>>> - I don't see a point in using integrated-DNS with external-DNS at
>>> the same time. To use integrated-DNS you have to get a proper DNS
>>> delegation from parent domain - and if you can get the delegation
>>> then there is no point in using external DNS ...
>>
>> I disagree on this point, it makes a lot of sense to have some zones
>> maintained by IPA and ... some not.
>>
>>> Advantages:
>>> - You can use external & integrated DNS at the same time.
>>
>> We can achieve the same w/o a new ipa level command.
> 
> This needs to be decided by FreeIPA framework experts ...
> 
> Petr^3 came up with clever 'proxy' idea for IPA-commands. This proxy would
> provide all ipa dns* commands and dispatch user-issued commands to appropriate
> FreeIPA-plugin (internal-dns or external-dns). This decision could depend on
> some values in LDAP.
> 
>>> b) Replace dns.py with another implementation of current dnszone-* &
>>> dnsrecord-* API.
>>> -
>>> This seems like a cleaner approach to me. It could be shipped as
>>> ipa-server-dns-external package (opposed to "standard" ipa-server-dns
>>> package).
>>>
>>> Advantages:
>>> - It could seamlessly work with FreeIPA client installer because the
>>> dns*->nsupdate command transformation would be done on FreeIPA server
>>> and client doesn't need to know about it.
>>> - Does not require re-training/not much new documentation because
>>> commands are the same.
>>>
>>> Disadvantages:
>>> - You can't use integrated & external DNS at the same time (but I
>>> don't think it justifies the added complexity).
>>
>> I disagree.
>>
>> One of the reason to use a mix is to allow smooth migrations where
>> zones are moved into (or out of) IPA one by one.
> 
> Good point, I agree. I will focus on supporting both (internal and external)
> DNS at the same time.
> 
>>> Petr^3 or anyone else, what do you propose?
>>
>> I think what I'd like to see is to be able to configure a DNS zone in
>> LDAP and mark it external.
>> The zone would held the TSIG keys necessary to perform DNS updates.
>>
>> When the regular ip

Re: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration

2014-12-01 Thread Gabe Alford

Thanks, David. You're totally right. I am good with it.

thanks,

Gabe

On Mon, Dec 1, 2014 at 5:20 AM, David Kupka  wrote:

> On 11/30/2014 02:03 AM, Gabe Alford wrote:
>
>> Hello,
>>
>> Fix for https://fedorahosted.org/freeipa/ticket/4583
>>
>> Thanks,
>>
>> Gabe
>>
>>
>>
>> ___
>> Freeipa-devel mailing list
>> Freeipa-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>>  Hello!
>
> Thanks for patch. I guess that you wanted to add the "iburst" option only
> once. Right now it will generate lines like:
>
> server  iburst iburst
>
> Attaching the fixed patch. Are you satisfied with it?
>
> --
> David Kupka
>
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration

2014-12-01 Thread Martin Basti


On 24/11/14 17:24, Petr Spacek wrote:

Hello!

Thank you for the patch. It is not ready yet but the overall direction seems
good. Please see my comments in-line.

On 24.11.2014 14:35, Martin Basti wrote:

Ticket: https://fedorahosted.org/freeipa/ticket/4721
Patch attached

--
Martin Basti


freeipa-mbasti-0170-Detect-and-warn-about-invalid-DNS-forward-zone-confi.patch


 From a5a19137e3ddf2d2d48cfbdb2968b6f68ac8f772 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 21 Nov 2014 16:54:09 +0100
Subject: [PATCH] Detect and warn about invalid DNS forward zone configuration

Shows warning if forward and parent authoritative zone do not have
proper NS record delegation, which can cause the forward zone will be
ineffective and forwarding will not work.

The chande in the test was required due python changes order of elemnts
in dict (python doesnt guarantee an order in dict)

Ticket: https://fedorahosted.org/freeipa/ticket/4721
---
  ipalib/messages.py  |  12 +++
  ipalib/plugins/dns.py   | 147 +---
  ipatests/test_xmlrpc/test_dns_plugin.py |   2 +-
  3 files changed, 149 insertions(+), 12 deletions(-)

diff --git a/ipalib/messages.py b/ipalib/messages.py
index 
102e35275dbe37328c84ecb3cd5b2a8d8578056f..cc9bae3d6e5c7d3a7401dab89fafb1b60dc1e15f
 100644
--- a/ipalib/messages.py
+++ b/ipalib/messages.py
@@ -200,6 +200,18 @@ class DNSServerDoesNotSupportDNSSECWarning(PublicMessage):
 u"If DNSSEC validation is enabled on IPA server(s), "
 u"please disable it.")
  
+class ForwardzoneIsNotEffectiveWarning(PublicMessage):

+"""
+**13008** Forwardzone is not effective, forwarding will not work because
+there is authoritative parent zone, without proper NS delegation
+"""
+
+errno = 13008
+type = "warning"
+format = _(u"forward zone \"%(fwzone)s\" is not effective (missing proper "
+   u"NS delegation in authoritative zone \"%(authzone)s\"). "
+   u"Forwarding may not work.")

I think that the error message could be made mode useful:

"Forwarding will not work. Please add NS record 
to parent zone %(authzone)s" (or something like that).


+
  
  def iter_messages(variables, base):

  """Return a tuple with all subclasses
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index 
c5d96a8c4fcdf101254ecefb60cb83d63bee6310..4f92da645e0faf784c7deb4b8ce386c1440f4229
 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -1725,6 +1725,79 @@ def _normalize_zone(zone):
  return zone
  
  
+def _find_zone_which_makes_fw_zone_ineffective(fwzonename):

Generally, this method finds an authoritative zone for given "fwzonename".
What about method name _find_auth_zone_ldap(name) ?


+"""
+Check if forward zone is effective.
+
+If parent zone exists as authoritative zone, forward zone will not
+forward queries. It is necessary to delegate authority of forward zone

I would clarify it: "forward queries by default."



+to another server (non IPA DNS server).

I would personally omit "(non IPA DNS server)" because this mechanism is not
related to IPA domain at all.


+Example:
+
+Forward zone: sub.example.com
+Zone: example.com
+
+Forwarding will not work, because server thinks it is authoritative
+and returns NXDOMAIN
+
+Adding record: sub.example.com NS nameserver.out.of.ipa.domain.

Again, this is not related to IPA domain at all. I propose this text:
"Adding record: sub.example.com NS ns.sub.example.com."


+will delegate authority to another server, and IPA DNS server will
+forward DNS queries.
+
+:param fwzonename: forwardzone
+:return: None if effective, name of authoritative zone otherwise
+"""
+assert isinstance(fwzonename, DNSName)
+
+# get all zones
+zones = api.Command.dnszone_find(pkey_only=True,
+sizelimit=0)['result']

Ooooh, are you serious? :-) I don't like this approach, I would rather chop
left-most labels from "name" and so dnszone_find() one by one. What if you
have many DNS zones?


This could be thrown away if you iterate only over relevant zones.

+zonenames = [zone['idnsname'][0].make_absolute() for zone in zones]
+zonenames.sort(reverse=True, key=len)  # sort, we need longest match
+
+# check if is there a zone which can cause the forward zone will
+# be ineffective
+sub_of_auth_zone = None
+for name in zonenames:
+if fwzonename.is_subdomain(name):
+sub_of_auth_zone = name
+break
+
+if sub_of_auth_zone is None:
+return None
+
+# check if forwardzone is delegated in authoritative zone
+# test if exists and get NS record
+try:
+ns_records = api.Command.dnsrecord_show(
+sub_of_auth_zone, fwzonename, raw=True)['result']['nsrecord']
+except (errors.NotFound, KeyError):
+return sub_of_auth_zone

Note: This function should

Re: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods

2014-12-01 Thread Jan Cholasta


Hi,

Dne 1.12.2014 v 14:17 Petr Vobornik napsal(a):

`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab

in order to allow hosts to retrieve keytab of their services or related
hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval
design page

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


Since groups of users are supported with "group" members, we should 
probably also support groups of hosts with "hostgroup" members, for 
consistency.





I'm pondering how to handle Web UI. I'm not font of adding a third pair
of tables to host and service details pages because the amount of space
on the page required for the keytab management is much bigger than its
importance compared to other fields.


Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] Threat model & abuse cases in design documents

2014-12-01 Thread Petr Spacek

Hello,

while wondering about design for 'external DNS integration' feature I have
realized that I did not see any explicit threat model for FreeIPA.

Do we have any? IMHO it would be handy to have it somewhere on wiki so it
could be used as 'checklist' while developing design documents for security
reviews.


Threat model

IMHO our assumed attacker should have these powers:
1) Do active man-in-the-middle attack on network:
- All network communication can be monitored and altered by attacked.
- This includes client<->FreeIPA server communication,
- and also server<->server communication.

2) Compromise normal user account:
I think that in in large networks the probability of successful attack against
at least one user account is almost 1.
So, we should assume that at least one user account was compromised. I.e. our
attacker knows user's password or has equivalent of keytab.

3) Compromise a client machine:
Again, I think that in in large networks the probability of successful attack
against at least one machine is almost 1.
So, we should assume that at least one machine account was compromised. I.e.
our attacker has equivalent of machine keytab and keytabs for services running
on it.

What did I miss? Maybe we should explicitly say how replica files and other
'secrets' (DM password ...) should be handled. It would help with discussion
about automated FreeIPA deployment too.


Also, we should explicitly say that FreeIPA server itself and its LDAP
database is the key to everything. If the FreeIPA server and its LDAP database
is compromised then the game is over - attacker has access to everything.


Abuse cases
===
IMHO security sensitive design documents (e.g. automated FreeIPA deployment,
sub-CAs, Vault, external DNS integration) should explicitly walk through the
thread model and state what is going to happen if FreeIPA infrastructure is
under attack we assume.

E.g. for external DNS integration with symmetric TSIG keys:

Proposal in design document:
- TSIG keys are distributed all to FreeIPA clients using LDAP & GSSAPI and
thus are accessible using any host/client.example.com credentials.

Design assessment with thread model in mind:
-> MitM attack will not reveal anything because we trust GSSAPI.
-> User account compromise will not reveal anything because uses doesn't have
access to TSIG keys.
-> Single compromised client will reveal TSIG keys to attacker so
authentication to external DNS will be completely compromised. This will allow
attacker to modify any records in external DNS.

This could be have very serious consequences if DNSSEC is in place so clients
can fully trust the records and use them for e.g. TLS validation.
--> This could be a reason to re-think the design and remove this weak point.


What do you think?

-- 
Petr^2 Spacek

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods

2014-12-01 Thread Petr Vobornik


`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab

in order to allow hosts to retrieve keytab of their services or related 
hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval 
design page


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


I'm pondering how to handle Web UI. I'm not font of adding a third pair 
of tables to host and service details pages because the amount of space 
on the page required for the keytab management is much bigger than its 
importance compared to other fields.

--
Petr Vobornik
From 5a7b77d47abd5b0ca5b97b667d1478c5e8f8dc3d Mon Sep 17 00:00:00 2001
From: Petr Vobornik 
Date: Mon, 1 Dec 2014 10:15:21 +0100
Subject: [PATCH] add --hosts option to allow/retrieve keytab methods

`--hosts` option added to:
* service-allow-create-keytab
* service-allow-retrieve-keytab
* service-disallow-create-keytab
* service-disallow-retrieve-keytab
* host-allow-create-keytab
* host-allow-retrieve-keytab
* host-disallow-create-keytab
* host-disallow-retrieve-keytab

in order to allow hosts to retrieve keytab of their services or related hosts as described on http://www.freeipa.org/page/V4/Keytab_Retrieval design page

https://fedorahosted.org/freeipa/ticket/4777
---
 API.txt | 24 
 VERSION |  4 +-
 ipalib/plugins/host.py  | 18 ++---
 ipalib/plugins/service.py   | 18 ++---
 ipatests/test_xmlrpc/test_host_plugin.py| 58 ++---
 ipatests/test_xmlrpc/test_service_plugin.py | 42 -
 6 files changed, 128 insertions(+), 36 deletions(-)

diff --git a/API.txt b/API.txt
index 2a63f1e2349f0df69433fa7cb742e269cd42d79f..8c0b530cb0b7855594beeb12f891c29e31893ed5 100644
--- a/API.txt
+++ b/API.txt
@@ -1826,10 +1826,11 @@ output: Output('completed', , None)
 output: Output('failed', , None)
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 command: host_allow_create_keytab
-args: 1,6,3
+args: 1,7,3
 arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
 option: Flag('no_members', autofill=True, default=False, exclude='webui')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1838,10 +1839,11 @@ output: Output('completed', , None)
 output: Output('failed', , None)
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 command: host_allow_retrieve_keytab
-args: 1,6,3
+args: 1,7,3
 arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
 option: Flag('no_members', autofill=True, default=False, exclude='webui')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1866,10 +1868,11 @@ output: Output('result', , None)
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
 command: host_disallow_create_keytab
-args: 1,6,3
+args: 1,7,3
 arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('host*', alwaysask=True, cli_name='hosts', csv=True)
 option: Flag('no_members', autofill=True, default=False, exclude='webui')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('user*', alwaysask=True, cli_name='users', csv=True)
@@ -1878,10 +1881,11 @@ output: Output('completed', , None)
 output: Output('failed', , None)
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 command: host_disallow_retrieve_keytab
-args: 1,6,3
+args: 1,7,3
 arg: Str('fqdn', attribute=True, cli_name='hostname', multivalue=False, primary_key=True, query=True, required=True)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('group*', alwaysask=True, cli_name='groups', csv=True)
+option: Str('h

Re: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds

2014-12-01 Thread Jan Cholasta


Dne 1.12.2014 v 09:10 Jan Cholasta napsal(a):

Hi,

Dne 27.11.2014 v 14:20 Martin Basti napsal(a):

Ticket: https://fedorahosted.org/freeipa/ticket/4771
Patch attached.


I would prefer if you did something like this instead:

  1) Add validate_idn_normalized function with the normalized IDN check
to ipapython.dnsutil, have it raise ValueError if the check fails. (Also
please get rid of the map() call for better readability.)

  2) Use validate_idn_normalized in DNSNameParam.

  3) Do the following in validate_zonemgr_str:

 validate_idn_normalized(zonemgr)
 try:
 zonemgr = DNSName(zonemgr)
 except dns.exception.DNSException as e:
 raise ValueError(e)

Honza



Actually, sratch that, exceptions thrown by python-dns do not have messages.

ACK.

Pushed to:
master: ca25c92ea89661755d7204ac703e8c419c8929fa
ipa-4-1: 07e29d250550f238e5706b348d69632fdbb67bda

Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 380 Improve validation of --instance and --backend options in ipa-restore

2014-12-01 Thread Jan Cholasta


Hi,

the attached patch fixes .

Honza

--
Jan Cholasta
>From 204a065d67a65d9ed43e5eaa22958cd8daf7b15f Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 1 Dec 2014 12:12:15 +
Subject: [PATCH] Improve validation of --instance and --backend options in
 ipa-restore

https://fedorahosted.org/freeipa/ticket/4744
---
 ipaplatform/base/paths.py|  2 +-
 ipaserver/install/ipa_backup.py  |  2 +-
 ipaserver/install/ipa_restore.py | 73 
 3 files changed, 46 insertions(+), 31 deletions(-)

diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index c4cdc58..3389042 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -262,7 +262,7 @@ class BasePathNamespace(object):
 VAR_LIB_DIRSRV_INSTANCE_SCRIPTS_TEMPLATE = "/var/lib/dirsrv/scripts-%s"
 VAR_LIB_SLAPD_INSTANCE_DIR_TEMPLATE = "/var/lib/dirsrv/slapd-%s"
 SLAPD_INSTANCE_BACKUP_DIR_TEMPLATE = "/var/lib/dirsrv/slapd-%s/bak/%s"
-IPACA_DIRSRV_INSTANCE_DB_TEMPLATE = "/var/lib/dirsrv/slapd-%s/db/ipaca"
+SLAPD_INSTANCE_DB_DIR_TEMPLATE = "/var/lib/dirsrv/slapd-%s/db/%s"
 SLAPD_INSTANCE_LDIF_DIR_TEMPLATE = "/var/lib/dirsrv/slapd-%s/ldif"
 VAR_LIB_SLAPD_PKI_IPA_DIR_TEMPLATE = "/var/lib/dirsrv/slapd-PKI-IPA"
 VAR_LIB_IPA = "/var/lib/ipa"
diff --git a/ipaserver/install/ipa_backup.py b/ipaserver/install/ipa_backup.py
index 5d583f7..72d1475 100644
--- a/ipaserver/install/ipa_backup.py
+++ b/ipaserver/install/ipa_backup.py
@@ -292,7 +292,7 @@ class Backup(admintool.AdminTool):
 
 for instance in [realm_to_serverid(api.env.realm), 'PKI-IPA']:
 if os.path.exists(paths.VAR_LIB_SLAPD_INSTANCE_DIR_TEMPLATE % instance):
-if os.path.exists(paths.IPACA_DIRSRV_INSTANCE_DB_TEMPLATE % instance):
+if os.path.exists(paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE % (instance, 'ipaca')):
 self.db2ldif(instance, 'ipaca', online=options.online)
 self.db2ldif(instance, 'userRoot', online=options.online)
 self.db2bak(instance, online=options.online)
diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py
index 9cb978a..0977039 100644
--- a/ipaserver/install/ipa_restore.py
+++ b/ipaserver/install/ipa_restore.py
@@ -188,15 +188,35 @@ class Restore(admintool.AdminTool):
 self.log.info("Preparing restore from %s on %s",
 self.backup_dir, api.env.host)
 
-if not options.instance:
-instances = []
-for instance in [realm_to_serverid(api.env.realm), 'PKI-IPA']:
-if os.path.exists(paths.VAR_LIB_SLAPD_INSTANCE_DIR_TEMPLATE % instance):
-instances.append(instance)
+if options.instance and options.backend:
+database = (options.instance, options.backend)
+if not os.path.exists(paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE %
+  database):
+raise admintool.ScriptError(
+"Instance %s with backend %s does not exist" % database)
+
+databases = [database]
 else:
-instances = [options.instance]
-if options.data_only and not instances:
-raise admintool.ScriptError('No instances to restore to')
+if options.instance:
+instances = [options.instance]
+else:
+instances = [realm_to_serverid(api.env.realm), 'PKI-IPA']
+
+if options.backend:
+backends = [options.backend]
+else:
+backends = ['userRoot', 'ipaca']
+
+databases = []
+for instance in instances:
+for backend in backends:
+database = (instance, backend)
+if os.path.exists(paths.SLAPD_INSTANCE_DB_DIR_TEMPLATE %
+  database):
+databases.append(database)
+
+if options.data_only and not databases:
+raise admintool.ScriptError('No instances to restore to')
 
 create_ds_user()
 pent = pwd.getpwnam(DS_USER)
@@ -223,7 +243,7 @@ class Restore(admintool.AdminTool):
 # These two checks would normally be in the validate method but
 # we need to know the type of backup we're dealing with.
 if (self.backup_type != 'FULL' and not options.data_only and
-not instances):
+not databases):
 raise admintool.ScriptError('Cannot restore a data backup into an empty system')
 if (self.backup_type == 'FULL' and not options.data_only and
 (options.instance or options.backend)):
@@ -244,6 +264,15 @@ class Restore(admintool.AdminTool):
 not user_input("Continue to restore?", False)):
 raise admintool.ScriptError("Aborted")

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

2014-12-01 Thread Martin Kosek

On 11/30/2014 03:28 AM, Gabe Alford wrote:
> Ignore the last patch. Updated patch attached.
> 
> On Sat, Nov 29, 2014 at 6:03 PM, Gabe Alford  wrote:
> 
>> This patch removes the app_PYTHON usage.
>>
>> Thanks,
>>
>> Gabe
>>
>> On Thu, Nov 27, 2014 at 9:40 AM, Martin Kosek  wrote:
>>
>>> Exactly, this was the message from Martin :-) I did not test it myself,
>>> but
>>> removing all app_PYTHON should be benign given we use Python setup.py
>>> packaging.
>>>
>>> On 11/27/2014 04:27 PM, Gabe Alford wrote:
 Thanks guys. Sounds like it would be better to submit a patch that
>>> removes
 app_PYTHON if it is considered dead code.

 Gabe

 On Thursday, November 27, 2014, Petr Spacek  wrote:

> On 27.11.2014 11:00, Martin Basti wrote:
>> On 27/11/14 00:50, Gabe Alford wrote:
>>> Hello,
>>>
>>>Wondering if I could get a review. Updated patch attached.
>>>
>>> Thanks,
>>> Gabe
>>>
>>> On Tue, Nov 11, 2014 at 7:21 AM, Gabe Alford  
>>> > wrote:
>>>
>>> Hello,
>>>
>>> Fix for https://fedorahosted.org/freeipa/ticket/4700
>>>
>>> Thanks,
>>>
>>> Gabe
>>>
>>>
>>>
>> Hello,
>>
>> sorry for late response.
>>
>> We push this ticket to backlog, as it would be part of build system
> refactoring.
>> The "app_PYTHON" statement is not used anymore in IPA, the better
> solution is
>> remove it, instead of keeping dead code up-to-date.
>
> Just to clarify:
> It can be pushed if it works, there is no need to postpone accepting
>>> patch
> if
> the patch seems okay and doesn't break anything.
>
> Martin, please keep in mind that contributions are welcome at any time.
>
> Milestones in Trac reflect our view of priorities but it doesn't
>>> prevent us
> from accepting correct patches from contributions at any time, no
>>> matter
> which
> priority is stated in Trac (or even if there is no ticket for it ...).
>
> --
> Petr^2 Spacek

Worked in my tests, I did not see any breakage. I guess we can also remove the
ipa-client/ipaclient/Makefile.am while we are at it.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration

2014-12-01 Thread David Kupka


On 11/30/2014 02:03 AM, Gabe Alford wrote:

Hello,

Fix for https://fedorahosted.org/freeipa/ticket/4583

Thanks,

Gabe



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Hello!

Thanks for patch. I guess that you wanted to add the "iburst" option 
only once. Right now it will generate lines like:


server  iburst iburst

Attaching the fixed patch. Are you satisfied with it?

--
David Kupka
From f571e379b3e7498e5f32092d633bd6219b1b9c5c Mon Sep 17 00:00:00 2001
From: Gabe 
Date: Sat, 29 Nov 2014 17:53:03 -0700
Subject: [PATCH] Update default NTP configuration

- Add in missing 4th default ntp server
- Add iburst to configuration

https://fedorahosted.org/freeipa/ticket/4583
---
 ipaserver/install/ntpinstance.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ipaserver/install/ntpinstance.py b/ipaserver/install/ntpinstance.py
index c653525d3abf43bef8847f55ef9e22108123c721..f2edf9bc18ec5408d7c17a7f1d90235c1ac164a5 100644
--- a/ipaserver/install/ntpinstance.py
+++ b/ipaserver/install/ntpinstance.py
@@ -51,6 +51,7 @@ class NTPInstance(service.Service):
 srv_vals.append("0.%s.pool.ntp.org" % os)
 srv_vals.append("1.%s.pool.ntp.org" % os)
 srv_vals.append("2.%s.pool.ntp.org" % os)
+srv_vals.append("3.%s.pool.ntp.org" % os)
 srv_vals.append("127.127.1.0")
 fudge = ["fudge", "127.127.1.0", "stratum", "10"]
 
@@ -92,7 +93,7 @@ class NTPInstance(service.Service):
 fd.write("\n### Added by IPA Installer ###\n")
 if len(srv_vals) != 0:
 for srv in srv_vals:
-fd.write("server "+srv+"\n")
+fd.write("server "+srv+" iburst\n")
 if not fudge_present:
 fd.write("fudge 127.127.1.0 stratum 10\n")
 fd.close()
-- 
2.1.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds

2014-12-01 Thread Jan Cholasta


Hi,

Dne 27.11.2014 v 14:20 Martin Basti napsal(a):

Ticket: https://fedorahosted.org/freeipa/ticket/4771
Patch attached.


I would prefer if you did something like this instead:

 1) Add validate_idn_normalized function with the normalized IDN check 
to ipapython.dnsutil, have it raise ValueError if the check fails. (Also 
please get rid of the map() call for better readability.)


 2) Use validate_idn_normalized in DNSNameParam.

 3) Do the following in validate_zonemgr_str:

validate_idn_normalized(zonemgr)
try:
zonemgr = DNSName(zonemgr)
except dns.exception.DNSException as e:
raise ValueError(e)

Honza

--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods

Re: [Freeipa-devel] [PATCH 0074] Make token window sizes configurable

Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration

Re: [Freeipa-devel] FreeIPA integration with external DNS services

Re: [Freeipa-devel] FreeIPA integration with external DNS services

Re: [Freeipa-devel] [PATCH 0168] Better workaround to get status of CA during upgrade

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

Re: [Freeipa-devel] FreeIPA integration with external DNS services

Re: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration

Re: [Freeipa-devel] [PATCH 0170] Detect and warn about invalid forwardzone configuration

Re: [Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods

[Freeipa-devel] Threat model & abuse cases in design documents

[Freeipa-devel] [PATCH] 792 add --hosts option to allow/retrieve keytab methods

Re: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds

[Freeipa-devel] [PATCH] 380 Improve validation of --instance and --backend options in ipa-restore

Re: [Freeipa-devel] [PATCH 0036] Add missing python files to Makefile

Re: [Freeipa-devel] [PATCH 0038] Update default NTP Configuration

Re: [Freeipa-devel] [PATCH 0173] Throw zonemgr error message before installation proceeds

20 matches

Site Navigation

Mail list logo

Footer information