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

2014-12-12 Thread Jan Cholasta

Hi,

Dne 1.12.2014 v 17:12 Simo Sorce napsal(a):

On Mon, 01 Dec 2014 16:17:54 +0100
Petr Spacek pspa...@redhat.com wrote:


On 14.11.2014 17:31, Petr Spacek wrote:

On 14.11.2014 02:22, Simo Sorce wrote:

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 ipa dnsrecord-add etc... commands are called, the
framework detects that the zone is external, fewttches the TSIG
key (if the user has access to it) and spawn an nsupdate command
that will perform the update against whatever DNS server is
authoritative for the zone.



Would it be feasible to use FreeIPA server as XML-RPC-DNS proxy
instead of nsupdate command (to hide TSIG key behind FreeIPA)?



I do not like the XML-RPC-DNS approach as it requires a special
client, leaving out the majority of clients.


I'm confused. Above you have suggested hiding the nsupdate machinery 
behind the framework and now you are saying that you do not like the 
XML-RPC-DNS approach. But the framework talks XML-RPC (and JSON-RPC) 
and using *anything else* would require a special client. Or did you 
mean some other XML-RPC-DNS?




Also, I am thinking that we only _need_ to set infrastructure relevant
names (like IPA servers SRV records), but if someone decides not to use
IPA for the DNS we may decide that it is not our responsibility to
provide a full end-to-end client dns update solution.

So I would concentrate on making it possible for IPA *Servers* to use a
private TSIG key to update infrastructure relevant names, and possibly
defer the clients side of the problem.

We could use an internal bus on the server to allow the ipa framework
to use nsupdate w/o gaining direct access to the TSIG key, this way
admins can use ipa dnsrecod-add and friends w/o exposing the key.


+1, we had a short discussion about external DNS with Petr yesterday and 
reached the same conclusion.


Honza

--
Jan Cholasta

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


[Freeipa-devel] IPA ldap-updater improvements

2014-12-12 Thread Martin Basti

Hello,

I would like to discuss following list of *ldap-updater characteristics*:
1.  Updates sorting are based on length of DN, update with shorter DN is 
executed earlier

2.  DNs of update entries are stored in dictionary
3.  update files are parsed in batches 10-19, 20-29, ..., 80-89
*
**Issues**:*
1. This approach solves parent-children dependency issues, but currently 
we have dependencies between different branches of tree, required by 
plugins, it happens several times for me that shorter DN depends on 
longer DN, and DS rejects update.


2. This disallow to specify order of upgrades per file,  for example, 
update entries A and B have the same length of DN, but B depends on A. 
However python internally (may) change order in dict which causes The B 
update is executed first and update failed. Solution now is move B to 
the file in next update batch.  The ticket 
https://fedorahosted.org/freeipa/ticket/4680 hits this problem.



3. This granularity seems to be not enough to me,  it causes the more 
updates are mixed by applying 1. and 2. for more update entries.


*Solutions:*
1. Don't sort DN, developer should be responsible for order of updates.
2. Use ordered dictionary, developer should be responsible for order of 
updates per file.

3. Parse files in batches per number, 10, 11, 12, ..., 89

*Summary:*
IMO the ipa ldap-updater does to much magic with updates, would be 
better if the updater delegates those responsibilities to developers. 
With current state we would hit the issues above more frequently as the 
we increase the amount of updates in each release.


As first I suggest to fix 3., which is quite easy and it will decrease 
effects of 1. and 2., and allows to use better granularity with upgrades.



Martin^2

--
Martin Basti

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

Re: [Freeipa-devel] IPA ldap-updater improvements

2014-12-12 Thread Martin Kosek

On 12/12/2014 10:38 AM, Martin Basti wrote:

Hello,

I would like to discuss following list of *ldap-updater characteristics*:
1.  Updates sorting are based on length of DN, update with shorter DN is
executed earlier
2.  DNs of update entries are stored in dictionary
3.  update files are parsed in batches 10-19, 20-29, ..., 80-89
*
**Issues**:*
1. This approach solves parent-children dependency issues, but currently we
have dependencies between different branches of tree, required by plugins, it
happens several times for me that shorter DN depends on longer DN, and DS
rejects update.

2. This disallow to specify order of upgrades per file,  for example, update
entries A and B have the same length of DN, but B depends on A. However python
internally (may) change order in dict which causes The B update is executed
first and update failed. Solution now is move B to the file in next update
batch.  The ticket https://fedorahosted.org/freeipa/ticket/4680 hits this 
problem.


3. This granularity seems to be not enough to me,  it causes the more updates
are mixed by applying 1. and 2. for more update entries.

*Solutions:*
1. Don't sort DN, developer should be responsible for order of updates.
2. Use ordered dictionary, developer should be responsible for order of updates
per file.
3. Parse files in batches per number, 10, 11, 12, ..., 89

*Summary:*
IMO the ipa ldap-updater does to much magic with updates, would be better if
the updater delegates those responsibilities to developers. With current state
we would hit the issues above more frequently as the we increase the amount of
updates in each release.

As first I suggest to fix 3., which is quite easy and it will decrease effects
of 1. and 2., and allows to use better granularity with upgrades.


Makes sense to me, better determinism should help us avoid the problems we had 
with 4.1 upgrades. CCing Rob for reference.


___
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-12 Thread Martin Kosek

On 12/11/2014 05:44 PM, Petr Spacek wrote:

On 11.12.2014 16:50, Martin Basti wrote:

Updated aptch attached:


Nice work, ACK!



Can we also add some tests? This is a lot of new code that could break stuff.

___
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-12 Thread Martin Basti

On 12/12/14 13:50, Martin Kosek wrote:

On 12/11/2014 05:44 PM, Petr Spacek wrote:

On 11.12.2014 16:50, Martin Basti wrote:

Updated aptch attached:


Nice work, ACK!



Can we also add some tests? This is a lot of new code that could break 
stuff.


We can, in week maybe or after christmas,  currently I do some work with 
tests and adding new tests required by QE, I will add forwardzone 
warnings  tests when finish this.


--
Martin Basti

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


Re: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply

2014-12-12 Thread Petr Vobornik

On 12/11/2014 03:43 PM, Tomas Babej wrote:


On 12/11/2014 11:07 AM, Jan Cholasta wrote:

Hi,

Dne 11.12.2014 v 09:23 Tomas Babej napsal(a):

Hi,

When running a idview-apply command, the hosts that were already
assigned
the desired view were silently ignored. Make sure such hosts show up in
the list of failed hosts.

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


Shouldn't the error message strings be translatable?



Sure, why not. Good point, I transformed the other error message string
as well.

Updated patch attach.


Honza



Got JSON serialization issues for both ID View already applied and 
not found errors.


Traceback (most recent call last):
  File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 
402, in __call__

response = self.wsgi_execute(environ)
  File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 
387, in wsgi_execute

return self.marshal(result, error, _id, version)
  File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line 
467, in marshal

return json.dumps(response, sort_keys=True, indent=4)
  File /usr/lib64/python2.7/json/__init__.py, line 250, in dumps
sort_keys=sort_keys, **kw).encode(obj)
  File /usr/lib64/python2.7/json/encoder.py, line 209, in encode
chunks = list(chunks)
  File /usr/lib64/python2.7/json/encoder.py, line 434, in _iterencode
for chunk in _iterencode_dict(o, _current_indent_level):
  File /usr/lib64/python2.7/json/encoder.py, line 408, in 
_iterencode_dict

for chunk in chunks:
  File /usr/lib64/python2.7/json/encoder.py, line 408, in 
_iterencode_dict

for chunk in chunks:
  File /usr/lib64/python2.7/json/encoder.py, line 408, in 
_iterencode_dict

for chunk in chunks:
  File /usr/lib64/python2.7/json/encoder.py, line 408, in 
_iterencode_dict

for chunk in chunks:
  File /usr/lib64/python2.7/json/encoder.py, line 332, in 
_iterencode_list

for chunk in chunks:
  File /usr/lib64/python2.7/json/encoder.py, line 332, in 
_iterencode_list

for chunk in chunks:
  File /usr/lib64/python2.7/json/encoder.py, line 442, in _iterencode
o = _default(o)
  File /usr/lib64/python2.7/json/encoder.py, line 184, in default
raise TypeError(repr(o) +  is not JSON serializable)
TypeError: Gettext('ID View already applied', domain='ipa', 
localedir=None) is not JSON serializable

--
Petr Vobornik

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


[Freeipa-devel] [PATCH 0179] Fix traceback if zonemgr error message contains unicode characters

2014-12-12 Thread Martin Basti

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

Patch attached.

--
Martin Basti

From a890b3171e1ee6873899266382412fbf36d4ba97 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 12 Dec 2014 14:23:32 +0100
Subject: [PATCH] Fix traceback if zonemgr error contains unicode

Ticket: https://fedorahosted.org/freeipa/ticket/4805
---
 ipaserver/install/bindinstance.py | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py
index 547cf19ee36140b5f29fcf7d217933fa68e1952b..4e630e8ddfed524d021d19016f48615fc8c0ab9d 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -411,7 +411,14 @@ def zonemgr_callback(option, opt_str, value, parser):
 value = value.decode(encoding)
 validate_zonemgr_str(value)
 except ValueError, e:
-parser.error(invalid zonemgr:  + unicode(e))
+# FIXME we can do this in better way
+# https://fedorahosted.org/freeipa/ticket/4804
+# decode to proper stderr encoding
+stderr_encoding = getattr(sys.stderr, 'encoding', None)
+if stderr_encoding is None:
+stderr_encoding = 'utf-8'
+error = unicode(e).encode(stderr_encoding)
+parser.error(invalid zonemgr:  + error)
 
 parser.values.zonemgr = value
 
-- 
1.8.3.1

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

Re: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply

2014-12-12 Thread Tomas Babej

On 12/12/2014 02:19 PM, Petr Vobornik wrote:
 On 12/11/2014 03:43 PM, Tomas Babej wrote:

 On 12/11/2014 11:07 AM, Jan Cholasta wrote:
 Hi,

 Dne 11.12.2014 v 09:23 Tomas Babej napsal(a):
 Hi,

 When running a idview-apply command, the hosts that were already
 assigned
 the desired view were silently ignored. Make sure such hosts show
 up in
 the list of failed hosts.

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

 Shouldn't the error message strings be translatable?


 Sure, why not. Good point, I transformed the other error message string
 as well.

 Updated patch attach.

 Honza


 Got JSON serialization issues for both ID View already applied and
 not found errors.

 Traceback (most recent call last):
   File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line
 402, in __call__
 response = self.wsgi_execute(environ)
   File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line
 387, in wsgi_execute
 return self.marshal(result, error, _id, version)
   File /usr/lib/python2.7/site-packages/ipaserver/rpcserver.py, line
 467, in marshal
 return json.dumps(response, sort_keys=True, indent=4)
   File /usr/lib64/python2.7/json/__init__.py, line 250, in dumps
 sort_keys=sort_keys, **kw).encode(obj)
   File /usr/lib64/python2.7/json/encoder.py, line 209, in encode
 chunks = list(chunks)
   File /usr/lib64/python2.7/json/encoder.py, line 434, in _iterencode
 for chunk in _iterencode_dict(o, _current_indent_level):
   File /usr/lib64/python2.7/json/encoder.py, line 408, in
 _iterencode_dict
 for chunk in chunks:
   File /usr/lib64/python2.7/json/encoder.py, line 408, in
 _iterencode_dict
 for chunk in chunks:
   File /usr/lib64/python2.7/json/encoder.py, line 408, in
 _iterencode_dict
 for chunk in chunks:
   File /usr/lib64/python2.7/json/encoder.py, line 408, in
 _iterencode_dict
 for chunk in chunks:
   File /usr/lib64/python2.7/json/encoder.py, line 332, in
 _iterencode_list
 for chunk in chunks:
   File /usr/lib64/python2.7/json/encoder.py, line 332, in
 _iterencode_list
 for chunk in chunks:
   File /usr/lib64/python2.7/json/encoder.py, line 442, in _iterencode
 o = _default(o)
   File /usr/lib64/python2.7/json/encoder.py, line 184, in default
 raise TypeError(repr(o) +  is not JSON serializable)
 TypeError: Gettext('ID View already applied', domain='ipa',
 localedir=None) is not JSON serializable

Thanks, fixed. Updated patch attached.

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

From 0a2232e031461c294760e1377de45d7d3273f581 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 11 Dec 2014 07:50:40 +0100
Subject: [PATCH] idviews: Complain if host is already assigned the ID View in
 idview-apply

When running a idview-apply command, the hosts that were already assigned
the desired view were silently ignored. Make sure such hosts show up in
the list of failed hosts.

https://fedorahosted.org/freeipa/ticket/4743
---
 ipalib/plugins/idviews.py | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index 9c8721018325f56e681f168b55c31055bfd07345..c9c1bd848750e7c7e1c472df179368ac2b9d29ce 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -260,7 +260,7 @@ class baseidview_apply(LDAPQuery):
 try:
 hosts_to_apply += get_complete_hostgroup_member_list(hostgroup)
 except errors.NotFound:
-failed['hostgroup'].append((hostgroup, not found))
+failed['hostgroup'].append((hostgroup, unicode(_(not found
 except errors.PublicError as e:
 failed['hostgroup'].append((hostgroup, %s : %s % (
 e.__class__.__name__, str(e
@@ -279,10 +279,11 @@ class baseidview_apply(LDAPQuery):
 completed = completed + 1
 succeeded['host'].append(host)
 except errors.EmptyModlist:
-# If view was already applied, do not complain
-pass
+# If view was already applied, complain about it
+failed['host'].append((host,
+   unicode(_(ID View already applied
 except errors.NotFound:
-failed['host'].append((host, not found))
+failed['host'].append((host, unicode(_(not found
 except errors.PublicError as e:
 failed['host'].append((host, str(e)))
 
-- 
1.9.3

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

Re: [Freeipa-devel] [PATCH 0291] idviews: Complain if host is already assigned the ID View in idview-apply

2014-12-12 Thread Petr Vobornik

On 12/12/2014 04:15 PM, Tomas Babej wrote:


Thanks, fixed. Updated patch attached.



ACK

Pushed to:
master: fdd7b79eeafae3891a9aa5bf414f9c65f947e88d
ipa-4-1: 12f6969ec9daafe7926a49a6775501d1034694f4
--
Petr Vobornik

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


[Freeipa-devel] [PATCH 0292] idviews: Ignore host or hostgroup options set to None

2014-12-12 Thread Tomas Babej
Hi,

Since passing --hosts= or --hostsgroups= to idview-apply or unapply
commands does not make sense, ignore it.

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

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 


From 02e8d68c644f451c3712861b9b85f2d80811fea4 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Fri, 12 Dec 2014 16:47:49 +0100
Subject: [PATCH] idviews: Ignore host or hostgroup options set to None

Since passing --hosts= or --hostsgroups= to idview-apply or unapply
commands does not make sense, ignore it.

https://fedorahosted.org/freeipa/ticket/4806
---
 ipalib/plugins/idviews.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index c9c1bd848750e7c7e1c472df179368ac2b9d29ce..df6b80fee6239c97e2133885234408c2816b3774 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -253,6 +253,12 @@ class baseidview_apply(LDAPQuery):
 'hostgroup': [],
 }
 
+# Make sure we ignore None passed via host or hostgroup, since it does
+# not make sense
+for key in ('host', 'hostgroup'):
+if key in options and options[key] is None:
+del options[key]
+
 # Generate a list of all hosts to apply the view to
 hosts_to_apply = list(options.get('host', []))
 
-- 
1.9.3

___
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-12 Thread Simo Sorce
On Fri, 12 Dec 2014 10:20:28 +0100
Jan Cholasta jchol...@redhat.com wrote:

 Hi,
 
 Dne 1.12.2014 v 17:12 Simo Sorce napsal(a):
  On Mon, 01 Dec 2014 16:17:54 +0100
  Petr Spacek pspa...@redhat.com wrote:
 
  On 14.11.2014 17:31, Petr Spacek wrote:
  On 14.11.2014 02:22, Simo Sorce wrote:
  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 ipa dnsrecord-add etc... commands are called,
  the framework detects that the zone is external, fewttches the
  TSIG key (if the user has access to it) and spawn an nsupdate
  command that will perform the update against whatever DNS server
  is authoritative for the zone.
 
  Would it be feasible to use FreeIPA server as XML-RPC-DNS proxy
  instead of nsupdate command (to hide TSIG key behind FreeIPA)?
 
  I do not like the XML-RPC-DNS approach as it requires a special
  client, leaving out the majority of clients.
 
 I'm confused. Above you have suggested hiding the nsupdate machinery 
 behind the framework and now you are saying that you do not like the 
 XML-RPC-DNS approach. But the framework talks XML-RPC (and JSON-RPC) 
 and using *anything else* would require a special client. Or did you 
 mean some other XML-RPC-DNS?

I do not like XML-RPC - DNS for when clients need to update the DNS.
For the FreeIPA server itself or the manager working through the
framework it is just fine of course, but then it is an internal detail.


  Also, I am thinking that we only _need_ to set infrastructure
  relevant names (like IPA servers SRV records), but if someone
  decides not to use IPA for the DNS we may decide that it is not our
  responsibility to provide a full end-to-end client dns update
  solution.
 
  So I would concentrate on making it possible for IPA *Servers* to
  use a private TSIG key to update infrastructure relevant names, and
  possibly defer the clients side of the problem.
 
  We could use an internal bus on the server to allow the ipa
  framework to use nsupdate w/o gaining direct access to the TSIG
  key, this way admins can use ipa dnsrecod-add and friends w/o
  exposing the key.
 
 +1, we had a short discussion about external DNS with Petr yesterday
 and reached the same conclusion.

Nice :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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


Re: [Freeipa-devel] [PATCH 0292] idviews: Ignore host or hostgroup options set to None

2014-12-12 Thread Petr Vobornik

On 12/12/2014 04:49 PM, Tomas Babej wrote:

Hi,

Since passing --hosts= or --hostsgroups= to idview-apply or unapply
commands does not make sense, ignore it.

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



ACK
--
Petr Vobornik

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


Re: [Freeipa-devel] [PATCH 0292] idviews: Ignore host or hostgroup options set to None

2014-12-12 Thread Tomas Babej

On 12/12/2014 05:02 PM, Petr Vobornik wrote:
 On 12/12/2014 04:49 PM, Tomas Babej wrote:
 Hi,

 Since passing --hosts= or --hostsgroups= to idview-apply or unapply
 commands does not make sense, ignore it.

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


 ACK

Pushed to:
master: c5c9d49706d27455c7f7bdb811108d45deb82bf4
ipa-4-1: 86a7dfccd522b16dc3deadb9837a409b65aa1aeb

-- 
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

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


Re: [Freeipa-devel] Features for F22

2014-12-12 Thread Adam Young

On 12/12/2014 07:33 AM, Joe Brockmeier wrote:

On 12/12/2014 03:15 AM, Kushal Das wrote:

It is time again to start discussion on the new features we want to
work for Fedora 22 release. The release schedule can be found at [1].

Please reply to this thread with the ideas you think will fit to
Fedora 22 timeline.

Some things to think about in the F22 timeline:

- Rocket packages (already in progress, I believe)
- Flannel
- Additional Docker packages launched at Dockercon?
- Overlay packages for rpm-ostree
- Package testCloud: https://github.com/Rorosha/testCloud
- Reduce Atomic, cloud base, and Docker image sizes
- Bare metal installer for Atomic

Crossposting:

Cloud Init support for auto registering a VM with FreeIPA.





Those are the ideas off the top of my head we've talked about and should
have for F22. I'm sure there's more.

Best,

jzb


___
cloud mailing list
cl...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


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