Re: [Freeipa-devel] [PATCH] 0208-0209 webUI changes for external trust and UPN suffixes

2016-06-10 Thread Alexander Bokovoy

On Fri, 10 Jun 2016, Pavel Vomacka wrote:



On 06/09/2016 02:19 PM, Alexander Bokovoy wrote:

On Thu, 09 Jun 2016, Sumit Bose wrote:

On Thu, Jun 09, 2016 at 02:30:52PM +0300, Alexander Bokovoy wrote:

Hi,

webUI changes to support external trust and showing UPN suffixes are
attached.

UPN Suffixes defined on AD side and fetched with 'ipa 
trust-fetch-domains'.

They cannot be disabled individually as they come from AD side and are
forest-wide, so we only show them, not allowing to modify anything.

External forest is a flag and is shown in the trust-add dialog.
The result would be visible as trust type of 'Non-transitive external
trust to a domain in another Active Directory forest'

These patches functionally depend on 0201 and 0202.

--
/ Alexander Bokovoy



From 4da33f5e82c83617ccfb2da7c3b70e5e66ac49d9 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 9 Jun 2016 12:04:05 +0300
Subject: [PATCH 7/8] webui: show UPN suffixes in trust properties

Part of https://fedorahosted.org/freeipa/ticket/5354

---
install/ui/src/freeipa/trust.js | 11 +++
ipaserver/plugins/internal.py   |  2 ++
2 files changed, 13 insertions(+)


...
diff --git a/ipaserver/plugins/internal.py 
b/ipaserver/plugins/internal.py

index 4804f64..ea29b16 100644
--- a/ipaserver/plugins/internal.py
+++ b/ipaserver/plugins/internal.py
@@ -747,6 +747,8 @@ class i18n_messages(Command):
"trustdirection": _("Trust direction"),
"truststatus": _("Trust status"),
"trusttype": _("Trust type"),
+"suffixes": _("UPN suffixes"),
+"ipantadditionalsuffixes": _("UPN suffixes"),


The AD gui calls the latter 'Alternative UPN suffixes'. Maybe we should
use the same description here as well to avoid irritations?

Makes sense. I've updated the patch 0208 and also removed the string
'suffixes' which is not referenced from the UI.



Hello,

thank you for patches, they look good and work well. I have only one 
small comment:

Patch 208:

+read_only: 'true'

It would be nicer to use boolean value instead of string, even if it 
works correctly with string value.


And because it is really small change I edited your patch. I also 
changed links in your commit messages to WebUI tickets (5904,5937). 
Edited patches are attached, so ACK if you agree with these changes.

Sure, ACK.

Thanks for the review.

--
/ Alexander Bokovoy

--
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] 0208-0209 webUI changes for external trust and UPN suffixes

2016-06-10 Thread Pavel Vomacka



On 06/09/2016 02:19 PM, Alexander Bokovoy wrote:

On Thu, 09 Jun 2016, Sumit Bose wrote:

On Thu, Jun 09, 2016 at 02:30:52PM +0300, Alexander Bokovoy wrote:

Hi,

webUI changes to support external trust and showing UPN suffixes are
attached.

UPN Suffixes defined on AD side and fetched with 'ipa 
trust-fetch-domains'.

They cannot be disabled individually as they come from AD side and are
forest-wide, so we only show them, not allowing to modify anything.

External forest is a flag and is shown in the trust-add dialog.
The result would be visible as trust type of 'Non-transitive external
trust to a domain in another Active Directory forest'

These patches functionally depend on 0201 and 0202.

--
/ Alexander Bokovoy



From 4da33f5e82c83617ccfb2da7c3b70e5e66ac49d9 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 9 Jun 2016 12:04:05 +0300
Subject: [PATCH 7/8] webui: show UPN suffixes in trust properties

Part of https://fedorahosted.org/freeipa/ticket/5354

---
 install/ui/src/freeipa/trust.js | 11 +++
 ipaserver/plugins/internal.py   |  2 ++
 2 files changed, 13 insertions(+)


...
diff --git a/ipaserver/plugins/internal.py 
b/ipaserver/plugins/internal.py

index 4804f64..ea29b16 100644
--- a/ipaserver/plugins/internal.py
+++ b/ipaserver/plugins/internal.py
@@ -747,6 +747,8 @@ class i18n_messages(Command):
 "trustdirection": _("Trust direction"),
 "truststatus": _("Trust status"),
 "trusttype": _("Trust type"),
+"suffixes": _("UPN suffixes"),
+"ipantadditionalsuffixes": _("UPN suffixes"),


The AD gui calls the latter 'Alternative UPN suffixes'. Maybe we should
use the same description here as well to avoid irritations?

Makes sense. I've updated the patch 0208 and also removed the string
'suffixes' which is not referenced from the UI.



Hello,

thank you for patches, they look good and work well. I have only one 
small comment:

Patch 208:

+read_only: 'true'

It would be nicer to use boolean value instead of string, even if it 
works correctly with string value.


And because it is really small change I edited your patch. I also 
changed links in your commit messages to WebUI tickets (5904,5937). 
Edited patches are attached, so ACK if you agree with these changes.


--
Pavel^3 Vomacka
From 647e44943e9aa456ae82c460ed808745c6bef6ba Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 9 Jun 2016 12:04:05 +0300
Subject: [PATCH 1/2] webui: show UPN suffixes in trust properties

https://fedorahosted.org/freeipa/ticket/5937
---
 install/ui/src/freeipa/trust.js | 13 -
 ipaserver/plugins/internal.py   |  1 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/install/ui/src/freeipa/trust.js b/install/ui/src/freeipa/trust.js
index f26e2f21b7c8a97536a0a5cb23484da4173d6463..fde7ff20768921c7425155bf31211f6903f13834 100644
--- a/install/ui/src/freeipa/trust.js
+++ b/install/ui/src/freeipa/trust.js
@@ -142,6 +142,17 @@ return {
 ]
 },
 {
+name: 'suffixes',
+label: '@i18n:objects.trust.ipantadditionalsuffixes',
+fields: [
+{
+$type: 'multivalued',
+name: 'ipantadditionalsuffixes',
+read_only: true
+},
+]
+},
+{
 name: 'blacklists',
 label: '@i18n:objects.trust.blacklists',
 fields: [
@@ -446,4 +457,4 @@ phases.on('registration', IPA.trust.register);
 phases.on('profile', exp.remove_menu_item, 20);
 
 return exp;
-});
\ No newline at end of file
+});
diff --git a/ipaserver/plugins/internal.py b/ipaserver/plugins/internal.py
index 4804f64a0191a8f00f613fbc4d7fd86d7c73775f..c44c260f542428a76ff81c7119efefef4b5da492 100644
--- a/ipaserver/plugins/internal.py
+++ b/ipaserver/plugins/internal.py
@@ -747,6 +747,7 @@ class i18n_messages(Command):
 "trustdirection": _("Trust direction"),
 "truststatus": _("Trust status"),
 "trusttype": _("Trust type"),
+"ipantadditionalsuffixes": _("Alternative UPN suffixes"),
 },
 "trustconfig": {
 "options": _("Options"),
-- 
2.5.5

From c86a13ba790dacfa0e2514f98fdc5f4e89a9e4de Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 9 Jun 2016 12:04:39 +0300
Subject: [PATCH 2/2] webui: support external flag to trust-add

https://fedorahosted.org/freeipa/ticket/5904
---
 install/ui/src/freeipa/trust.js | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/install/ui/src/freeipa/trust.js b/install/ui/src/freeipa/trust.js
index 

Re: [Freeipa-devel] [PATCH] 0003 batch command can be used to trigger internal errors on server

2016-06-10 Thread Stanislav Laznicka

On 06/08/2016 02:06 PM, Florence Blanc-Renaud wrote:

On 06/08/2016 10:07 AM, Petr Spacek wrote:

On 7.6.2016 15:11, Stanislav Laznicka wrote:

Hello,

Thank you for your patch. As the thin-client patches were pushed in the
meantime, the patch won't apply. Could you please send a rebased version?

Also, I have a few comments to the patch:

1) I think that the commit message should be rather a brief conclusion to the
changes made in the commit. This could help for faster orientation in the
changes that were made to a certain part of code should you be searching for a
bug introduced by a commit. Should some more info be required, it can be added
to the ticket. Could you therefore shorten the commit message?

(My personal opinion, no golden standard.)

Honestly I disagree with Standa. Yes, the commit message seems to be a bit
long but *tickets* are not the best place to put *technical* information into.

Tickets are planning tool but keep in mind that Trac may/will vanish one day
and all we will have will be (Git?) repo.

I would recommend putting the comment about expected input format into code
comments somewhere around batch command definition.

This would reduce commit message (roughly, the text needs to be adapted) to
part starting 'The code did not check the format of ' ... which is perfectly
reasonable description of the change.

IMHO.
Petr^2 Spacek



2) Please do not add the tickets to comments in the code. You can use git
blame -L or git log -L to see in which commits were the changes introduced to
a certain part of a file, these commits should include the ticket number if
more info is needed.

Standa


On 05/27/2016 03:53 PM, Florence Blanc-Renaud wrote:

Hi all,

the following patch checks the format of parameters passed to a method
called through the batch command. I picked the ConversionError for invalid
parameters format but this choice can be discussed if you have better
suggestions...

Fixes:https://fedorahosted.org/freeipa/ticket/5810
--
Florence Blanc-Renaud
Identity Management Team, Red Hat






Hi,

please find an updated patch version with a less verbose commit msg. I 
also removed the reference to ticket # in the code.


Flo.



Hello,

Thank you for your updated patch. I have just one small issue that maybe 
exceeds the scope of this ticket. If the check for dictionary instance 
in list:


+if not isinstance(arg, dict):
+raise errors.ConversionError(
+name='methods',
+error=_(u'must contain dict objects'))

fails at a further member of the list, by raising an exception, you will 
lose information about execution of all the previous commands but these 
were already executed. This hasn't seem to be an issue until now so I 
wonder if it is a problem or not.


So far, batch commands have only been utilized in the WebUI so I am 
adding Petr for opinions on how to handle this properly so that WebUI 
could react to it should it ever happen (although AFAIK this should 
never happen for batch commands called from the UI).


Standa
-- 
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 0023] topology plugins sigsev when adding a managed host

2016-06-10 Thread thierry bordaz



On 06/10/2016 05:56 PM, Ludwig Krispenz wrote:


On 06/10/2016 05:41 PM, thierry bordaz wrote:



On 06/10/2016 05:23 PM, Ludwig Krispenz wrote:


On 06/10/2016 04:44 PM, thierry bordaz wrote:

Hi Ludwig,

I agree with you there is no path to add a host with an empty hostname.
You fix looks valid but I would prefer a log in FATAL rather in PLUGIN.

yes, of course that was my intention, copy paste :-)


Also I wonder if a reason of empty hostname could be a 
slapi_ch_free on it but with the host remaining in the list.
Looking at 
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_cfg.c#n852,

I wonder if the two lines 852 and 853 could lead to this situation.
but this frees the complete replica structure tconf and in the 
caller tconf is set to null, so should never be used again.


Yes you are right, it can not conduct to empty hostname into tconf.
However I think it can leak because host will be set to 0 at the end 
of the first iteration.

yes, line 852 and 853 should be switched


An other possibility is that in
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_util.c#n1449|
ipa_topo_util_init_hosts, 'cn' has an empty value. newhost is not 
null but empty, so we may create an empty hostname.

|


|You are definitely right there is no path that can lead to NULL 
hostname :-(


If we are unable to get a reproducible test case,
A crazy idea would be to do some internal rotating logging in a buffer 
on each events (add/del host, add/del segments...),
when the incoherency is detected, then dump the buffer into the error 
logs so that we would have more data to find the RC.



|

||


thanks
thierry


On 06/10/2016 12:36 PM, Ludwig Krispenz wrote:

Hi,
the attached patch will prevent the crash reported in ticket #5928.

So far I do not understand how this situation can occur, there is 
no reproducer yet. I do not really like this fix as it hides a 
probable corrupted data structure and would prefer to find the 
root cause.


But please review it, so we can commit it if there is no progress 
on the root cause.


Ludwig







--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander




--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [Testplan review] Sub CAs

2016-06-10 Thread Milan Kubík

Hi Fraser and list,

I've wrote a (minimal) draft [1] of the test plan for the Sub CAs feature
and I also have several questions.

Could you please take a look at it?

Questions:

As described in the last (currently) test case, should it be possible to 
specify

both the CA and certificate profile in cert-request call?
This way one could use (at least) two ACLs (one affiliated with CA, one 
with a profile).

Are there such use cases?

Related to this, what happens when CA ACL has specific CA and profile 
category (all)?

Applicable to other combinations as well. The ACL category semantics is
a bit unclear for me here.

Is there any validation of the CA's DN (syntax)?

How would you approach testing of the Sub CA certificate renewal and key 
replication
(I do not know if this is covered at the respective component's level or 
not)?



[1]: http://www.freeipa.org/page/V4/Sub-CAs/Test_Plan

Thanks

--
Milan Kubik

--
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 0023] topology plugins sigsev when adding a managed host

2016-06-10 Thread Ludwig Krispenz


On 06/10/2016 05:41 PM, thierry bordaz wrote:



On 06/10/2016 05:23 PM, Ludwig Krispenz wrote:


On 06/10/2016 04:44 PM, thierry bordaz wrote:

Hi Ludwig,

I agree with you there is no path to add a host with an empty hostname.
You fix looks valid but I would prefer a log in FATAL rather in PLUGIN.

yes, of course that was my intention, copy paste :-)


Also I wonder if a reason of empty hostname could be a slapi_ch_free 
on it but with the host remaining in the list.
Looking at 
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_cfg.c#n852,

I wonder if the two lines 852 and 853 could lead to this situation.
but this frees the complete replica structure tconf and in the caller 
tconf is set to null, so should never be used again.


Yes you are right, it can not conduct to empty hostname into tconf.
However I think it can leak because host will be set to 0 at the end 
of the first iteration.

yes, line 852 and 853 should be switched


An other possibility is that in
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_util.c#n1449|
ipa_topo_util_init_hosts, 'cn' has an empty value. newhost is not null 
but empty, so we may create an empty hostname.

|


thanks
thierry


On 06/10/2016 12:36 PM, Ludwig Krispenz wrote:

Hi,
the attached patch will prevent the crash reported in ticket #5928.

So far I do not understand how this situation can occur, there is 
no reproducer yet. I do not really like this fix as it hides a 
probable corrupted data structure and would prefer to find the root 
cause.


But please review it, so we can commit it if there is no progress 
on the root cause.


Ludwig







--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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 0023] topology plugins sigsev when adding a managed host

2016-06-10 Thread Ludwig Krispenz


On 06/10/2016 05:41 PM, thierry bordaz wrote:



On 06/10/2016 05:23 PM, Ludwig Krispenz wrote:


On 06/10/2016 04:44 PM, thierry bordaz wrote:

Hi Ludwig,

I agree with you there is no path to add a host with an empty hostname.
You fix looks valid but I would prefer a log in FATAL rather in PLUGIN.

yes, of course that was my intention, copy paste :-)


Also I wonder if a reason of empty hostname could be a slapi_ch_free 
on it but with the host remaining in the list.
Looking at 
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_cfg.c#n852,

I wonder if the two lines 852 and 853 could lead to this situation.
but this frees the complete replica structure tconf and in the caller 
tconf is set to null, so should never be used again.


Yes you are right, it can not conduct to empty hostname into tconf.
However I think it can leak because host will be set to 0 at the end 
of the first iteration.


An other possibility is that in
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_util.c#n1449|
ipa_topo_util_init_hosts, 'cn' has an empty value. newhost is not null 
but empty, so we may create an empty hostname.

|


|newhost=  slapi_entry_attr_get_charptr(hostentry,"cn");
if  (newhost==  NULL)  return;

if there is no cn, it will not be added, if the cn is an empty value, the 
pointer is not NULL and it will not crash when dereferncing
|




||


thanks
thierry


On 06/10/2016 12:36 PM, Ludwig Krispenz wrote:

Hi,
the attached patch will prevent the crash reported in ticket #5928.

So far I do not understand how this situation can occur, there is 
no reproducer yet. I do not really like this fix as it hides a 
probable corrupted data structure and would prefer to find the root 
cause.


But please review it, so we can commit it if there is no progress 
on the root cause.


Ludwig







--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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] [PATCHES 0146-0152] Server Roles v2

2016-06-10 Thread Martin Babinsky

On 06/10/2016 02:22 PM, Jan Cholasta wrote:

On 9.6.2016 17:06, Martin Babinsky wrote:

On 06/09/2016 03:54 PM, Petr Vobornik wrote:

On 06/09/2016 01:02 PM, Martin Babinsky wrote:

On 06/07/2016 07:01 PM, Pavel Vomacka wrote:



On 06/07/2016 12:07 PM, Martin Babinsky wrote:

On 06/03/2016 05:25 PM, Martin Babinsky wrote:

I am sending rebased patches implementing
http://www.freeipa.org/page/V4/Server_Roles

I hope the patches work since I have had a lot of fun rebasing
them on
top of thin client and DNS locations effort.

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





Sending updated patches according to Jan's interactive review.

Since the name of attributes returned by API commands and
signature of
`server-role-find` have changed, a small update in WebUI patches is
required.




NACK, why did you remove sizelimit from server_role_find command's? Is
it possible to return it back? It breaks WebUI.


Indeed, this was caused by changing the base class of the command.
It is
fixed in updated patches.



NACK

Option timelimit? of command server_role_find in ipalib, not in API
file:
Int('timelimit?', autofill=False)
Option sizelimit? of command server_role_find in ipalib, not in API
file:
Int('sizelimit?', autofill=False)

There are one or more changes to the API.
Either undo the API changes or update API.txt and increment the major
version in VERSION.
Makefile:159: recipe for target 'version-update' failed
make: *** [version-update] Error 1



Oops, seems like a missed API.txt update.

Fixed.


"ipa server-role-find" does not return the "IPA master" role for my
server ("ipa-server-role $HOSTNAME 'IPA master'" does).

This is intentional since we discussed during the design phase[1] that 
"IPA master" role should be implicit and not shown to the user in 
server-show and server-role-find operation. This however does not 
preclude you to query its status manually if you know the role name.


[1] http://www.freeipa.org/page/V4/Server_Roles#Server_Roles


I would rather skip the option altogether rather than hide it:

+# we do not want to test negative membership for roles
+# hide it from CLI
+elif option.name == 'no_servrole':
+option = option.clone(flags={'no_option'})


So something like:

elif option.name == 'no_servrole':
continue

should do the trick?

The patches need a rebase (VERSION).

Otherwise LGTM.



Ok I will send fixed patches ASAP.

--
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 0023] topology plugins sigsev when adding a managed host

2016-06-10 Thread thierry bordaz



On 06/10/2016 05:23 PM, Ludwig Krispenz wrote:


On 06/10/2016 04:44 PM, thierry bordaz wrote:

Hi Ludwig,

I agree with you there is no path to add a host with an empty hostname.
You fix looks valid but I would prefer a log in FATAL rather in PLUGIN.

yes, of course that was my intention, copy paste :-)


Also I wonder if a reason of empty hostname could be a slapi_ch_free 
on it but with the host remaining in the list.
Looking at 
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_cfg.c#n852,

I wonder if the two lines 852 and 853 could lead to this situation.
but this frees the complete replica structure tconf and in the caller 
tconf is set to null, so should never be used again.


Yes you are right, it can not conduct to empty hostname into tconf.
However I think it can leak because host will be set to 0 at the end of 
the first iteration.


An other possibility is that in
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_util.c#n1449|
ipa_topo_util_init_hosts, 'cn' has an empty value. newhost is not null 
but empty, so we may create an empty hostname.

|


thanks
thierry


On 06/10/2016 12:36 PM, Ludwig Krispenz wrote:

Hi,
the attached patch will prevent the crash reported in ticket #5928.

So far I do not understand how this situation can occur, there is no 
reproducer yet. I do not really like this fix as it hides a probable 
corrupted data structure and would prefer to find the root cause.


But please review it, so we can commit it if there is no progress on 
the root cause.


Ludwig







--
Red Hat GmbH,http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander


-- 
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 0023] topology plugins sigsev when adding a managed host

2016-06-10 Thread Ludwig Krispenz


On 06/10/2016 04:44 PM, thierry bordaz wrote:

Hi Ludwig,

I agree with you there is no path to add a host with an empty hostname.
You fix looks valid but I would prefer a log in FATAL rather in PLUGIN.

yes, of course that was my intention, copy paste :-)


Also I wonder if a reason of empty hostname could be a slapi_ch_free 
on it but with the host remaining in the list.
Looking at 
https://git.fedorahosted.org/cgit/freeipa.git/tree/daemons/ipa-slapi-plugins/topology/topology_cfg.c#n852,

I wonder if the two lines 852 and 853 could lead to this situation.
but this frees the complete replica structure tconf and in the caller 
tconf is set to null, so should never be used again.


thanks
thierry


On 06/10/2016 12:36 PM, Ludwig Krispenz wrote:

Hi,
the attached patch will prevent the crash reported in ticket #5928.

So far I do not understand how this situation can occur, there is no 
reproducer yet. I do not really like this fix as it hides a probable 
corrupted data structure and would prefer to find the root cause.


But please review it, so we can commit it if there is no progress on 
the root cause.


Ludwig







--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] Storing directory path in variables

2016-06-10 Thread Florence Blanc-Renaud

Hi,

I am working on a bug linked to a trailing / in a directory name. It 
looks like hardcoded paths for directories sometimes contain the 
trailing / but not always (for instance dsinstance.config_dirname() 
returns something like 
'/etc/dirsrv/slapd-DOM-221-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM*/*' while 
HTTPD_ALIAS_DIR = "/etc/httpd/alias").


So my question is: is there a rule inside FreeIPA to use the directory 
name with the / or not? For most of the tools, it doesn't matter but 
when looking for a cert monitored by certmonger it is important. I think 
that a consistent rule would also avoid ugly logs with double slashes in 
the file names.


Flo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH] 0045-47: webui: Sub-CAs

2016-06-10 Thread Pavel Vomacka

Hello,

please review these new patches which add WebUI for Sub-CAs.

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

--
Pavel^3 Vomacka
From e76324180aa9518a93867fd6c9daa50a8fa79c1f Mon Sep 17 00:00:00 2001
From: Pavel Vomacka 
Date: Fri, 10 Jun 2016 16:12:45 +0200
Subject: [PATCH 1/3] Add new webui plugin - ca

Whole new entity for CAs.

https://fedorahosted.org/freeipa/ticket/5939
---
 install/ui/src/freeipa/app.js  |  1 +
 install/ui/src/freeipa/navigation/menu_spec.js |  5 ++
 install/ui/src/freeipa/plugins/ca.js   | 92 ++
 install/ui/test/data/ipa_init.json |  3 +
 ipaserver/plugins/internal.py  |  3 +
 5 files changed, 104 insertions(+)
 create mode 100644 install/ui/src/freeipa/plugins/ca.js

diff --git a/install/ui/src/freeipa/app.js b/install/ui/src/freeipa/app.js
index daf17b7ba021d3db8288f2de89a8ae4814172a70..4eb045d7a989bdfee29cef670770d285701ae875 100644
--- a/install/ui/src/freeipa/app.js
+++ b/install/ui/src/freeipa/app.js
@@ -29,6 +29,7 @@ define([
 './aci',
 './automember',
 './automount',
+'./plugins/ca',
 './plugins/caacl',
 './plugins/certprofile',
 './dns',
diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js
index 0afc7daceb725cee5677982c68c09d1666d42885..97a03527e94ba2ae21d70e0170b91efc81b155a4 100644
--- a/install/ui/src/freeipa/navigation/menu_spec.js
+++ b/install/ui/src/freeipa/navigation/menu_spec.js
@@ -142,6 +142,11 @@ var nav = {};
 entity: 'caacl',
 facet: 'search',
 hidden: true
+},
+{
+entity: 'ca',
+facet: 'search',
+hidden: true
 }
 ]
 },
diff --git a/install/ui/src/freeipa/plugins/ca.js b/install/ui/src/freeipa/plugins/ca.js
new file mode 100644
index ..14eccef5b797fd6aa8441dc0b0397159dc92f2c8
--- /dev/null
+++ b/install/ui/src/freeipa/plugins/ca.js
@@ -0,0 +1,92 @@
+//
+// Copyright (C) 2016  FreeIPA Contributors see COPYING for license
+//
+
+define([
+'../ipa',
+'../jquery',
+'../phases',
+'../reg',
+'../certificate'
+],
+function(IPA, $, phases, reg, cert) {
+
+/**
+ * ca module
+ * @class plugins.ca
+ * @singleton
+ */
+ var ca = IPA.ca = {};
+
+ var make_ca_spec = function() {
+ var spec = {
+ name: 'ca',
+ facets: [
+ {
+ $type: 'search',
+ disable_facet_tabs: false,
+ tabs_in_sidebar: true,
+ tab_label: '@mo:ca.label',
+ facet_groups: [cert.facet_group],
+ facet_group: 'certificates',
+ columns: [
+ 'cn',
+ {
+label: '@i18n:objects.ca.subject_dn',
+name: 'dn'
+ },
+ 'description'
+ ]
+ },
+ {
+ $type: 'details',
+ disable_facet_tabs: true,
+ fields: [
+ 'cn',
+ 'description',
+ 'dn',
+ 'ipacaid',
+ 'ipacaissuerdn',
+ 'ipacasubjectdn'
+ ]
+ }
+ ],
+ adder_dialog: {
+ fields: [
+ {
+ $type: 'text',
+ name: 'cn',
+ required: true
+ },
+ 'ipacasubjectdn',
+ {
+ $type: 'textarea',
+ name: 'description'
+ }
+ ]
+ }
+ };
+
+ return spec;
+ };
+
+ /**
+  * CA entity specification object
+  * @member plugins.ca
+  */
+ca.ca_spec = make_ca_spec();
+
+/**
+ * Register entity
+ * @member plugins.ca
+ */
+ca.register = function() {
+var e = reg.entity;
+
+e.register({type: 'ca', spec: ca.ca_spec});
+};
+
+phases.on('registration', ca.register);
+
+return ca;
+});
diff --git a/install/ui/test/data/ipa_init.json b/install/ui/test/data/ipa_init.json
index 4ccf49f889f57eb28f11d8ebe701fac47d166879..d34e1f5fcb3c2af2751560d0c94b5e0efc497c63 100644
--- a/install/ui/test/data/ipa_init.json
+++ b/install/ui/test/data/ipa_init.json
@@ -213,6 +213,9 @@
 "indirect": "Indirect",
 "map_type": "Map Type"
 },
+"ca": {
+"subject_dn": "Subject DN"
+},
 "caacl": {
 "any_host": "Any Host",
 "any_service": "Any 

Re: [Freeipa-devel] [PATCH] 0203 adtrust: remove ipanttrustpartner parameter

2016-06-10 Thread Petr Vobornik
On 06/10/2016 04:03 PM, Lukas Slebodnik wrote:
> On (10/06/16 11:01), Martin Kosek wrote:
>> On 06/10/2016 10:01 AM, Martin Basti wrote:

>>> Sorry I misread that ticket in the commit message, because ipatool was 
>>> unable
>>> to parse it from commit message
>>>
>>> Pushed to master: 185806432d6dfccc5cdd73815471ce60a575b073
>>
>> I see no link to this ticket in the commit message in
>> https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=185806432d6dfccc5cdd73815471ce60a575b073
>> Did you push old version of this patch?
>>
>> In general, I would suggest using the patch format from
>> http://www.freeipa.org/page/Contribute/Patch_Format
>> It makes automation easier...
>>
> And it would be much easier for author with .git-commit-template
> @see
> https://git.fedorahosted.org/cgit/sssd.git/commit/?id=3d9edb4c510028def2df41aa7b0ce705b197e6fc
> 
> LS
> 

Good idea, https://fedorahosted.org/freeipa/ticket/5952
-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] [PATCH] 0203 adtrust: remove ipanttrustpartner parameter

2016-06-10 Thread Lukas Slebodnik
On (10/06/16 11:01), Martin Kosek wrote:
>On 06/10/2016 10:01 AM, Martin Basti wrote:
>> 
>> 
>> On 09.06.2016 21:45, Alexander Bokovoy wrote:
>>> On Thu, 09 Jun 2016, Martin Basti wrote:


 On 09.06.2016 17:56, Martin Babinsky wrote:
> On 06/06/2016 01:37 PM, Alexander Bokovoy wrote:
>> On Mon, 06 Jun 2016, Jan Cholasta wrote:
>>> On 6.6.2016 13:22, Martin Basti wrote:


 On 06.06.2016 13:14, Alexander Bokovoy wrote:
> On Mon, 06 Jun 2016, Martin Basti wrote:
>>
>>
>> On 06.06.2016 12:36, Alexander Bokovoy wrote:
>>> Hi,
>>>
>>> MS-ADTS spec requires that TrustPartner field should be equal to the
>>> commonName (cn) of the trust. We used it a bit wrongly to express
>>> trust relationship between parent and child domains. In fact, we
>>> have parent-child relationship recorded in the DN (child domains
>>> are part of the parent domain's container).
>>>
>>> Remove the argument that was never used externally but only
>>> supplied by
>>> trust-specific code inside the IPA framework.
>>>
>>> Part of https://fedorahosted.org/freeipa/ticket/5354
>>>
>>>
>>>
>>
>> Hello, how is handled backward compatibility here, you just removes
>> the option from API, without any additional logic for older clients.
> This is not used by the external clients at all. It is part of 
> internal
> logic of the code in trust.py+com.redhat.trust.fetch-domains which
> always talk to the same server they are running on.
>
> @register()
> class trustdomain_add(LDAPCreate):
>  __doc__ = _('Allow access from the trusted domain')
>  NO_CLI = True
>
>

 Yes sorry, not old IPA clients, but it was part of API, shown in API
 browser, and since this was in API, it is set to stone. So If you think
 that it is safe to be removed and nobody can hit this, I'm okay for
 removing that option. Maybe we should at least wrote it to release 
 notes
 (I'll let Honza to express his feelings as API versioning/compatibility
 sensei)
>>>
>>> IMHO it is safe to remove.
>>>

 And you forgot to increment api version in VERSION file
>> Updated patch attached, with a VERSION change.
>>
>>
>>
> ACK
>

 Is there any ticket for this?
>>> As I wrote in the commit message and in the email,
>>> it is part of https://fedorahosted.org/freeipa/ticket/5354
>>>
>> Sorry I misread that ticket in the commit message, because ipatool was unable
>> to parse it from commit message
>> 
>> Pushed to master: 185806432d6dfccc5cdd73815471ce60a575b073
>
>I see no link to this ticket in the commit message in
>https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=185806432d6dfccc5cdd73815471ce60a575b073
>Did you push old version of this patch?
>
>In general, I would suggest using the patch format from
>http://www.freeipa.org/page/Contribute/Patch_Format
>It makes automation easier...
>
And it would be much easier for author with .git-commit-template
@see
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=3d9edb4c510028def2df41aa7b0ce705b197e6fc

LS

-- 
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][WIP] DNS Location: generator for location records

2016-06-10 Thread Martin Basti



On 10.06.2016 10:21, Martin Basti wrote:




On 09.06.2016 12:21, Martin Basti wrote:

Hello,

here is WIP version of generator for IPA DNS records and locations, 
that is responsible for creating and updating all IPA records for all 
masters.


Please note that this is not finished yet and some methods may not work.


Patch attached




Updated, this version actually works


SelfNACK, I will use Zone object as storage for data instead of random 
lists and dicts
-- 
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] [PATCHES 0146-0152] Server Roles v2

2016-06-10 Thread Jan Cholasta

On 9.6.2016 17:06, Martin Babinsky wrote:

On 06/09/2016 03:54 PM, Petr Vobornik wrote:

On 06/09/2016 01:02 PM, Martin Babinsky wrote:

On 06/07/2016 07:01 PM, Pavel Vomacka wrote:



On 06/07/2016 12:07 PM, Martin Babinsky wrote:

On 06/03/2016 05:25 PM, Martin Babinsky wrote:

I am sending rebased patches implementing
http://www.freeipa.org/page/V4/Server_Roles

I hope the patches work since I have had a lot of fun rebasing
them on
top of thin client and DNS locations effort.

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





Sending updated patches according to Jan's interactive review.

Since the name of attributes returned by API commands and signature of
`server-role-find` have changed, a small update in WebUI patches is
required.




NACK, why did you remove sizelimit from server_role_find command's? Is
it possible to return it back? It breaks WebUI.


Indeed, this was caused by changing the base class of the command. It is
fixed in updated patches.



NACK

Option timelimit? of command server_role_find in ipalib, not in API file:
Int('timelimit?', autofill=False)
Option sizelimit? of command server_role_find in ipalib, not in API file:
Int('sizelimit?', autofill=False)

There are one or more changes to the API.
Either undo the API changes or update API.txt and increment the major
version in VERSION.
Makefile:159: recipe for target 'version-update' failed
make: *** [version-update] Error 1



Oops, seems like a missed API.txt update.

Fixed.


"ipa server-role-find" does not return the "IPA master" role for my 
server ("ipa-server-role $HOSTNAME 'IPA master'" does).


I would rather skip the option altogether rather than hide it:

+# we do not want to test negative membership for roles
+# hide it from CLI
+elif option.name == 'no_servrole':
+option = option.clone(flags={'no_option'})

The patches need a rebase (VERSION).

Otherwise LGTM.

--
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] [PATCH] 0204 adtrust: support GSSAPI authentication to LDAP as Active Directory user

2016-06-10 Thread Petr Vobornik
On 06/10/2016 01:09 PM, Alexander Bokovoy wrote:
> On Fri, 10 Jun 2016, Petr Vobornik wrote:
>> On 06/10/2016 12:43 PM, Alexander Bokovoy wrote:
>>> On Fri, 10 Jun 2016, Petr Vobornik wrote:
 On 06/09/2016 09:47 PM, Alexander Bokovoy wrote:
> On Thu, 09 Jun 2016, Martin Basti wrote:
>>
>>
>> On 09.06.2016 17:49, Martin Babinsky wrote:
>>> On 06/06/2016 12:38 PM, Alexander Bokovoy wrote:
 Hi,

 In case an ID override was created for an Active Directory user in
 the
 default trust view, allow mapping the incoming GSSAPI authenticated
 connection to the ID override for this user.

 This allows to self-manage ID override parameters from the CLI, for
 example, SSH public keys or certificates. Admins can define what
 can be
 changed by the users via self-service permissions.

 Part of https://fedorahosted.org/freeipa/ticket/2149



>>> ACK
>>>
>>
>> Ticket for this is in 'Tickets Deferred' milestone and should be
>> re-triaged before push
> The ticket itself covers a far longer story and should stay in the
> deferred bucket. However, this specific part of the implementation was
> already discussed to be for 4.4. Don't pull the original ticket, as
> I'm
> using it as a tracker.

 This ticket should be used for that:
 https://fedorahosted.org/freeipa/ticket/3242
>>> I'm not sure. We have 2149 which came earlier (almost 5 years ago!) and
>>> is properly describing what this is about.
>>>
>>> Note that if you manually add ID Override record to the cn=admins group,
>>> then AD users will indeed be able to manage IPA via CLI.
>>>
>>> 3242 is more UI related. UI part needs to be done as we have explicit
>>> prevention for AD user logons right now.
>>
>> Most proper would be to create a new ticket, link to bz 1287194 and
>> make it a blocker for 2149 and 3242. But I'm fine with updating both
>> tickets(2149, 3242) with the commit ID while leaving the tickets open.
>>
>> Up to you.
> That's what I did when I chose to put the reference to ticket 2149
> already.

Added
 "Part of https://fedorahosted.org/freeipa/ticket/3242;

to commit message. Removed blank lines at the end of update files which
git complained about and pushed to master:

* b506fd178edbf1553ca581c44ac6697f88ead125 adtrust: support GSSAPI
authentication to LDAP as Active Directory user

-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] [PATCH 0046] Don't fail in find/show methods if userCertificate is invalid

2016-06-10 Thread Stanislav Laznicka

On 06/09/2016 04:32 PM, Rob Crittenden wrote:

Fraser Tweedale wrote:

On Thu, Jun 09, 2016 at 03:07:34PM +0200, Martin Basti wrote:

On 09.06.2016 15:03, Martin Basti wrote:

On 09.06.2016 15:02, Stanislav Laznicka wrote:

On 06/09/2016 02:51 PM, Rob Crittenden wrote:

Stanislav Laznicka wrote:

Hello,

Please see the attached patch of
https://fedorahosted.org/freeipa/ticket/5797.

Standa


Just wondering out loud but should usercertificate be excluded
from the output if it is unparsable? Is there any value in
showing that a bogus value is in there?

rob

I think it is a good pointer that something has gone wrong with the
certificate. Another way would be to print 'Invalid certificate'
instead of it similar to what Apache LDAP Browser does.

We can return a warning message that something with certificates is
broken.

Martin^2


And you should log it at error log level, because it is error


Is the data from LDAP actually invalid?  It should not be possible
to store data that is not a syntactically valid X.509 cert in the
userCertificate attribute (if it is, we should file a ticket against
389).

Is there a full traceback for the original error of #5797?  What is
the datum that is the immediate cause of the error and what happens
to it between the database and the function that throws?

Could it be a python3 bytes/str problem originating in
x509.normalize_certificate?

Cheers,
Fraser



A cert can get in several different ways. IPA sure tries hard not to 
allow bad certs but I guess they can happen:


$ ldapmodify -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: ad...@greyoak.com
SASL SSF: 56
SASL data security layer installed.
dn: 
krbprincipalname=cert/slithy.greyoak@greyoak.com,cn=services,cn=accounts,dc=greyoak,dc=com

changetype: modify
add: usercertificate
usercertificate: foo

modifying entry 
"krbprincipalname=cert/slithy.greyoak@greyoak.com,cn=services,cn=accounts,dc=greyoak,dc=com"

< .. snip .. >
That is exactly how I was reproducing this issue.

Added is the patch that adds error message and logs properly.
From 6913cb98da07b235b571d0772889df9a2caff1e8 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Thu, 9 Jun 2016 13:13:24 +0200
Subject: [PATCH] host/service-show/find shouldn't fail on invalid certificate

host/service-show/find methods would have failed if the first
certificate they had in userCertificate attribute were invalid.
Expected behavior is that they just show the rest of the reqested
attributes.

https://fedorahosted.org/freeipa/ticket/5797
---
 ipalib/messages.py   | 10 ++
 ipaserver/plugins/host.py| 31 +--
 ipaserver/plugins/service.py | 34 +++---
 3 files changed, 70 insertions(+), 5 deletions(-)

diff --git a/ipalib/messages.py b/ipalib/messages.py
index e863bdd495b55921c9e487794f5c9573a6166038..2c02f8b912f5e8253048f63c0b60a5483b29772b 100644
--- a/ipalib/messages.py
+++ b/ipalib/messages.py
@@ -395,6 +395,16 @@ class DNSForwardPolicyConflictWithEmptyZone(PublicMessage):
 )
 
 
+class CertificateInvalid(PublicMessage):
+"""
+***13022 Failed to parse a certificate
+"""
+errno = 13022
+type = "error"
+format = _("%(subject)s: Invalid certificate. "
+   "%(reason)s")
+
+
 def iter_messages(variables, base):
 """Return a tuple with all subclasses
 """
diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py
index e59e0fa93c9fc0b9c6fccc36421d3489678a0eb2..befa4d8bbb602594cfaa388cf9615d1f62b6a028 100644
--- a/ipaserver/plugins/host.py
+++ b/ipaserver/plugins/host.py
@@ -1023,7 +1023,21 @@ class host_find(LDAPSearch):
 if options.get('pkey_only', False):
 return truncated
 for entry_attrs in entries:
-set_certificate_attrs(entry_attrs)
+hostname = entry_attrs['fqdn']
+if isinstance(hostname, (tuple, list)):
+hostname = hostname[0]
+try:
+set_certificate_attrs(entry_attrs)
+except errors.CertificateFormatError as e:
+self.add_message(
+messages.CertificateInvalid(
+subject=hostname,
+reason=e,
+)
+)
+self.log.error("Invalid certificate: {err}".format(err=e))
+del(entry_attrs['usercertificate'])
+
 set_kerberos_attrs(entry_attrs, options)
 rename_ipaallowedtoperform_from_ldap(entry_attrs, options)
 self.obj.suppress_netgroup_memberof(ldap, entry_attrs)
@@ -1066,7 +1080,20 @@ class host_show(LDAPRetrieve):
 # fetched anywhere.
 entry_attrs['has_keytab'] = False
 
-set_certificate_attrs(entry_attrs)
+hostname = entry_attrs['fqdn']
+if isinstance(hostname, (tuple, list)):
+hostname = hostname[0]
+try:
+

Re: [Freeipa-devel] [PATCH] 0204 adtrust: support GSSAPI authentication to LDAP as Active Directory user

2016-06-10 Thread Alexander Bokovoy

On Fri, 10 Jun 2016, Petr Vobornik wrote:

On 06/10/2016 12:43 PM, Alexander Bokovoy wrote:

On Fri, 10 Jun 2016, Petr Vobornik wrote:

On 06/09/2016 09:47 PM, Alexander Bokovoy wrote:

On Thu, 09 Jun 2016, Martin Basti wrote:



On 09.06.2016 17:49, Martin Babinsky wrote:

On 06/06/2016 12:38 PM, Alexander Bokovoy wrote:

Hi,

In case an ID override was created for an Active Directory user in
the
default trust view, allow mapping the incoming GSSAPI authenticated
connection to the ID override for this user.

This allows to self-manage ID override parameters from the CLI, for
example, SSH public keys or certificates. Admins can define what
can be
changed by the users via self-service permissions.

Part of https://fedorahosted.org/freeipa/ticket/2149




ACK



Ticket for this is in 'Tickets Deferred' milestone and should be
re-triaged before push

The ticket itself covers a far longer story and should stay in the
deferred bucket. However, this specific part of the implementation was
already discussed to be for 4.4. Don't pull the original ticket, as I'm
using it as a tracker.


This ticket should be used for that:
https://fedorahosted.org/freeipa/ticket/3242

I'm not sure. We have 2149 which came earlier (almost 5 years ago!) and
is properly describing what this is about.

Note that if you manually add ID Override record to the cn=admins group,
then AD users will indeed be able to manage IPA via CLI.

3242 is more UI related. UI part needs to be done as we have explicit
prevention for AD user logons right now.


Most proper would be to create a new ticket, link to bz 1287194 and
make it a blocker for 2149 and 3242. But I'm fine with updating both
tickets(2149, 3242) with the commit ID while leaving the tickets open.

Up to you.

That's what I did when I chose to put the reference to ticket 2149
already.
--
/ Alexander Bokovoy

--
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] 0204 adtrust: support GSSAPI authentication to LDAP as Active Directory user

2016-06-10 Thread Petr Vobornik
On 06/10/2016 12:43 PM, Alexander Bokovoy wrote:
> On Fri, 10 Jun 2016, Petr Vobornik wrote:
>> On 06/09/2016 09:47 PM, Alexander Bokovoy wrote:
>>> On Thu, 09 Jun 2016, Martin Basti wrote:


 On 09.06.2016 17:49, Martin Babinsky wrote:
> On 06/06/2016 12:38 PM, Alexander Bokovoy wrote:
>> Hi,
>>
>> In case an ID override was created for an Active Directory user in
>> the
>> default trust view, allow mapping the incoming GSSAPI authenticated
>> connection to the ID override for this user.
>>
>> This allows to self-manage ID override parameters from the CLI, for
>> example, SSH public keys or certificates. Admins can define what
>> can be
>> changed by the users via self-service permissions.
>>
>> Part of https://fedorahosted.org/freeipa/ticket/2149
>>
>>
>>
> ACK
>

 Ticket for this is in 'Tickets Deferred' milestone and should be
 re-triaged before push
>>> The ticket itself covers a far longer story and should stay in the
>>> deferred bucket. However, this specific part of the implementation was
>>> already discussed to be for 4.4. Don't pull the original ticket, as I'm
>>> using it as a tracker.
>>
>> This ticket should be used for that:
>> https://fedorahosted.org/freeipa/ticket/3242
> I'm not sure. We have 2149 which came earlier (almost 5 years ago!) and
> is properly describing what this is about.
> 
> Note that if you manually add ID Override record to the cn=admins group,
> then AD users will indeed be able to manage IPA via CLI.
> 
> 3242 is more UI related. UI part needs to be done as we have explicit
> prevention for AD user logons right now.

Most proper would be to create a new ticket, link to bz ​1287194 and
make it a blocker for 2149 and 3242. But I'm fine with updating both
tickets(2149, 3242) with the commit ID while leaving the tickets open.

Up to you.
-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0204 adtrust: support GSSAPI authentication to LDAP as Active Directory user

2016-06-10 Thread Alexander Bokovoy

On Fri, 10 Jun 2016, Petr Vobornik wrote:

On 06/09/2016 09:47 PM, Alexander Bokovoy wrote:

On Thu, 09 Jun 2016, Martin Basti wrote:



On 09.06.2016 17:49, Martin Babinsky wrote:

On 06/06/2016 12:38 PM, Alexander Bokovoy wrote:

Hi,

In case an ID override was created for an Active Directory user in the
default trust view, allow mapping the incoming GSSAPI authenticated
connection to the ID override for this user.

This allows to self-manage ID override parameters from the CLI, for
example, SSH public keys or certificates. Admins can define what can be
changed by the users via self-service permissions.

Part of https://fedorahosted.org/freeipa/ticket/2149




ACK



Ticket for this is in 'Tickets Deferred' milestone and should be
re-triaged before push

The ticket itself covers a far longer story and should stay in the
deferred bucket. However, this specific part of the implementation was
already discussed to be for 4.4. Don't pull the original ticket, as I'm
using it as a tracker.


This ticket should be used for that:
https://fedorahosted.org/freeipa/ticket/3242

I'm not sure. We have 2149 which came earlier (almost 5 years ago!) and
is properly describing what this is about.

Note that if you manually add ID Override record to the cn=admins group,
then AD users will indeed be able to manage IPA via CLI.

3242 is more UI related. UI part needs to be done as we have explicit
prevention for AD user logons right now.
--
/ Alexander Bokovoy

--
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] 0204 adtrust: support GSSAPI authentication to LDAP as Active Directory user

2016-06-10 Thread Petr Vobornik
On 06/09/2016 09:47 PM, Alexander Bokovoy wrote:
> On Thu, 09 Jun 2016, Martin Basti wrote:
>>
>>
>> On 09.06.2016 17:49, Martin Babinsky wrote:
>>> On 06/06/2016 12:38 PM, Alexander Bokovoy wrote:
 Hi,

 In case an ID override was created for an Active Directory user in the
 default trust view, allow mapping the incoming GSSAPI authenticated
 connection to the ID override for this user.

 This allows to self-manage ID override parameters from the CLI, for
 example, SSH public keys or certificates. Admins can define what can be
 changed by the users via self-service permissions.

 Part of https://fedorahosted.org/freeipa/ticket/2149



>>> ACK
>>>
>>
>> Ticket for this is in 'Tickets Deferred' milestone and should be
>> re-triaged before push
> The ticket itself covers a far longer story and should stay in the
> deferred bucket. However, this specific part of the implementation was
> already discussed to be for 4.4. Don't pull the original ticket, as I'm
> using it as a tracker.

This ticket should be used for that:
https://fedorahosted.org/freeipa/ticket/3242

-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


[Freeipa-devel] [PATCH 0023] topology plugins sigsev when adding a managed host

2016-06-10 Thread Ludwig Krispenz

Hi,
the attached patch will prevent the crash reported in ticket #5928.

So far I do not understand how this situation can occur, there is no 
reproducer yet. I do not really like this fix as it hides a probable 
corrupted data structure and would prefer to find the root cause.


But please review it, so we can commit it if there is no progress on the 
root cause.


Ludwig

--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

>From a3c20fb375da1d0c663d587bd25114e131874050 Mon Sep 17 00:00:00 2001
From: Ludwig Krispenz 
Date: Fri, 10 Jun 2016 10:48:04 +0200
Subject: [PATCH] avoid crash in topology plugin when host list contains host
 with no hostname: ticket #5928

---
 daemons/ipa-slapi-plugins/topology/topology_cfg.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/daemons/ipa-slapi-plugins/topology/topology_cfg.c b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
index 3ca61a8ea7c463c45f3dbf2e13a9790c5079e2d7..2248269fdfeb1d1bc80a31be0241ec8bcee7cf3f 100644
--- a/daemons/ipa-slapi-plugins/topology/topology_cfg.c
+++ b/daemons/ipa-slapi-plugins/topology/topology_cfg.c
@@ -452,6 +452,15 @@ ipa_topo_cfg_host_find(TopoReplica *tconf, char *findhost, int lock)
 
 if (lock) slapi_lock_mutex(tconf->repl_lock);
 for (host=tconf->hosts;host;host=host->next) {
+if (host->hostname == NULL) {
+/* this check is done to avoid a crash,
+ * for which the root cause is not yet known.
+ * Avoid the crash and log an error
+ */
+slapi_log_error(SLAPI_LOG_PLUGIN, IPA_TOPO_PLUGIN_SUBSYSTEM,
+"ipa_topo_cfg_host_find: found a NULL hostname in host list\n");
+continue;
+}
 if (!strcasecmp(host->hostname,findhost)) {
break;
 }
-- 
2.4.3

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0046] Don't fail in find/show methods if userCertificate is invalid

2016-06-10 Thread Petr Spacek
On 9.6.2016 15:07, Martin Basti wrote:
> 
> 
> On 09.06.2016 15:03, Martin Basti wrote:
>>
>>
>> On 09.06.2016 15:02, Stanislav Laznicka wrote:
>>> On 06/09/2016 02:51 PM, Rob Crittenden wrote:
 Stanislav Laznicka wrote:
> Hello,
>
> Please see the attached patch of
> https://fedorahosted.org/freeipa/ticket/5797.
>
> Standa
>
>
>

 Just wondering out loud but should usercertificate be excluded from the
 output if it is unparsable? Is there any value in showing that a bogus
 value is in there?

 rob
>>> I think it is a good pointer that something has gone wrong with the
>>> certificate. Another way would be to print 'Invalid certificate' instead of
>>> it similar to what Apache LDAP Browser does.
>>>
>>
>> We can return a warning message that something with certificates is broken.
>>
>> Martin^2
>>
> And you should log it at error log level, because it is error

+1

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] [PATCH] 0203 adtrust: remove ipanttrustpartner parameter

2016-06-10 Thread Martin Basti



On 10.06.2016 12:13, Martin Basti wrote:



On 10.06.2016 11:01, Martin Kosek wrote:

On 06/10/2016 10:01 AM, Martin Basti wrote:


On 09.06.2016 21:45, Alexander Bokovoy wrote:

On Thu, 09 Jun 2016, Martin Basti wrote:


On 09.06.2016 17:56, Martin Babinsky wrote:

On 06/06/2016 01:37 PM, Alexander Bokovoy wrote:

On Mon, 06 Jun 2016, Jan Cholasta wrote:

On 6.6.2016 13:22, Martin Basti wrote:


On 06.06.2016 13:14, Alexander Bokovoy wrote:

On Mon, 06 Jun 2016, Martin Basti wrote:


On 06.06.2016 12:36, Alexander Bokovoy wrote:

Hi,

MS-ADTS spec requires that TrustPartner field should be 
equal to the
commonName (cn) of the trust. We used it a bit wrongly to 
express
trust relationship between parent and child domains. In 
fact, we
have parent-child relationship recorded in the DN (child 
domains

are part of the parent domain's container).

Remove the argument that was never used externally but only
supplied by
trust-specific code inside the IPA framework.

Part of https://fedorahosted.org/freeipa/ticket/5354



Hello, how is handled backward compatibility here, you just 
removes
the option from API, without any additional logic for older 
clients.
This is not used by the external clients at all. It is part 
of internal
logic of the code in trust.py+com.redhat.trust.fetch-domains 
which

always talk to the same server they are running on.

@register()
class trustdomain_add(LDAPCreate):
  __doc__ = _('Allow access from the trusted domain')
  NO_CLI = True


Yes sorry, not old IPA clients, but it was part of API, shown 
in API
browser, and since this was in API, it is set to stone. So If 
you think
that it is safe to be removed and nobody can hit this, I'm 
okay for
removing that option. Maybe we should at least wrote it to 
release notes
(I'll let Honza to express his feelings as API 
versioning/compatibility

sensei)

IMHO it is safe to remove.


And you forgot to increment api version in VERSION file

Updated patch attached, with a VERSION change.




ACK


Is there any ticket for this?

As I wrote in the commit message and in the email,
it is part of https://fedorahosted.org/freeipa/ticket/5354

Sorry I misread that ticket in the commit message, because ipatool 
was unable

to parse it from commit message

Pushed to master: 185806432d6dfccc5cdd73815471ce60a575b073

I see no link to this ticket in the commit message in
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=185806432d6dfccc5cdd73815471ce60a575b073 


Did you push old version of this patch?

In general, I would suggest using the patch format from
http://www.freeipa.org/page/Contribute/Patch_Format
It makes automation easier...

Martin


Oh well, yes, my bad

I will revert the wrong commit and push the right one

Martin^2



Revert:
master
*478017357b50cb7fe30d6a4e26c3c47e111c91d0 Revert "adtrust: remove 
nttrustpartner parameter"


The right patch:
master:
a0f953e0ff89900d9767df3e6ed868ae662616b4 adtrust: remove nttrustpartner 
parameter


--
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] 0203 adtrust: remove ipanttrustpartner parameter

2016-06-10 Thread Martin Kosek
On 06/10/2016 10:01 AM, Martin Basti wrote:
> 
> 
> On 09.06.2016 21:45, Alexander Bokovoy wrote:
>> On Thu, 09 Jun 2016, Martin Basti wrote:
>>>
>>>
>>> On 09.06.2016 17:56, Martin Babinsky wrote:
 On 06/06/2016 01:37 PM, Alexander Bokovoy wrote:
> On Mon, 06 Jun 2016, Jan Cholasta wrote:
>> On 6.6.2016 13:22, Martin Basti wrote:
>>>
>>>
>>> On 06.06.2016 13:14, Alexander Bokovoy wrote:
 On Mon, 06 Jun 2016, Martin Basti wrote:
>
>
> On 06.06.2016 12:36, Alexander Bokovoy wrote:
>> Hi,
>>
>> MS-ADTS spec requires that TrustPartner field should be equal to the
>> commonName (cn) of the trust. We used it a bit wrongly to express
>> trust relationship between parent and child domains. In fact, we
>> have parent-child relationship recorded in the DN (child domains
>> are part of the parent domain's container).
>>
>> Remove the argument that was never used externally but only
>> supplied by
>> trust-specific code inside the IPA framework.
>>
>> Part of https://fedorahosted.org/freeipa/ticket/5354
>>
>>
>>
>
> Hello, how is handled backward compatibility here, you just removes
> the option from API, without any additional logic for older clients.
 This is not used by the external clients at all. It is part of internal
 logic of the code in trust.py+com.redhat.trust.fetch-domains which
 always talk to the same server they are running on.

 @register()
 class trustdomain_add(LDAPCreate):
  __doc__ = _('Allow access from the trusted domain')
  NO_CLI = True


>>>
>>> Yes sorry, not old IPA clients, but it was part of API, shown in API
>>> browser, and since this was in API, it is set to stone. So If you think
>>> that it is safe to be removed and nobody can hit this, I'm okay for
>>> removing that option. Maybe we should at least wrote it to release notes
>>> (I'll let Honza to express his feelings as API versioning/compatibility
>>> sensei)
>>
>> IMHO it is safe to remove.
>>
>>>
>>> And you forgot to increment api version in VERSION file
> Updated patch attached, with a VERSION change.
>
>
>
 ACK

>>>
>>> Is there any ticket for this?
>> As I wrote in the commit message and in the email,
>> it is part of https://fedorahosted.org/freeipa/ticket/5354
>>
> Sorry I misread that ticket in the commit message, because ipatool was unable
> to parse it from commit message
> 
> Pushed to master: 185806432d6dfccc5cdd73815471ce60a575b073

I see no link to this ticket in the commit message in
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=185806432d6dfccc5cdd73815471ce60a575b073
Did you push old version of this patch?

In general, I would suggest using the patch format from
http://www.freeipa.org/page/Contribute/Patch_Format
It makes automation easier...

Martin

-- 
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 0501] Revert: switch /usr/bin/ipa to python3

2016-06-10 Thread Martin Basti



On 10.06.2016 06:17, Jan Cholasta wrote:

On 9.6.2016 20:57, Martin Basti wrote:

Py3 support was enabled prematurely, attached patches removes python3
from /usr/bin/ipa


Notes:

* ipa 4.3.x won't have enabled py3

* master (ipa 4.4+) will have disabled py3 temporarily


NACK. you reverted this bit wrong:

-%if 0%{?with_python3}
-Requires: python3-ipaclient = %{version}-%{release}
-%else
 Requires: python2-ipaclient = %{version}-%{release}
-%endif
+Requires: %{name}-client-common = %{version}-%{release}
+Requires: python2-ipalib = %{version}-%{release}



Shame on me,

updated patch attached
From 606a8ed11692980d578c23d5bb70d10cd84f490d Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 10 Jun 2016 10:38:55 +0200
Subject: [PATCH] Revert "Switch /usr/bin/ipa to Python 3"

This reverts commit 1ebd8334bc7da95f1edd64fc930e9cd6e3650534.

Switch 'ipa' command to py3 has been done prematurely, thus this commit
reverts it from IPA 4.3.2 and temporarily from master because it is
blocker for developing of the new features.

https://fedorahosted.org/freeipa/ticket/5638
---
 freeipa.spec.in | 11 ---
 ipa |  2 +-
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 58344695cae08fa1baf2123a13eb99f3fbc6d496..f51fec4ebf15ab73a4c4fe1c51647ce4709ee38b 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -421,11 +421,7 @@ installed on every client machine.
 Summary: IPA administrative tools
 Group: System Environment/Base
 BuildArch: noarch
-%if 0%{?with_python3}
-Requires: python3-ipaclient = %{version}-%{release}
-%else
 Requires: python2-ipaclient = %{version}-%{release}
-%endif
 Requires: python-ldap
 
 Provides: %{alt_name}-admintools = %{version}
@@ -741,13 +737,6 @@ make client-install DESTDIR=%{buildroot}
 (cd ipapython && make PYTHON=%{__python3} IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} DESTDIR=%{buildroot} install)
 (cd ipaplatform && %{__python3} setup.py install --root %{buildroot})
 (cd ipaclient && %{__python3} setup.py install --root %{buildroot})
-
-# Switch shebang of /usr/bin/ipa
-# XXX: This script is installed with ipaserver. When all of ipaserver is
-# built with Python 3, this will no longer be necessary (as long as the py3
-# version is installed after the py2 version, so it overwrites /usr/bin/ipa)
-sed -i -e'1s/python\(2\|$\)/python3/' %{buildroot}%{_bindir}/ipa
-
 %endif # with_python3
 
 %find_lang %{gettext_domain}
diff --git a/ipa b/ipa
index 342c5414792cbc2b6a2a393c5a3b8d9a54dbac80..9ef356868a444555172d35e5f44a86f6f9914d71 100755
--- a/ipa
+++ b/ipa
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/python2
 
 # Authors:
 #   Jason Gerard DeRose 
-- 
2.5.5

From c7988f133de6d5d9a84e02e6d8b7f060173f757d Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Thu, 9 Jun 2016 20:37:55 +0200
Subject: [PATCH] Revert "Switch /usr/bin/ipa to Python 3"

This reverts commit 1ebd8334bc7da95f1edd64fc930e9cd6e3650534.

Switch 'ipa' command to py3 has been done prematurely, thus this commit
reverts it from IPA 4.3.2 and temporarily from master because it is
blocker for developing of the new features.

https://fedorahosted.org/freeipa/ticket/5638
---
 freeipa.spec.in | 11 ---
 ipa |  2 +-
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index ebd910a3df287a0154624391ddb54567cbb47364..c884990c3d158d4ae5bb84d869de4fde0915809b 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -421,11 +421,7 @@ Summary: IPA administrative tools
 Group: System Environment/Base
 BuildArch: noarch
 Requires: %{name}-client-common = %{version}-%{release}
-%if 0%{?with_python3}
-Requires: python3-ipalib = %{version}-%{release}
-%else
 Requires: python2-ipalib = %{version}-%{release}
-%endif
 Requires: python-ldap
 
 Provides: %{alt_name}-admintools = %{version}
@@ -741,13 +737,6 @@ make client-install DESTDIR=%{buildroot}
 (cd ipapython && make PYTHON=%{__python3} IPA_VERSION_IS_GIT_SNAPSHOT=no %{?_smp_mflags} DESTDIR=%{buildroot} install)
 (cd ipaplatform && %{__python3} setup.py install --root %{buildroot})
 (cd ipaclient && %{__python3} setup.py install --root %{buildroot})
-
-# Switch shebang of /usr/bin/ipa
-# XXX: This script is installed with ipaserver. When all of ipaserver is
-# built with Python 3, this will no longer be necessary (as long as the py3
-# version is installed after the py2 version, so it overwrites /usr/bin/ipa)
-sed -i -e'1s/python\(2\|$\)/python3/' %{buildroot}%{_bindir}/ipa
-
 %endif # with_python3
 
 %find_lang %{gettext_domain}
diff --git a/ipa b/ipa
index 338105d7ec57897078c4e94cf5959259565624d2..64ceea49732bb11c4d69cf353d1a2d183e58981a 100755
--- a/ipa
+++ b/ipa
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/python2
 
 # Authors:
 #   Jason Gerard DeRose 
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:

Re: [Freeipa-devel] [PATCH][WIP] DNS Location: generator for location records

2016-06-10 Thread Martin Basti



On 09.06.2016 12:21, Martin Basti wrote:

Hello,

here is WIP version of generator for IPA DNS records and locations, 
that is responsible for creating and updating all IPA records for all 
masters.


Please note that this is not finished yet and some methods may not work.


Patch attached




Updated, this version actually works
From 511adfcc1c33ae8d49afb4fc21a6eb1cf2b211b2 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Wed, 8 Jun 2016 17:53:58 +0200
Subject: [PATCH 1/2] DNS Location: generator for records

WIP
---
 install/share/60ipadns.ldif |   2 +
 ipalib/dns.py   | 334 
 ipaserver/plugins/dns.py|   1 +
 3 files changed, 337 insertions(+)

diff --git a/install/share/60ipadns.ldif b/install/share/60ipadns.ldif
index 5bfed905566bdbfe4e011e218c328701ce854943..0eb90d68353fd94605e70070bb885e4158281235 100644
--- a/install/share/60ipadns.ldif
+++ b/install/share/60ipadns.ldif
@@ -70,6 +70,7 @@ attributeTypes: ( 2.16.840.1.113730.3.8.5.25 NAME 'idnsSecKeyRevoke' DESC 'DNSKE
 attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 'idnsSecKeySep' DESC 'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v4.1' )
 attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 'idnsSecAlgorithm' DESC 'DNSKEY algorithm: string used as mnemonic' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v4.1' )
 attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 'idnsSecKeyRef' DESC 'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' )
+attributeTypes: ( 2.16.840.1.113730.3.8.5.29 NAME 'idnsTemplateAttribute' DESC 'Template attribute for dynamic attribute generation' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v4.4' )
 attributeTypes: ( 2.16.840.1.113730.3.8.11.74 NAME 'ipaDNSVersion' DESC 'IPA DNS data version' EQUALITY integerMatch ORDERING integerOrderingMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'IPA v4.3' )
 attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 'ipaLocation' DESC 'Reference to IPA location' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' )
 attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 'ipaLocationWeight' DESC 'Weight for the server in IPA location' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' )
@@ -79,6 +80,7 @@ objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 'idnsConfigObject' DESC 'DNS glo
 objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 'ipaDNSZone' SUP top AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' )
 objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 'idnsForwardZone' DESC 'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ idnsZoneActive ) MAY ( idnsForwarders $ idnsForwardPolicy ) )
 objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 'idnsSecKey' DESC 'DNSSEC key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ idnsSecKeyCreated $ idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $ idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ idnsSecKeyRevoke $ idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' )
+objectClasses: ( 2.16.840.1.113730.3.8.6.5 NAME 'idnsTemplateObject' DESC 'Template object for dynamic DNS attribute generation' AUXILIARY MUST ( idnsTemplateAttribute ) X-ORIGIN 'IPA v4.4' )
 objectClasses: ( 2.16.840.1.113730.3.8.12.36 NAME 'ipaDNSContainer' DESC 'IPA DNS container' AUXILIARY MUST ( ipaDNSVersion ) X-ORIGIN 'IPA v4.3' )
 objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 'ipaLocationObject' DESC 'Object for storing IPA server location' STRUCTURAL MUST ( idnsName ) MAY ( description ) X-ORIGIN 'IPA v4.4' )
 objectClasses: ( 2.16.840.1.113730.3.8.6.8 NAME 'ipaLocationMember' DESC 'Member object of IPA location' AUXILIARY MAY ( ipaLocation $ ipaLocationWeight ) X-ORIGIN 'IPA v4.4' )
diff --git a/ipalib/dns.py b/ipalib/dns.py
index 54a4c24a08c974d8e905e4630d91d2381c39778d..a234c9b57d9e7b4cbd07f74f5051b8ab0ac2124f 100644
--- a/ipalib/dns.py
+++ b/ipalib/dns.py
@@ -18,9 +18,19 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
+from __future__ import absolute_import
+
 import re
+from collections import defaultdict
+from dns import (
+rrset,
+rdataclass,
+rdatatype,
+)
+from dns.rdtypes.IN.SRV import SRV
 
 from ipalib import errors
+from ipapython.dnsutil import DNSName, resolve_rrsets
 
 # dnsrecord param name formats
 record_name_format = '%srecord'
@@ -98,3 +108,327 @@ def iterate_rrparams_by_parts(cmd, kw, skip_extra=False):
 if rrparam.name not in processed:
 processed.append(rrparam.name)
 yield rrparam
+
+
+class DNSRecordsGenerator(object):
+
+IPA_DEFAULT_MASTER_SRV_REC 

Re: [Freeipa-devel] [PATCH] 0203 adtrust: remove ipanttrustpartner parameter

2016-06-10 Thread Martin Basti



On 09.06.2016 21:45, Alexander Bokovoy wrote:

On Thu, 09 Jun 2016, Martin Basti wrote:



On 09.06.2016 17:56, Martin Babinsky wrote:

On 06/06/2016 01:37 PM, Alexander Bokovoy wrote:

On Mon, 06 Jun 2016, Jan Cholasta wrote:

On 6.6.2016 13:22, Martin Basti wrote:



On 06.06.2016 13:14, Alexander Bokovoy wrote:

On Mon, 06 Jun 2016, Martin Basti wrote:



On 06.06.2016 12:36, Alexander Bokovoy wrote:

Hi,

MS-ADTS spec requires that TrustPartner field should be equal 
to the

commonName (cn) of the trust. We used it a bit wrongly to express
trust relationship between parent and child domains. In fact, we
have parent-child relationship recorded in the DN (child domains
are part of the parent domain's container).

Remove the argument that was never used externally but only
supplied by
trust-specific code inside the IPA framework.

Part of https://fedorahosted.org/freeipa/ticket/5354





Hello, how is handled backward compatibility here, you just 
removes
the option from API, without any additional logic for older 
clients.
This is not used by the external clients at all. It is part of 
internal

logic of the code in trust.py+com.redhat.trust.fetch-domains which
always talk to the same server they are running on.

@register()
class trustdomain_add(LDAPCreate):
 __doc__ = _('Allow access from the trusted domain')
 NO_CLI = True




Yes sorry, not old IPA clients, but it was part of API, shown in API
browser, and since this was in API, it is set to stone. So If you 
think

that it is safe to be removed and nobody can hit this, I'm okay for
removing that option. Maybe we should at least wrote it to 
release notes
(I'll let Honza to express his feelings as API 
versioning/compatibility

sensei)


IMHO it is safe to remove.



And you forgot to increment api version in VERSION file

Updated patch attached, with a VERSION change.




ACK



Is there any ticket for this?

As I wrote in the commit message and in the email,
it is part of https://fedorahosted.org/freeipa/ticket/5354

Sorry I misread that ticket in the commit message, because ipatool was 
unable to parse it from commit message


Pushed to master: 185806432d6dfccc5cdd73815471ce60a575b073





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