Re: [Freeipa-devel] [PATCH] 0069 renew_ca_cert: bootstrap api with in_server=True

2016-06-16 Thread Fraser Tweedale 
On Fri, Jun 17, 2016 at 08:35:45AM +0200, Jan Cholasta wrote:
> Hi,
> 
> On 17.6.2016 06:55, Fraser Tweedale wrote:
> > Attached patch fixes https://fedorahosted.org/freeipa/ticket/5968
> 
> This should be fixed for all the restart scripts, not just renew_ca_cert.
> 
Updated patch attached.
From dac1e3e748fc5b9b3d48aa1dc2050d5f9a505773 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Fri, 17 Jun 2016 14:18:05 +1000
Subject: [PATCH] restart scripts: bootstrap api with in_server=True

renew_ca_cert fails because it cannot access the 'config' plugin.
Bootstrap all the restart scripts to avoid such issues.

Fixes: https://fedorahosted.org/freeipa/ticket/5968
---
 install/restart_scripts/renew_ca_cert  | 2 +-
 install/restart_scripts/renew_ra_cert  | 2 +-
 install/restart_scripts/restart_dirsrv | 2 +-
 install/restart_scripts/stop_pkicad| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/install/restart_scripts/renew_ca_cert 
b/install/restart_scripts/renew_ca_cert
index 
bfb726cddf1b747f01512a85408fd479427ced44..dc0f1117b366e3fdcf6d00f0e6d928e2e32b8f2b
 100644
--- a/install/restart_scripts/renew_ca_cert
+++ b/install/restart_scripts/renew_ca_cert
@@ -38,7 +38,7 @@ from ipaplatform.paths import paths
 def _main():
 nickname = sys.argv[1]
 
-api.bootstrap(context='restart')
+api.bootstrap(in_server=True, context='restart')
 api.finalize()
 
 dogtag_service = services.knownservices['pki_tomcatd']
diff --git a/install/restart_scripts/renew_ra_cert 
b/install/restart_scripts/renew_ra_cert
index 
9b5e231b526432bec3e6d187a674042a27b94b57..17a7af9b079ea6d91fc60fac2bcc65d8ec7d8bc0
 100644
--- a/install/restart_scripts/renew_ra_cert
+++ b/install/restart_scripts/renew_ra_cert
@@ -37,7 +37,7 @@ from ipaplatform.paths import paths
 def _main():
 nickname = 'ipaCert'
 
-api.bootstrap(context='restart')
+api.bootstrap(in_server=True, context='restart')
 api.finalize()
 
 tmpdir = tempfile.mkdtemp(prefix="tmp-")
diff --git a/install/restart_scripts/restart_dirsrv 
b/install/restart_scripts/restart_dirsrv
index 
856729b5cd8dcfe7885a6ccf64aa847e6379102c..a8e78184f9a6f595a11440fbddae3c41933bb29b
 100644
--- a/install/restart_scripts/restart_dirsrv
+++ b/install/restart_scripts/restart_dirsrv
@@ -33,7 +33,7 @@ def _main():
 except IndexError:
 instance = ""
 
-api.bootstrap(context='restart')
+api.bootstrap(in_server=True, context='restart')
 api.finalize()
 
 syslog.syslog(syslog.LOG_NOTICE, "certmonger restarted dirsrv instance 
'%s'" % instance)
diff --git a/install/restart_scripts/stop_pkicad 
b/install/restart_scripts/stop_pkicad
index 
30b99eeff80b42aedbada583df37f9fddb076aec..ae07dcd588a54bbb1328b289c9218d2053f32c0b
 100644
--- a/install/restart_scripts/stop_pkicad
+++ b/install/restart_scripts/stop_pkicad
@@ -27,7 +27,7 @@ from ipaserver.install import certs
 
 
 def main():
-api.bootstrap(context='restart')
+api.bootstrap(in_server=True, context='restart')
 api.finalize()
 
 dogtag_service = services.knownservices['pki_tomcatd']
-- 
2.5.5

-- 
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 0048] Remove sys.exit() from installer modules

2016-06-16 Thread Petr Spacek 
On 17.6.2016 08:43, Stanislav Laznicka wrote:
> On 06/17/2016 07:45 AM, Petr Spacek wrote:
>> On 16.6.2016 17:33, Stanislav Laznicka wrote:
>>> Hello,
>>>
>>> This patch removes most sys.exits() from installer modules and scripts and
>>> replaces them with ScriptError. I only left sys.exits at places where the 
>>> user
>>> decides yes/no on continuation of the script.
>> I wonder if yes/no should be replaced with KeyboardInterrupt or some other
>> exception, too...
>>
> I'm not sure, it seems more clear to just really exit if the user desires it
> and it's what we say we'll do (with possible cleanup beforehand). Do you think
> we could benefit somehow by raising an exception here?

I'm just thinking out loud.

It seemed to me that it is easier to share cleanup on one except block instead
of having if (interrupt): cleanup; if (interrupt2): same_cleanup;

etc.

Again, just wondering out loud.

-- 
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 0503-0513, 0515-0519, 0520-0528] DNS locations

2016-06-16 Thread Petr Spacek 
On 16.6.2016 22:14, Martin Basti wrote:
> 
> 
> On 16.06.2016 15:59, Petr Spacek wrote:
>> On 16.6.2016 13:57, Martin Basti wrote:
>>>
>>> On 16.06.2016 12:09, Petr Spacek wrote:
 On 15.6.2016 17:24, Petr Spacek wrote:
> On 15.6.2016 15:45, Martin Basti wrote:
>> On 15.06.2016 14:52, Martin Basti wrote:
>>> 
>>> Hydra patching: Updated patches attached + new patches for dnsserver-*
>>> commands attached
>>> Updated+rebased patches after Honza's interactive review
>>>
>>>
>> Minor nitpick fixed
>>
>>
>>
> freeipa-mbasti-0503.3-DNS-Locations-add-index-for-ipalocation-attribute.patch
>
> ACK
>
> freeipa-mbasti-0505.3-DNS-Locations-add-idnsTemplateObject-objectclass.patch
> ACK
>
>
> I will get to the rest later on.
 Problems I found (could be solved in separate patches if you wish):

 1. NACK
 # ipa dns-update-system-records --dry-run
 ipa: ERROR: an internal error has occurred
 ValueError: dns_update_system_records.validate_output(): unexpected keys
 ['summary'] in { ...
>>> Fixed
 2. NACK
 Command ipa dns-update-system-records does not work with DNS Administrators
 privilege when some record is missing:

 ipa: WARNING: Update of system record
 '_kpasswd._tcp.dom-046.abc.idm.lab.eng.brq.redhat.com. 86400 IN SRV 0 100 
 464
 vm-046.abc.idm.lab.eng.brq.redhat.com.' failed with error: Insufficient
 access: Insufficient 'write' privilege to the 'objectClass' attribute of
 entry
 'idnsname=_kpasswd._tcp,idnsname=dom-046.abc.idm.lab.eng.brq.redhat.com.,cn=dns,dc=suffix'.


>>> Fixed (I hope)
 3. NACK
 IPA server upgrade does not create idnsServerConfigObjects in cn=dns
 In fact the upgrade does not even add the object class into schema.

>>> Fixed
 These needs to be fixed before we can proceed.

>>> Updated patches attached
>> 4. NACK
>> ipa-ca-install does not add A/ records for the new CA.
> This should work, code is on the right place. Maybe it is a race condition.
> 
> ... 2 hours later ...
> 
> I found that this is broken since 4.3.0, I will fix it separately
> https://fedorahosted.org/freeipa/ticket/5966
> 
> Anyway I found bug in replicainstall (fixed) because copy&paste everywhere
> 
>>
>> 5. NACK
>> ipa-replica-manage del  does not delete SRV records from the
>> remaining master
>>
>> # ipa-replica-manage del vm-046.abc.idm.lab.eng.brq.redhat.com
>> WARNING: yacc table file version is out of date
>> Checking connectivity in topology suffix 'domain'
>> Checking connectivity in topology suffix 'ca'
>> Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com entries: invalid
>> 'idnsserverid': must be Unicode text
>> You may need to manually remove them from the tree
>> Checking for deleted segments in suffix 'domain'
>> Agreements deleted
>> Checking for deleted segments in suffix 'ca'
>> Agreements deleted
>> Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com DNS entries:
>> abc.idm.lab.eng.brq.redhat.com.: DNS zone not found
>> You may need to manually remove them from the tree
> Fixed
>>
>> Manual execution of ipa dns-update-system-records fixes that.
>>
>>
>>
>> Besides NACKs above one more thing is missing:
>> Following config options are not migrated from named.conf to LDAP object:
>>
>> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/PerServerConfigInLDAP#Upgrade
>>
>>
>> This can go to a separate patch set if you wish (at the very end).
> I will leave this for later, bind-dyndb-ldap will continue working with local
> configuration as before, patches are of course welcome.
> 
> Updated patches attached, + hydra patching

6. NACK
# ipa server-show $(hostname)
Managed suffixes: domain, ca
  Min domain level: 0
  Max domain level: 1
  Location: l1
  Enabled server roles: CA server, DNS server, NTP server
  Server name: vm-046.abc.idm.lab.eng.brq.redhat.com

[root@vm-046 review]# ipa server-mod $(hostname) --location=l2
ipa: ERROR: no modifications to be performed

-- 
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 0048] Remove sys.exit() from installer modules

2016-06-16 Thread Stanislav Laznicka 

On 06/17/2016 07:45 AM, Petr Spacek wrote:

On 16.6.2016 17:33, Stanislav Laznicka wrote:

Hello,

This patch removes most sys.exits() from installer modules and scripts and
replaces them with ScriptError. I only left sys.exits at places where the user
decides yes/no on continuation of the script.

I wonder if yes/no should be replaced with KeyboardInterrupt or some other
exception, too...

I'm not sure, it seems more clear to just really exit if the user 
desires it and it's what we say we'll do (with possible cleanup 
beforehand). Do you think we could benefit somehow by raising an 
exception here?


--
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] 0069 renew_ca_cert: bootstrap api with in_server=True

2016-06-16 Thread Jan Cholasta 

Hi,

On 17.6.2016 06:55, Fraser Tweedale wrote:

Attached patch fixes https://fedorahosted.org/freeipa/ticket/5968


This should be fixed for all the restart scripts, not just renew_ca_cert.



Thanks,
Fraser


Honza

--
Jan Cholasta

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

Re: [Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules

2016-06-16 Thread Petr Spacek 
On 16.6.2016 17:33, Stanislav Laznicka wrote:
> Hello,
> 
> This patch removes most sys.exits() from installer modules and scripts and
> replaces them with ScriptError. I only left sys.exits at places where the user
> decides yes/no on continuation of the script.

I wonder if yes/no should be replaced with KeyboardInterrupt or some other
exception, too...

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

[Freeipa-devel] [PATCH] 0069 renew_ca_cert: bootstrap api with in_server=True

2016-06-16 Thread Fraser Tweedale 
Attached patch fixes https://fedorahosted.org/freeipa/ticket/5968

Thanks,
Fraser
From 47ddd811f37fc026c296dd6c2fd44be606ba5a75 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Fri, 17 Jun 2016 14:18:05 +1000
Subject: [PATCH] renew_ca_cert: bootstrap api with in_server=True

renew_ca_cert is failing because it cannot access the 'config'
plugin.  Bootstrap with in_server=True to remedy.

Fixes: https://fedorahosted.org/freeipa/ticket/5968
---
 install/restart_scripts/renew_ca_cert | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/install/restart_scripts/renew_ca_cert 
b/install/restart_scripts/renew_ca_cert
index 
bfb726cddf1b747f01512a85408fd479427ced44..dc0f1117b366e3fdcf6d00f0e6d928e2e32b8f2b
 100644
--- a/install/restart_scripts/renew_ca_cert
+++ b/install/restart_scripts/renew_ca_cert
@@ -38,7 +38,7 @@ from ipaplatform.paths import paths
 def _main():
 nickname = sys.argv[1]
 
-api.bootstrap(context='restart')
+api.bootstrap(in_server=True, context='restart')
 api.finalize()
 
 dogtag_service = services.knownservices['pki_tomcatd']
-- 
2.5.5

-- 
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

2016-06-16 Thread Ben Lipton 

On 06/14/2016 08:27 AM, Ben Lipton wrote:

Hello all,

I have written up a design proposal for making certificate requests 
easier to generate when using alternate certificate profiles: 
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. 
The use case for this is described in 
https://fedorahosted.org/freeipa/ticket/4899. I will be working on 
implementing this design over the next couple of months. If you have 
the time and interest, please take a look and share any comments or 
concerns that you have.


Thanks!

Ben

Just a quick update to say that I've created a new document that covers 
the proposed schema additions in a more descriptive way (with diagrams!) 
I'm very new to developing with LDAP, so some more experienced eyes on 
the proposal would be very helpful, even if you don't have time to 
absorb the full design. Please take a look at 
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema 
if you have a chance.


Thanks,
Ben

--
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Alexander Bokovoy 

On Thu, 16 Jun 2016, Lukas Slebodnik wrote:

On (16/06/16 12:00), Petr Spacek wrote:

Hello,

Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html

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

--
Petr^2 Spacek



From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Thu, 16 Jun 2016 11:58:56 +0200
Subject: [PATCH] Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html

https://fedorahosted.org/freeipa/ticket/2008
---
freeipa.spec.in | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 
d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f
 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz
BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

%if ! %{ONLY_CLIENT}
-BuildRequires:  389-ds-base-devel >= 1.3.5
+BuildRequires:  389-ds-base-devel >= 1.3.5.6

I know that patch was pushed and it fixed your problem.
but I am little bit curious why did you need to change
version in BuildRequires?

If I understand correctly FreeIPA complies well with 1.3.5.
The only problem was at runtime.

We actually need 1.3.5.6 for slapi-nis and pwd extop plugins to build as
we are using all new pre-extop operation callback.
--
/ 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] 0019 - 2 ipapwd_extop should take precedence over default DS plugin

2016-06-16 Thread Alexander Bokovoy 

On Thu, 16 Jun 2016, thierry bordaz wrote:
The version DS 1.3.5.6 is now available. Here is the second version of 
the patch taking into account lower precedence for Schema Compat




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

On Mon, 13 Jun 2016, thierry bordaz wrote:



On 06/13/2016 04:57 PM, Alexander Bokovoy wrote:

On Mon, 13 Jun 2016, thierry bordaz wrote:

This is the fix for https://fedorahosted.org/freeipa/ticket/5944


From 2838fbfc7a22b9bc0c1c4dfaf3660d1ac7099461 Mon Sep 17 
00:00:00 2001

From: Thierry Bordaz 
Date: Wed, 8 Jun 2016 14:03:42 +0200
Subject: [PATCH] Make sure ipapwd_extop takes precedence over
passwd_modify_extop

DS core server provides a default plugin (passwd_modify_extop) 
to handle
1.3.6.1.4.1.4203.1.11.1 extended op 
(https://www.ietf.org/rfc/rfc3062.txt)


IPA delivers ipa_pwd_extop plugin that should take precedence over
the default DS plugin (passwd_modify_extop)
---
install/updates/10-ipapwd.update | 9 +
1 file changed, 9 insertions(+)
create mode 100644 install/updates/10-ipapwd.update

diff --git a/install/updates/10-ipapwd.update 
b/install/updates/10-ipapwd.update

new file mode 100644
index 000..d9bffa2
--- /dev/null
+++ b/install/updates/10-ipapwd.update
@@ -0,0 +1,9 @@
+dn: cn=ipa_pwd_extop,cn=plugins,cn=config
+# DS core server provides a default plugin 
(passwd_modify_extop) to handle
+# 1.3.6.1.4.1.4203.1.11.1 extended op 
(https://www.ietf.org/rfc/rfc3062.txt)
+# the pluginprecedence of the passwd_modify_extop is 50 
(default value)

+#
+# IPA delivers ipa_pwd_extop plugin to handle that extended op
+# we need to make sure ipa_pwd_extop is called and so to set a lower
+# precedence value
+add:nsslapd-pluginprecedence: 49

Here is the problem: slapi-nis is 49 as well and it should be before
ipa_pwd_extop.

You need to update install/share/schema_compat.uldif and
install/updates/10-schema_compat.update to get slapi-nis before
ipa_pwd_extop.
ipapwd_plugin registers extendedop callback but slapi-nis does 
not. So I do not think they will "fight" for precedence.
Even if slapi-nis register perextendedop they will be on different 
lists and it should not create any issue.


Now I understand that slapi-nis must run with a precedence that 
should be lower than most of the others plugins. Currently it is 
49, are you ok with a value like 40 ?

I'm OK with 40, yes. The precedence applies to all callbacks, not just
to preextendedop, so a BIND callback would be affected too.


You also need to make sure we depend on the updated 389-ds-base package
version.


Good !
Now with this dependency we should wait for 389-ds 1.3.5.5 to be 
available, I will resend the review when it will be available.

Yep, thanks.






From 81af4f17deca1814851429a054804b5bc9f63491 Mon Sep 17 00:00:00 2001
From: Thierry Bordaz 
Date: Thu, 16 Jun 2016 16:28:03 +0200
Subject: [PATCH] Make sure ipapwd_extop takes precedence over
passwd_modify_extop

DS core server provides a default plugin (passwd_modify_extop) to handle
1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt)

IPA delivers ipa_pwd_extop plugin that should take precedence over
the default DS plugin (passwd_modify_extop)

In addition make sure that slapi-nis has a low precedence
---
install/share/schema_compat.uldif   | 2 +-
install/updates/10-ipapwd.update| 9 +
install/updates/10-schema_compat.update | 2 +-
3 files changed, 11 insertions(+), 2 deletions(-)
create mode 100644 install/updates/10-ipapwd.update

diff --git a/install/share/schema_compat.uldif 
b/install/share/schema_compat.uldif
index a3d412f..66f8ea1 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -16,7 +16,7 @@ default:nsslapd-pluginid: schema-compat-plugin
# We need to run schema-compat pre-bind callback before
# other IPA pre-bind callbacks to make sure bind DN is
# rewritten to the original entry if needed
-default:nsslapd-pluginprecedence: 49
+default:nsslapd-pluginprecedence: 40
default:nsslapd-pluginversion: 0.8
default:nsslapd-pluginbetxn: on
default:nsslapd-pluginvendor: redhat.com
diff --git a/install/updates/10-ipapwd.update b/install/updates/10-ipapwd.update
new file mode 100644
index 000..d9bffa2
--- /dev/null
+++ b/install/updates/10-ipapwd.update
@@ -0,0 +1,9 @@
+dn: cn=ipa_pwd_extop,cn=plugins,cn=config
+# DS core server provides a default plugin (passwd_modify_extop) to handle
+# 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt)
+# the pluginprecedence of the passwd_modify_extop is 50 (default value)
+#
+# IPA delivers ipa_pwd_extop plugin to handle that extended op
+# we need to make sure ipa_pwd_extop is called and so to set a lower
+# precedence value
+add:nsslapd-pluginprecedence: 49
diff --git a/install/updates/10-schema_compat.update 
b/install/updates/10-schema_compat.update
index 2d257a3..e4c257d 100644
--- a/install/updates/10-schema_compat.update
+++ b/install/updates/10-schema_compat.update
@@ -74,7 +74,7 @@ dn: cn=S

[Freeipa-devel] [PATCH 0048] Remove sys.exit() from installer modules

2016-06-16 Thread Stanislav Laznicka 

Hello,

This patch removes most sys.exits() from installer modules and scripts 
and replaces them with ScriptError. I only left sys.exits at places 
where the user decides yes/no on continuation of the script.


From 7968f068141e53f7bf111221b38c40cac432 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Thu, 16 Jun 2016 17:12:24 +0200
Subject: [PATCH] Remove sys.exit from install modules and scripts

sys.exit() calls sometimes make it hard to find bugs and mask code that
does not always work properly.

https://fedorahosted.org/freeipa/ticket/5750
---
 install/tools/ipa-adtrust-install  | 17 +++---
 install/tools/ipa-ca-install   | 23 
 install/tools/ipa-compat-manage| 11 ++--
 install/tools/ipa-dns-install  |  3 +-
 ipaserver/install/bindinstance.py  |  2 +-
 ipaserver/install/ca.py| 19 +++---
 ipaserver/install/cainstance.py|  5 +-
 ipaserver/install/dns.py   |  5 +-
 ipaserver/install/dsinstance.py|  3 +-
 ipaserver/install/installutils.py  | 16 +++---
 ipaserver/install/ipa_ldap_updater.py  |  2 +-
 ipaserver/install/krainstance.py   |  3 +-
 ipaserver/install/replication.py   | 10 ++--
 ipaserver/install/server/install.py| 64 +++--
 ipaserver/install/server/replicainstall.py | 92 --
 15 files changed, 147 insertions(+), 128 deletions(-)

diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install
index 36caa5c2d429c6cf107df03e82aa80e15d8efe01..da635cb02c3c8affb234515dd64f2cb06e9ea872 100755
--- a/install/tools/ipa-adtrust-install
+++ b/install/tools/ipa-adtrust-install
@@ -37,6 +37,7 @@ from ipaserver.install.installutils import (
 from ipaserver.install import service
 from ipapython import version
 from ipapython import ipautil, sysrestore, ipaldap
+from ipapython.admintool import ScriptError
 from ipalib import api, errors, krb_utils
 from ipapython.config import IPAOptionParser
 from ipaplatform.paths import paths
@@ -192,7 +193,7 @@ def set_and_check_netbios_name(netbios_name, unattended):
 if not adtrustinstance.check_netbios_name(netbios_name):
 if unattended and not gen_netbios_name:
 netbios_name_error(netbios_name)
-sys.exit("Aborting installation.")
+raise ScriptError("Aborting installation.")
 else:
 if netbios_name:
 netbios_name_error(netbios_name)
@@ -227,7 +228,7 @@ def main():
 safe_options, options = parse_options()
 
 if os.getegid() != 0:
-sys.exit("Must be root to setup AD trusts on server")
+raise ScriptError("Must be root to setup AD trusts on server")
 
 standard_logging_setup(log_file_name, debug=options.debug, filemode='a')
 print("\nThe log file for this installation can be found in %s" % log_file_name)
@@ -255,7 +256,7 @@ def main():
 
 # Check if samba packages are installed
 if not adtrustinstance.check_inst():
-sys.exit("Aborting installation.")
+raise ScriptError("Aborting installation.")
 
 # Initialize the ipalib api
 cfg = dict(
@@ -318,14 +319,14 @@ def main():
 try:
 principal = krb_utils.get_principal()
 except errors.CCacheError as e:
-sys.exit("Must have Kerberos credentials to setup AD trusts on server: %s" % e.message)
+raise ScriptError("Must have Kerberos credentials to setup AD trusts on server: %s" % e.message)
 
 try:
 api.Backend.ldap2.connect()
 except errors.ACIError as e:
-sys.exit("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket")
+raise ScriptError("Outdated Kerberos credentials. Use kdestroy and kinit to update your ticket")
 except errors.DatabaseError as e:
-sys.exit("Cannot connect to the LDAP database. Please check if IPA is running")
+raise ScriptError("Cannot connect to the LDAP database. Please check if IPA is running")
 
 try:
 user = api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result']
@@ -334,9 +335,9 @@ def main():
 group['cn'][0] in user['memberof_group']):
 raise errors.RequirementError(name='admins group membership')
 except errors.RequirementError as e:
-sys.exit("Must have administrative privileges to setup AD trusts on server")
+raise ScriptError("Must have administrative privileges to setup AD trusts on server")
 except Exception as e:
-sys.exit("Unrecognized error during check of admin rights: %s" % (str(e)))
+raise ScriptError("Unrecognized error during check of admin rights: %s" % (str(e)))
 
 (netbios_name, reset_netbios_name) = \
 set_and_check_netbios_name(options.netbios_name,
diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index 1bc5def03bf687a1e4f9fb38a54363b5429c8fc4..3a863

[Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964

2016-06-16 Thread Oleg Fayans 

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
From debac0cf5cb24e1c2072d10373f4d9f72cb875a7 Mon Sep 17 00:00:00 2001
From: Oleg Fayans 
Date: Thu, 16 Jun 2016 16:45:03 +0200
Subject: [PATCH] Automated clean-ruv subcommand test

https://fedorahosted.org/freeipa/ticket/5964
---
 ipatests/test_integration/test_topology.py | 51 ++
 1 file changed, 51 insertions(+)

diff --git a/ipatests/test_integration/test_topology.py b/ipatests/test_integration/test_topology.py
index e956563c27eafd84deed5786274a73d0d3594642..849ee12267b2f0412dee189440c2fe7bd0cdec85 100644
--- a/ipatests/test_integration/test_topology.py
+++ b/ipatests/test_integration/test_topology.py
@@ -159,3 +159,54 @@ class TestTopologyOptions(IntegrationTest):
 assert err == "", err
 returncode, error = tasks.destroy_segment(self.master, "%s-to-%s" % replicas)
 assert returncode == 0, error
+
+
+@pytest.mark.skipif(config.domain_level == 0, reason=reasoning)
+class TestCASpecificRUVs(IntegrationTest):
+num_replicas = 1
+topology = 'star'
+username = 'testuser'
+user_firstname = 'test'
+user_lastname = 'user'
+
+def test_ca_specific_ruvs(self):
+"""
+http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan
+#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended
+_to_handle_CA-specific_RUVs
+"""
+replica = self.replicas[0]
+master = self.master
+result1 = master.run_command(['ipa-replica-manage', 'list-ruv',
+  '-p', master.config.dirman_password])
+assert(result1.stdout_text.count(replica.hostname) == 2 and
+   "Certificate Server Replica Update Vectors" in result1.stdout_text), (
+"CA-specific RUVs are not displayed")
+ruvid_re = re.compile(".*%s:389: (\d+).*" % replica)
+replica_ruv_ids = ruvid_re.findall(result1.stdout_text)
+result2 = master.run_command(['ipa-replica-manage', 'clean-ruv',
+  replica_ruv_ids[1], '-p',
+  master.config.dirman_password, '-f'])
+assert(replica.hostname in result2.stdout_text), (
+"The wrong RUV was deleted")
+result3 = master.run_command(['ipa-replica-manage', 'list-ruv',
+  '-p', master.config.dirman_password])
+assert(result3.stdout_text.count(replica.hostname) == 1), (
+"CA RUV of the replica is still displayed")
+result4 = master.run_command(['ipa-replica-manage', 'clean-ruv',
+  replica_ruv_ids[0], '-p',
+  master.config.dirman_password, '-f'])
+assert(replica.hostname in result4.stdout_text), (
+"The wrong RUV was deleted")
+result5 = master.run_command(['ipa-replica-manage', 'list-ruv',
+  '-p', master.config.dirman_password])
+assert(replica.hostname not in result5.stdout_text), (
+"replica's RUV is still displayed")
+tasks.kinit_admin(master)
+master.run_command(['ipa', 'user-add', self.username,
+"--first=%s" % self.user_firstname,
+"--last=%s" % self.user_lastname])
+result6 = replica.run_command(['ipa', 'user-show', self.username],
+  raiseonerr=False)
+assert(result6.returncode > 0), (
+'Replication still works after all RUVs were deleted')
-- 
1.8.3.1

-- 
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] 0019 - 2 ipapwd_extop should take precedence over default DS plugin

2016-06-16 Thread thierry bordaz 
The version DS 1.3.5.6 is now available. Here is the second version of 
the patch taking into account lower precedence for Schema Compat




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

On Mon, 13 Jun 2016, thierry bordaz wrote:



On 06/13/2016 04:57 PM, Alexander Bokovoy wrote:

On Mon, 13 Jun 2016, thierry bordaz wrote:

This is the fix for https://fedorahosted.org/freeipa/ticket/5944


From 2838fbfc7a22b9bc0c1c4dfaf3660d1ac7099461 Mon Sep 17 00:00:00 
2001

From: Thierry Bordaz 
Date: Wed, 8 Jun 2016 14:03:42 +0200
Subject: [PATCH] Make sure ipapwd_extop takes precedence over
passwd_modify_extop

DS core server provides a default plugin (passwd_modify_extop) to 
handle
1.3.6.1.4.1.4203.1.11.1 extended op 
(https://www.ietf.org/rfc/rfc3062.txt)


IPA delivers ipa_pwd_extop plugin that should take precedence over
the default DS plugin (passwd_modify_extop)
---
install/updates/10-ipapwd.update | 9 +
1 file changed, 9 insertions(+)
create mode 100644 install/updates/10-ipapwd.update

diff --git a/install/updates/10-ipapwd.update 
b/install/updates/10-ipapwd.update

new file mode 100644
index 000..d9bffa2
--- /dev/null
+++ b/install/updates/10-ipapwd.update
@@ -0,0 +1,9 @@
+dn: cn=ipa_pwd_extop,cn=plugins,cn=config
+# DS core server provides a default plugin (passwd_modify_extop) 
to handle
+# 1.3.6.1.4.1.4203.1.11.1 extended op 
(https://www.ietf.org/rfc/rfc3062.txt)
+# the pluginprecedence of the passwd_modify_extop is 50 (default 
value)

+#
+# IPA delivers ipa_pwd_extop plugin to handle that extended op
+# we need to make sure ipa_pwd_extop is called and so to set a lower
+# precedence value
+add:nsslapd-pluginprecedence: 49

Here is the problem: slapi-nis is 49 as well and it should be before
ipa_pwd_extop.

You need to update install/share/schema_compat.uldif and
install/updates/10-schema_compat.update to get slapi-nis before
ipa_pwd_extop.
ipapwd_plugin registers extendedop callback but slapi-nis does not. 
So I do not think they will "fight" for precedence.
Even if slapi-nis register perextendedop they will be on different 
lists and it should not create any issue.


Now I understand that slapi-nis must run with a precedence that 
should be lower than most of the others plugins. Currently it is 49, 
are you ok with a value like 40 ?

I'm OK with 40, yes. The precedence applies to all callbacks, not just
to preextendedop, so a BIND callback would be affected too.


You also need to make sure we depend on the updated 389-ds-base package
version.


Good !
Now with this dependency we should wait for 389-ds 1.3.5.5 to be 
available, I will resend the review when it will be available.

Yep, thanks.



>From 81af4f17deca1814851429a054804b5bc9f63491 Mon Sep 17 00:00:00 2001
From: Thierry Bordaz 
Date: Thu, 16 Jun 2016 16:28:03 +0200
Subject: [PATCH] Make sure ipapwd_extop takes precedence over
 passwd_modify_extop

DS core server provides a default plugin (passwd_modify_extop) to handle
1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt)

IPA delivers ipa_pwd_extop plugin that should take precedence over
the default DS plugin (passwd_modify_extop)

In addition make sure that slapi-nis has a low precedence
---
 install/share/schema_compat.uldif   | 2 +-
 install/updates/10-ipapwd.update| 9 +
 install/updates/10-schema_compat.update | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 install/updates/10-ipapwd.update

diff --git a/install/share/schema_compat.uldif b/install/share/schema_compat.uldif
index a3d412f..66f8ea1 100644
--- a/install/share/schema_compat.uldif
+++ b/install/share/schema_compat.uldif
@@ -16,7 +16,7 @@ default:nsslapd-pluginid: schema-compat-plugin
 # We need to run schema-compat pre-bind callback before
 # other IPA pre-bind callbacks to make sure bind DN is
 # rewritten to the original entry if needed
-default:nsslapd-pluginprecedence: 49
+default:nsslapd-pluginprecedence: 40
 default:nsslapd-pluginversion: 0.8
 default:nsslapd-pluginbetxn: on
 default:nsslapd-pluginvendor: redhat.com
diff --git a/install/updates/10-ipapwd.update b/install/updates/10-ipapwd.update
new file mode 100644
index 000..d9bffa2
--- /dev/null
+++ b/install/updates/10-ipapwd.update
@@ -0,0 +1,9 @@
+dn: cn=ipa_pwd_extop,cn=plugins,cn=config
+# DS core server provides a default plugin (passwd_modify_extop) to handle
+# 1.3.6.1.4.1.4203.1.11.1 extended op (https://www.ietf.org/rfc/rfc3062.txt)
+# the pluginprecedence of the passwd_modify_extop is 50 (default value)
+#
+# IPA delivers ipa_pwd_extop plugin to handle that extended op
+# we need to make sure ipa_pwd_extop is called and so to set a lower
+# precedence value
+add:nsslapd-pluginprecedence: 49
diff --git a/install/updates/10-schema_compat.update b/install/updates/10-schema_compat.update
index 2d257a3..e4c257d 100644
--- a/install/updates/10-schema_compat.update
+++ b/install/updates/10-schema_compat.update
@@ -74,7 +74,7 @@ dn: cn=Schema Compatibility,cn=plugins,cn=co

[Freeipa-devel] [PATCH] 497 Update Developers in Contributors.txt

2016-06-16 Thread Martin Kosek 
Since we are close to 4.4 release, let's add the latest contributors. (master
branch should be enough).

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.
From 2f3b4706fbdf4319a54ef679042cdf1b156787b5 Mon Sep 17 00:00:00 2001
From: Martin Kosek 
Date: Thu, 16 Jun 2016 15:49:16 +0200
Subject: [PATCH] Update Developers in Contributors.txt

Add the most recent development contributors to FreeIPA.
---
 Contributors.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Contributors.txt b/Contributors.txt
index 8858724fab4febf01e19d8660786c10ddcc7a3b6..71be27da5ab415deb11589d5bf82d684b2d85f9a 100644
--- a/Contributors.txt
+++ b/Contributors.txt
@@ -12,6 +12,7 @@ Developers:
 	Kyle Baker
 	Martin Bašti
 	Sylvain Baubeau
+	Florence Blanc-Renaud
 	Alexander Bokovoy
 	Thierry Bordaz
 	Sumit Bose
@@ -30,9 +31,12 @@ Developers:
 	Endi Sukma Dewata
 	Lenka Doudova
 	Benjamin Drung
+	Patrice Duc-Jacquet
 	Drew Erny
 	Oleg Fayans
+	Jérôme Fenal
 	Stephen Gallagher
+	James Groffen
 	Ondřej Hamada
 	Nick Hatch
 	Christian Heimes
@@ -48,6 +52,7 @@ Developers:
 	Ian Kumlien
 	David Kupka
 	Robert Kuska
+	Peter Lacko
 	Stanislav Laznicka
 	Ade Lee
 	Karl MacMillan
@@ -70,12 +75,14 @@ Developers:
 	W. Michael Petullo
 	Gowrishankar Rajaiyan
 	Lubomír Rintel
+	Matt Rogers
 	Lynn Root
 	Pete Rowley
 	Lenka Ryznarova
 	Thorsten Scherf
 	Michael Simacek
 	Lars Sjostrom
+	Filip Skola
 	Lukáš Slebodník
 	Simo Sorce
 	Petr Špaček
@@ -84,6 +91,7 @@ Developers:
 	Fraser Tweedale
 	Petr Viktorin
 	Petr Voborník
+	Pavel Vomacka
 	Andrew Wnuk
 	Jason Woods
 	Adam Young
-- 
2.5.5

-- 
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Petr Spacek 
On 16.6.2016 15:58, Lukas Slebodnik wrote:
> On (16/06/16 12:00), Petr Spacek wrote:
>> Hello,
>>
>> Require 389-ds-base >= 1.3.5.6
>>
>> Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
>> See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html
>>
>> https://fedorahosted.org/freeipa/ticket/2008
>>
>> -- 
>> Petr^2 Spacek
> 
>>From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001
>> From: Petr Spacek 
>> Date: Thu, 16 Jun 2016 11:58:56 +0200
>> Subject: [PATCH] Require 389-ds-base >= 1.3.5.6
>>
>> Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
>> See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html
>>
>> https://fedorahosted.org/freeipa/ticket/2008
>> ---
>> freeipa.spec.in | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/freeipa.spec.in b/freeipa.spec.in
>> index 
>> d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f
>>  100644
>> --- a/freeipa.spec.in
>> +++ b/freeipa.spec.in
>> @@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz
>> BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} 
>> -n)
>>
>> %if ! %{ONLY_CLIENT}
>> -BuildRequires:  389-ds-base-devel >= 1.3.5
>> +BuildRequires:  389-ds-base-devel >= 1.3.5.6
> I know that patch was pushed and it fixed your problem.
> but I am little bit curious why did you need to change
> version in BuildRequires?
> 
> If I understand correctly FreeIPA complies well with 1.3.5.
> The only problem was at runtime.

Right, I did not bother to test it. Feel free to submit correcting patch.

-- 
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 0503-0513, 0515-0519] DNS locations

2016-06-16 Thread Petr Spacek 
On 16.6.2016 13:57, Martin Basti wrote:
> 
> 
> On 16.06.2016 12:09, Petr Spacek wrote:
>> On 15.6.2016 17:24, Petr Spacek wrote:
>>> On 15.6.2016 15:45, Martin Basti wrote:

 On 15.06.2016 14:52, Martin Basti wrote:
> 
> Hydra patching: Updated patches attached + new patches for dnsserver-*
> commands attached
>>
> Updated+rebased patches after Honza's interactive review
>
>
 Minor nitpick fixed



>>> freeipa-mbasti-0503.3-DNS-Locations-add-index-for-ipalocation-attribute.patch
>>> ACK
>>>
>>> freeipa-mbasti-0505.3-DNS-Locations-add-idnsTemplateObject-objectclass.patch
>>> ACK
>>>
>>>
>>> I will get to the rest later on.
>>
>> Problems I found (could be solved in separate patches if you wish):
>>
>> 1. NACK
>> # ipa dns-update-system-records --dry-run
>> ipa: ERROR: an internal error has occurred
>> ValueError: dns_update_system_records.validate_output(): unexpected keys
>> ['summary'] in { ...
> Fixed
>>
>> 2. NACK
>> Command ipa dns-update-system-records does not work with DNS Administrators
>> privilege when some record is missing:
>>
>> ipa: WARNING: Update of system record
>> '_kpasswd._tcp.dom-046.abc.idm.lab.eng.brq.redhat.com. 86400 IN SRV 0 100 464
>> vm-046.abc.idm.lab.eng.brq.redhat.com.' failed with error: Insufficient
>> access: Insufficient 'write' privilege to the 'objectClass' attribute of 
>> entry
>> 'idnsname=_kpasswd._tcp,idnsname=dom-046.abc.idm.lab.eng.brq.redhat.com.,cn=dns,dc=suffix'.
>>
> Fixed (I hope)
>> 3. NACK
>> IPA server upgrade does not create idnsServerConfigObjects in cn=dns
>> In fact the upgrade does not even add the object class into schema.
>>
> Fixed
>> These needs to be fixed before we can proceed.
>>
> Updated patches attached

4. NACK
ipa-ca-install does not add A/ records for the new CA.


5. NACK
ipa-replica-manage del  does not delete SRV records from the
remaining master

# ipa-replica-manage del vm-046.abc.idm.lab.eng.brq.redhat.com
WARNING: yacc table file version is out of date
Checking connectivity in topology suffix 'domain'
Checking connectivity in topology suffix 'ca'
Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com entries: invalid
'idnsserverid': must be Unicode text
You may need to manually remove them from the tree
Checking for deleted segments in suffix 'domain'
Agreements deleted
Checking for deleted segments in suffix 'ca'
Agreements deleted
Failed to cleanup vm-046.abc.idm.lab.eng.brq.redhat.com DNS entries:
abc.idm.lab.eng.brq.redhat.com.: DNS zone not found
You may need to manually remove them from the tree


Manual execution of ipa dns-update-system-records fixes that.



Besides NACKs above one more thing is missing:
Following config options are not migrated from named.conf to LDAP object:

https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/PerServerConfigInLDAP#Upgrade

This can go to a separate patch set if you wish (at the very end).

-- 
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Lukas Slebodnik 
On (16/06/16 12:00), Petr Spacek wrote:
>Hello,
>
>Require 389-ds-base >= 1.3.5.6
>
>Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
>See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html
>
>https://fedorahosted.org/freeipa/ticket/2008
>
>-- 
>Petr^2 Spacek

>From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001
>From: Petr Spacek 
>Date: Thu, 16 Jun 2016 11:58:56 +0200
>Subject: [PATCH] Require 389-ds-base >= 1.3.5.6
>
>Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
>See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html
>
>https://fedorahosted.org/freeipa/ticket/2008
>---
> freeipa.spec.in | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/freeipa.spec.in b/freeipa.spec.in
>index 
>d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f
> 100644
>--- a/freeipa.spec.in
>+++ b/freeipa.spec.in
>@@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz
> BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> 
> %if ! %{ONLY_CLIENT}
>-BuildRequires:  389-ds-base-devel >= 1.3.5
>+BuildRequires:  389-ds-base-devel >= 1.3.5.6
I know that patch was pushed and it fixed your problem.
but I am little bit curious why did you need to change
version in BuildRequires?

If I understand correctly FreeIPA complies well with 1.3.5.
The only problem was at runtime.

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

[Freeipa-devel] [PATCH 0014-0016][Tests] Authentication indicators

2016-06-16 Thread Lenka Doudova 

Hi,

attached are tests for authentication indicators. Please note:

1. newly created service tracker is not exactly complete, list of 
unimplemented methods is in doc. These methods can be filled in when 
existing declarative tests are refactored.


2. patch 0015 depends on 0014, so it should not be pushed without it.


Lenka

From 2dfcc81b979a345dbed2449a5c30ba19fd2025ee Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Wed, 15 Jun 2016 13:40:00 +0200
Subject: [PATCH] Tests: Tracker class for services

Provides basic service tracker, so far for purposes of [1].
Tracker is not complete, some methods will need to be added in case of service test refactoring.

[1] https://fedorahosted.org/freeipa/ticket/433
---
 ipatests/test_xmlrpc/tracker/service_plugin.py | 173 +
 1 file changed, 173 insertions(+)
 create mode 100644 ipatests/test_xmlrpc/tracker/service_plugin.py

diff --git a/ipatests/test_xmlrpc/tracker/service_plugin.py b/ipatests/test_xmlrpc/tracker/service_plugin.py
new file mode 100644
index ..3fdf17ddf9cd7fee7b5af71347b32c41f61cd355
--- /dev/null
+++ b/ipatests/test_xmlrpc/tracker/service_plugin.py
@@ -0,0 +1,173 @@
+# -*- coding: utf-8 -*-
+#
+# Copyright (C) 2016  FreeIPA Contributors see COPYING for license
+#
+
+import six
+
+from ipalib import api
+from ipatests.test_xmlrpc.tracker.base import Tracker
+from ipatests.test_xmlrpc.xmlrpc_test import fuzzy_uuid
+from ipatests.test_xmlrpc import objectclasses
+from ipatests.util import assert_deepequal
+from ipapython.dn import DN
+
+if six.PY3:
+unicode = str
+
+
+class ServiceTracker(Tracker):
+"""
+Tracker class for service plugin
+
+So far does not include methods for these commands:
+service-add-host
+service-remove-host
+service-allow-retrieve-keytab
+service-disallow-retrieve-keytab
+service-allow-create-keytab
+service-disallow-create-keytab
+service-disable
+service-add-cert
+service-remove-cert
+"""
+
+retrieve_keys = {
+u'dn', u'krbprincipalname', u'usercertificate', u'has_keytab',
+u'ipakrbauthzdata', u'ipaallowedtoperform', u'subject',
+u'managedby', u'serial_number', u'serial_number_hex', u'issuer',
+u'valid_not_before', u'valid_not_after', u'md5_fingerprint',
+u'sha1_fingerprint', u'krbprincipalauthind', u'managedby_host'}
+retrieve_all_keys = retrieve_keys | {
+u'ipaKrbPrincipalAlias', u'ipaUniqueID', u'krbExtraData',
+u'krbLastPwdChange', u'krbLoginFailedCount', u'memberof',
+u'objectClass', u'ipakrbrequirespreauth',
+u'ipakrbokasdelegate'}
+
+create_keys = (retrieve_keys | {u'objectclass', u'ipauniqueid'}) - {
+u'usercertificate', u'has_keytab'}
+update_keys = retrieve_keys - {u'dn'}
+
+def __init__(self, name, host_fqdn, options):
+super(ServiceTracker, self).__init__(default_version=None)
+self._name = "{0}/{1}@{2}".format(name, host_fqdn, api.env.realm)
+self.dn = DN(
+('krbprincipalname', self.name), api.env.container_service,
+api.env.basedn)
+self.host_fqdn = host_fqdn
+self.options = options
+
+@property
+def name(self):
+return self._name
+
+def make_create_command(self, force=True):
+""" Make function that creates a service """
+return self.make_command('service_add', self.name,
+ force=force, **self.options)
+
+def make_delete_command(self):
+""" Make function that deletes a service """
+return self.make_command('service_del', self.name)
+
+def make_retrieve_command(self, all=False, raw=False):
+""" Make function that retrieves a service """
+return self.make_command('service_show', self.name, all=all)
+
+def make_find_command(self, *args, **kwargs):
+""" Make function that searches for a service"""
+return self.make_command('service_find', *args, **kwargs)
+
+def make_update_command(self, updates):
+""" Make function that updates a service """
+
+return self.make_command('service_mod', self.name, **updates)
+
+def track_create(self, **options):
+""" Update expected state for service creation """
+self.attrs = {
+u'dn': self.dn,
+u'krbprincipalname': [u'{0}'.format(self.name)],
+u'objectclass': objectclasses.service,
+u'ipauniqueid': [fuzzy_uuid],
+u'managedby_host': [self.host_fqdn],
+}
+
+for key in self.options:
+self.attrs[key] = [self.options[key]]
+
+def check_create(self, result):
+""" Check service-add command result """
+assert_deepequal({
+u'value': u'{0}'.format(self.name),
+u'summary': u'Added service "{0}"'.format(self.name),
+u'result': self.filter_attrs(self.create_keys)
+

Re: [Freeipa-devel] [PATCH 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Martin Basti 



On 16.06.2016 12:21, Ludwig Krispenz wrote:


On 06/16/2016 12:14 PM, Petr Spacek wrote:

On 16.6.2016 12:12, Ludwig Krispenz wrote:

On 06/16/2016 12:00 PM, Petr Spacek wrote:

Hello,

Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly

no. Old DS handles filters strictly as documented in the admin guide,
requiring access rights to each attribute used in the search filter. 
This was
known and applications had to adapt, in your case there would have 
had to be

two searches one with the (&()()) filter and one with (|()()()()).
You know, it is quite hard to adapt when your application rely on one 
SyncRepl

session ...

Anyway, feel free to send patch with rephrased commit message if you 
wish, I'm

okay with superseding my patch with yours.

no, it's fine, only sometimes I need to defend DS a bit


Petr^2 Spacek


This was improved in the latest version and componets withou access are
ignored in filter evaluation to avoid the problems you did run into.

otherwise your fix is ok

Ludwig

and breaks bind-dyndb-ldap.
See 
https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html


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



ACK
Pushed to master: 85d083c36651b15457af75e009f83bc6bb8114b0

--
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] 0056 webui: Counterpart of dnsserver-{find, show, mod}

2016-06-16 Thread Petr Spacek 
On 16.6.2016 12:09, Pavel Vomacka wrote:
> 
> 
> On 06/16/2016 12:06 PM, Pavel Vomacka wrote:
>> Hello,
>>
>> please review attached patch.
>>
>> https://fedorahosted.org/freeipa/ticket/5905
>>
> Fixed commit message


LGTM from user's perspective but I did not review the code.

-- 
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 0153-0158] move ipa-replica-manage del functionality into server-del

2016-06-16 Thread Martin Basti 



On 15.06.2016 15:29, Martin Babinsky wrote:

On 06/15/2016 10:30 AM, Jan Cholasta wrote:

Hi,

On 12.6.2016 17:31, Martin Babinsky wrote:

On 06/09/2016 08:12 PM, Martin Babinsky wrote:
These patches expand `server_del` to a full fledged IPA master 
killer in

domain level 1.

Due to 'server uninstallation removed master from topology' use case,
the individual steps are not in the same order as in the original code
to facilitate self-removal from topology without introducing an 
array of

permissions for master to remove itself.

I had no opportunity to test out the CI test suite because of 
technical
problems so it would be nice if our upstream QE could give it a 
spin and

report errors.

http://www.freeipa.org/page/V4/Manage_replication_topology_4_4
https://fedorahosted.org/freeipa/ticket/5181




Attaching rebased patches and bumping for review.

Please note that they depend on 'Server Roles v2' patchset.


Patch 0153:

Should be an ipaserver module, unless it is required on clients as well,
in which case it should be an ipalib module.


Patch 0154: LGTM


Patch 0155:

In LDAPDelete subclasses, the primary key argument is multivalue, so I'm
guessing your post_callback won't work correctly.

Also, since this is *server*-del, s/master/server/ where applicable.


Patch 0156: LGTM


Patch 0157:

This looks suspicious:

+result = server_del_cmd(hostname, version=api_version, **options)

Version is automatically filled in in Command.__call__(), why do you add
it manually here?


Patch 0158: LGTM


Honza



Attaching updated patches.





Hello, I have a few comments:

1)
you reused ID numbers for the your messages

+class ServerRemovalInfo(PublicMessage):
...
+errno = 13020

+class ServerRemovalWarning(PublicMessage):
...
+errno = 13021


 class FailedToRemoveHostDNSRecords(PublicMessage):
...
 errno = 13020


 class DNSForwardPolicyConflictWithEmptyZone(PublicMessage):
...
 errno = 13021

2)
+def _check_topology_connectivity(self, topology_connectivity, 
master_cn):

+try:
+topology_connectivity.check_current_state()
+except ValueError as e:
+raise errors.ServerRemovalError(reason=_(str(e)))
+
+try:
+ topology_connectivity.check_state_after_removal(master_cn)
+except ValueError as e:
+raise errors.ServerRemovalError(reason=_(str(e)))

* _(str(e)): gettext cannot be used by this way
* str(e): you dont need to convert exception to string, this is done 
automatically in exception



3) gettext again
+self.add_message(
+messages.ServerRemovalWarning(
+message=_(msg)
+)
+)


4)
+messages.ServerRemovalWarning(
+message=_("Failed to clean memberPrincipal 
{principal}"
+  " from s4u2proxy entry {dn}: 
{err}".format(

+  principal=member_principal,
+  dn=dn,
+  err=e

+messages.ServerRemovalWarning(
+message=_("Failed to clean up DNA hostname entries 
for "

+  "{master}: {err}".format(
+  master=master, err=e

several more times

I'm not sure if this will work, for safety I would prefer to change it 
to dictionary substitution

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668226
It looks like it was fixed in gettext 18.3, some distributions still 
have the older one


I have to test more how gettext works with the new python format strings

5)
+def interactive_prompt_callback(self, kw):
+self.api.Backend.textui.print_plain(
+_("Removing {server} from replication topology, "
+  "please wait...".format(server=', '.join(kw['cn']

Will this work? IMO this should be on client side


-- 
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread thierry bordaz 



On 06/16/2016 12:14 PM, Petr Spacek wrote:

On 16.6.2016 12:12, Ludwig Krispenz wrote:

On 06/16/2016 12:00 PM, Petr Spacek wrote:

Hello,

Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly

no. Old DS handles filters strictly as documented in the admin guide,
requiring access rights to each attribute used in the search filter. This was
known and applications had to adapt, in your case there would have had to be
two searches one with the (&()()) filter and one with (|()()()()).

You know, it is quite hard to adapt when your application rely on one SyncRepl
session ...

Anyway, feel free to send patch with rephrased commit message if you wish, I'm
okay with superseding my patch with yours.


Note that https://fedorahosted.org/freeipa/ticket/5944 (patch 0019 still 
under review) has the same requirement on DS >=1.3.5.5.


So the requirement >=1.3.5.6 makes me happy.

thanks
thierry


Petr^2 Spacek


This was improved in the latest version and componets withou access are
ignored in filter evaluation to avoid the problems you did run into.

otherwise your fix is ok

Ludwig

and breaks bind-dyndb-ldap.
See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html

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


--
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Ludwig Krispenz 


On 06/16/2016 12:14 PM, Petr Spacek wrote:

On 16.6.2016 12:12, Ludwig Krispenz wrote:

On 06/16/2016 12:00 PM, Petr Spacek wrote:

Hello,

Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly

no. Old DS handles filters strictly as documented in the admin guide,
requiring access rights to each attribute used in the search filter. This was
known and applications had to adapt, in your case there would have had to be
two searches one with the (&()()) filter and one with (|()()()()).

You know, it is quite hard to adapt when your application rely on one SyncRepl
session ...

Anyway, feel free to send patch with rephrased commit message if you wish, I'm
okay with superseding my patch with yours.

no, it's fine, only sometimes I need to defend DS a bit


Petr^2 Spacek


This was improved in the latest version and componets withou access are
ignored in filter evaluation to avoid the problems you did run into.

otherwise your fix is ok

Ludwig

and breaks bind-dyndb-ldap.
See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html

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


--
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Petr Spacek 
On 16.6.2016 12:12, Ludwig Krispenz wrote:
> 
> On 06/16/2016 12:00 PM, Petr Spacek wrote:
>> Hello,
>>
>> Require 389-ds-base >= 1.3.5.6
>>
>> Old DS handles LDAP filters incorrectly
> no. Old DS handles filters strictly as documented in the admin guide,
> requiring access rights to each attribute used in the search filter. This was
> known and applications had to adapt, in your case there would have had to be
> two searches one with the (&()()) filter and one with (|()()()()).

You know, it is quite hard to adapt when your application rely on one SyncRepl
session ...

Anyway, feel free to send patch with rephrased commit message if you wish, I'm
okay with superseding my patch with yours.

Petr^2 Spacek

> This was improved in the latest version and componets withou access are
> ignored in filter evaluation to avoid the problems you did run into.
> 
> otherwise your fix is ok
> 
> Ludwig
>> and breaks bind-dyndb-ldap.
>> See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html
>>
>> https://fedorahosted.org/freeipa/ticket/2008

-- 
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] 0056 webui: Counterpart of dnsserver-{find, show, mod}

2016-06-16 Thread Pavel Vomacka 



On 06/16/2016 12:06 PM, Pavel Vomacka wrote:

Hello,

please review attached patch.

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


Fixed commit message

--
Pavel^3 Vomacka
From c61e0dd9190be2537ecd8da0a4fa5c0ace81a81e Mon Sep 17 00:00:00 2001
From: Pavel Vomacka 
Date: Thu, 16 Jun 2016 10:09:36 +0200
Subject: [PATCH] DNS Servers: Web UI part

Adds new page with DNS Servers and details page about each server.
It is counterpart of dnsserver-{find,show,mod} CLI commands.

Part of: https://fedorahosted.org/freeipa/ticket/5905
---
 install/ui/src/freeipa/dns.js  | 54 ++
 install/ui/src/freeipa/navigation/menu_spec.js |  1 +
 2 files changed, 55 insertions(+)

diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js
index 8573e653770867210bb31066021e5b78809b1573..a441b56026aa1510d5c7357c156a12e2eb46325b 100644
--- a/install/ui/src/freeipa/dns.js
+++ b/install/ui/src/freeipa/dns.js
@@ -492,6 +492,58 @@ return {
 };};
 
 
+var make_dnsserver_spec = function() {
+var spec = {
+name: 'dnsserver',
+enable_test: function() {
+return IPA.dns_enabled;
+},
+facets: [
+{
+$type: 'search',
+no_update: true,
+columns: [
+'idnsserverid'
+]
+},
+{
+$type: 'details',
+disable_facet_tabs: true,
+fields: [
+'idnssoamname',
+'idnsserverid',
+{
+$type: 'multivalued',
+name: 'idnsforwarders',
+validators: ['dnsforwarder']
+},
+{
+$type: 'radio',
+name: 'idnsforwardpolicy',
+options: [
+{
+value: 'first',
+label: '@i18n:objects.dnsconfig.forward_first'
+},
+{
+value: 'only',
+label: '@i18n:objects.dnsconfig.forward_only'
+},
+{
+value: 'none',
+label: '@i18n:objects.dnsconfig.forward_none'
+}
+]
+}
+]
+}
+]
+};
+
+return spec;
+};
+
+
 IPA.dnszone_details_facet = function(spec, no_init) {
 
 spec = spec || {};
@@ -2521,6 +2573,7 @@ exp.config_spec = make_config_spec();
 exp.zone_spec = make_zone_spec();
 exp.record_spec = make_record_spec();
 exp.forwardzone_spec = make_forwardzone_spec();
+exp.dnsserver_spec = make_dnsserver_spec();
 exp.register = function() {
 var e = reg.entity;
 var w = reg.widget;
@@ -2532,6 +2585,7 @@ exp.register = function() {
 e.register({type: 'dnszone', spec: exp.zone_spec});
 e.register({type: 'dnsrecord', spec: exp.record_spec});
 e.register({type: 'dnsforwardzone', spec: exp.forwardzone_spec});
+e.register({type: 'dnsserver', spec: exp.dnsserver_spec});
 
 w.register('dnszone_name', IPA.dnszone_name_widget);
 w.register('force_dnszone_add_checkbox', IPA.force_dnszone_add_checkbox_widget);
diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js
index 2e47761ce3f17289d0a0a914896ee31209ace290..108f4577f7e1326b9c9bc495c54f6e1f12a0cce6 100644
--- a/install/ui/src/freeipa/navigation/menu_spec.js
+++ b/install/ui/src/freeipa/navigation/menu_spec.js
@@ -179,6 +179,7 @@ var nav = {};
 ]
 },
 { entity: 'dnsforwardzone' },
+{ entity: 'dnsserver' },
 { entity: 'dnsconfig' }
 ]
 }
-- 
2.5.5

-- 
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 0503-0513, 0515-0519] DNS locations

2016-06-16 Thread Petr Spacek 
On 15.6.2016 17:24, Petr Spacek wrote:
> On 15.6.2016 15:45, Martin Basti wrote:
>>
>>
>> On 15.06.2016 14:52, Martin Basti wrote:
>>> 
>>> Hydra patching: Updated patches attached + new patches for dnsserver-*
>>> commands attached


>>> Updated+rebased patches after Honza's interactive review
>>>
>>>
>> Minor nitpick fixed
>>
>>
>>
> freeipa-mbasti-0503.3-DNS-Locations-add-index-for-ipalocation-attribute.patch
> ACK
> 
> freeipa-mbasti-0505.3-DNS-Locations-add-idnsTemplateObject-objectclass.patch
> ACK
> 
> 
> I will get to the rest later on.


Problems I found (could be solved in separate patches if you wish):

1. NACK
# ipa dns-update-system-records --dry-run
ipa: ERROR: an internal error has occurred
ValueError: dns_update_system_records.validate_output(): unexpected keys
['summary'] in { ...


2. NACK
Command ipa dns-update-system-records does not work with DNS Administrators
privilege when some record is missing:

ipa: WARNING: Update of system record
'_kpasswd._tcp.dom-046.abc.idm.lab.eng.brq.redhat.com. 86400 IN SRV 0 100 464
vm-046.abc.idm.lab.eng.brq.redhat.com.' failed with error: Insufficient
access: Insufficient 'write' privilege to the 'objectClass' attribute of entry
'idnsname=_kpasswd._tcp,idnsname=dom-046.abc.idm.lab.eng.brq.redhat.com.,cn=dns,dc=suffix'.

3. NACK
IPA server upgrade does not create idnsServerConfigObjects in cn=dns
In fact the upgrade does not even add the object class into schema.


These needs to be fixed before we can proceed.

-- 
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Ludwig Krispenz 


On 06/16/2016 12:00 PM, Petr Spacek wrote:

Hello,

Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly
no. Old DS handles filters strictly as documented in the admin guide, 
requiring access rights to each attribute used in the search filter. 
This was known and applications had to adapt, in your case there would 
have had to be two searches one with the (&()()) filter and one with 
(|()()()()).


This was improved in the latest version and componets withou access are 
ignored in filter evaluation to avoid the problems you did run into.


otherwise your fix is ok

Ludwig

and breaks bind-dyndb-ldap.
See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html

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





--
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] [PATCH] 0056 webui: Counterpart of dnsserver-{find, show, mod}

2016-06-16 Thread Pavel Vomacka 

Hello,

please review attached patch.

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

--
Pavel^3 Vomacka
From 16270e37ce76796e76513270f5833241d4f5c892 Mon Sep 17 00:00:00 2001
From: Pavel Vomacka 
Date: Thu, 16 Jun 2016 10:09:36 +0200
Subject: [PATCH] DNS Servers: Web UI part

Adds new page with DNS Servers and details page about each server.
There is also new adder dialog for adding new DNS Server. In summary
it is counterpart of dnsserver-{find,show,mod} CLI commands.

Part of: https://fedorahosted.org/freeipa/ticket/5905
---
 install/ui/src/freeipa/dns.js  | 54 ++
 install/ui/src/freeipa/navigation/menu_spec.js |  1 +
 2 files changed, 55 insertions(+)

diff --git a/install/ui/src/freeipa/dns.js b/install/ui/src/freeipa/dns.js
index 8573e653770867210bb31066021e5b78809b1573..a441b56026aa1510d5c7357c156a12e2eb46325b 100644
--- a/install/ui/src/freeipa/dns.js
+++ b/install/ui/src/freeipa/dns.js
@@ -492,6 +492,58 @@ return {
 };};
 
 
+var make_dnsserver_spec = function() {
+var spec = {
+name: 'dnsserver',
+enable_test: function() {
+return IPA.dns_enabled;
+},
+facets: [
+{
+$type: 'search',
+no_update: true,
+columns: [
+'idnsserverid'
+]
+},
+{
+$type: 'details',
+disable_facet_tabs: true,
+fields: [
+'idnssoamname',
+'idnsserverid',
+{
+$type: 'multivalued',
+name: 'idnsforwarders',
+validators: ['dnsforwarder']
+},
+{
+$type: 'radio',
+name: 'idnsforwardpolicy',
+options: [
+{
+value: 'first',
+label: '@i18n:objects.dnsconfig.forward_first'
+},
+{
+value: 'only',
+label: '@i18n:objects.dnsconfig.forward_only'
+},
+{
+value: 'none',
+label: '@i18n:objects.dnsconfig.forward_none'
+}
+]
+}
+]
+}
+]
+};
+
+return spec;
+};
+
+
 IPA.dnszone_details_facet = function(spec, no_init) {
 
 spec = spec || {};
@@ -2521,6 +2573,7 @@ exp.config_spec = make_config_spec();
 exp.zone_spec = make_zone_spec();
 exp.record_spec = make_record_spec();
 exp.forwardzone_spec = make_forwardzone_spec();
+exp.dnsserver_spec = make_dnsserver_spec();
 exp.register = function() {
 var e = reg.entity;
 var w = reg.widget;
@@ -2532,6 +2585,7 @@ exp.register = function() {
 e.register({type: 'dnszone', spec: exp.zone_spec});
 e.register({type: 'dnsrecord', spec: exp.record_spec});
 e.register({type: 'dnsforwardzone', spec: exp.forwardzone_spec});
+e.register({type: 'dnsserver', spec: exp.dnsserver_spec});
 
 w.register('dnszone_name', IPA.dnszone_name_widget);
 w.register('force_dnszone_add_checkbox', IPA.force_dnszone_add_checkbox_widget);
diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js
index 2e47761ce3f17289d0a0a914896ee31209ace290..108f4577f7e1326b9c9bc495c54f6e1f12a0cce6 100644
--- a/install/ui/src/freeipa/navigation/menu_spec.js
+++ b/install/ui/src/freeipa/navigation/menu_spec.js
@@ -179,6 +179,7 @@ var nav = {};
 ]
 },
 { entity: 'dnsforwardzone' },
+{ entity: 'dnsserver' },
 { entity: 'dnsconfig' }
 ]
 }
-- 
2.5.5

-- 
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 0133] Require 389-ds-base >= 1.3.5.6

2016-06-16 Thread Petr Spacek 
Hello,

Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html

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

-- 
Petr^2 Spacek
From 6cadda4044cf2ea85c84e04937455ab7726207e1 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Thu, 16 Jun 2016 11:58:56 +0200
Subject: [PATCH] Require 389-ds-base >= 1.3.5.6

Old DS handles LDAP filters incorrectly and breaks bind-dyndb-ldap.
See https://www.redhat.com/archives/freeipa-devel/2016-June/msg00477.html

https://fedorahosted.org/freeipa/ticket/2008
---
 freeipa.spec.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index d0f6888b47dbc6bcb7dcaf271d71900d67f97a2b..0d5c745d5306cd7141c573454bd1c1e6a78c7e7f 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -42,7 +42,7 @@ Source0:freeipa-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 %if ! %{ONLY_CLIENT}
-BuildRequires:  389-ds-base-devel >= 1.3.5
+BuildRequires:  389-ds-base-devel >= 1.3.5.6
 BuildRequires:  svrcore-devel
 BuildRequires:  policycoreutils >= 2.1.12-5
 BuildRequires:  systemd-units
@@ -131,7 +131,7 @@ Requires: %{name}-client = %{version}-%{release}
 Requires: %{name}-admintools = %{version}-%{release}
 Requires: %{name}-common = %{version}-%{release}
 Requires: python2-ipaserver = %{version}-%{release}
-Requires: 389-ds-base >= 1.3.5
+Requires: 389-ds-base >= 1.3.5.6
 Requires: openldap-clients > 2.4.35-4
 Requires: nss >= 3.14.3-12.0
 Requires: nss-tools >= 3.14.3-12.0
@@ -163,7 +163,7 @@ Requires: zip
 Requires: policycoreutils >= 2.1.12-5
 Requires: tar
 Requires(pre): certmonger >= 0.78
-Requires(pre): 389-ds-base >= 1.3.5
+Requires(pre): 389-ds-base >= 1.3.5.6
 Requires: fontawesome-fonts
 Requires: open-sans-fonts
 Requires: openssl
-- 
2.5.5

-- 
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] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

2016-06-16 Thread Petr Spacek 
On 16.6.2016 11:34, Ludwig Krispenz wrote:
> 
> On 06/16/2016 11:23 AM, Ludwig Krispenz wrote:
>>
>> On 06/16/2016 06:55 AM, Petr Spacek wrote:
>>> Hello,
>>>
>>> TL;DR version:
>>> Upgrade to 389-ds-base-1.3.5.6-1.fc24.
>>>
>>> I was facing weird filter/ACI evaluation with 389 DS
>>> 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
>>> realized that DS is old one ...):
>>>
>>>
>>> Test
>>> 
>>> First, let's try LDAP search with OR filter consisting of 5 components:
>>>
>>> [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
>>> nentries=0 etime=0
>>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
>>>
>>> [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
>>> base="cn=dns,dc=toplevel" scope=2
>>> filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
>>>
>>> attrs="objectClass"
>>> [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101
>>> nentries=1 etime=0
>>> [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
>>> [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1
>>>
>>> It returns 1 entry - the idnsServerConfigObject object.
>>>
>>>
>>>
>>> Now let us re-try shortened filter containing only 4 OR components. I would
>>> expect to get less entries but that is not the case:
>>>
>>> [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL 
>>> connection
>>> from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2
>>> [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
>>> [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl
>>> version=3 mech=GSSAPI
>>> [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97
>>> nentries=0 etime=0, SASL bind in progress
>>> [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl
>>> version=3 mech=GSSAPI
>>> [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97
>>> nentries=0 etime=0, SASL bind in progress
>>> [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl
>>> version=3 mech=GSSAPI
>>> [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
>>> nentries=0 etime=0
>>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
>>>
>>> [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
>>> base="cn=dns,dc=toplevel" scope=2
>>> filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
>>>
>>> attrs="objectClass"
>>> [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101
>>> nentries=11 etime=0
>>>
>>> Huh? Now we got 11 entries.
>>>
>>>
>>> When I do the first search as Directory Manager it returns all 12 matching
>>> entries (which is expected number, at least according to my match-by-eye
>>> algorithm :-)).
>>>
>>>
>>> Schema
>>> ==
>>> idnsServerId attribute definition contains an equality specification:
>>> ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server 
>>> identifier'
>>> EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
>>> X-ORIGIN 'IPA v4.4' )
>>>
>>>
>>> Indices
>>> ===
>>> The attribute itself is not indexed but that should not hurt I guess.
>>>
>>> Mere addition of equality index to the attribute did not help.
>>>
>>> Reindexing using
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks
>>>
>>> did not help either.
>>>
>>>
>>>
>>> ACI
>>> ===
>>> Relevant ACIs are:
>>> (targetattr = "createtimestamp || entryusn || idnsforwarders ||
>>> idnsforwardpolicy || idnsserverid || idnssoamname || 
>>> idnssubstitutionvariable
>>> || modifytimestamp || objectclass")(targetfilter =
>>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
>>> Read DNS Servers Configuration";allow (compare,read,search) groupdn =
>>> "ldap:///cn=System: Read DNS Servers
>>> Configuration,cn=permissions,cn=pbac,dc=toplevel";)
>>>
>>> (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
>>> idnssubstitutionvariable")(targetfilter =
>>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
>>> Modify DNS Servers Configuration";allow (write) groupdn = 
>>> "ldap:///cn=System:
>>> Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)
>>>
>>>
>>> BIND DN
>>> krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel
>>>
>>> is member of
>>> cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel
>>> which is member of
>>> cn=System: Read DNS Se

Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

2016-06-16 Thread Ludwig Krispenz 


On 06/16/2016 11:23 AM, Ludwig Krispenz wrote:


On 06/16/2016 06:55 AM, Petr Spacek wrote:

Hello,

TL;DR version:
Upgrade to 389-ds-base-1.3.5.6-1.fc24.

I was facing weird filter/ACI evaluation with 389 DS
389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
realized that DS is old one ...):


Test

First, let's try LDAP search with OR filter consisting of 5 components:

[16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" 


[16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" 


attrs="objectClass"
[16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 
tag=101

nentries=1 etime=0
[16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
[16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1

It returns 1 entry - the idnsServerConfigObject object.



Now let us re-try shortened filter containing only 4 OR components. I 
would

expect to get less entries but that is not the case:

[16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL 
connection
from 2620:52:0:224e:21a:4aff:fe23:12d2 to 
2620:52:0:224e:21a:4aff:fe23:12d2

[16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
[16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" 
method=sasl

version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 
tag=97

nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" 
method=sasl

version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 
tag=97

nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" 
method=sasl

version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" 


[16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" 


attrs="objectClass"
[16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 
tag=101

nentries=11 etime=0

Huh? Now we got 11 entries.


When I do the first search as Directory Manager it returns all 12 
matching

entries (which is expected number, at least according to my match-by-eye
algorithm :-)).


Schema
==
idnsServerId attribute definition contains an equality specification:
( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server 
identifier'
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE

X-ORIGIN 'IPA v4.4' )


Indices
===
The attribute itself is not indexed but that should not hurt I guess.

Mere addition of equality index to the attribute did not help.

Reindexing using
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks 


did not help either.



ACI
===
Relevant ACIs are:
(targetattr = "createtimestamp || entryusn || idnsforwarders ||
idnsforwardpolicy || idnsserverid || idnssoamname || 
idnssubstitutionvariable

|| modifytimestamp || objectclass")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl 
"permission:System:

Read DNS Servers Configuration";allow (compare,read,search) groupdn =
"ldap:///cn=System: Read DNS Servers
Configuration,cn=permissions,cn=pbac,dc=toplevel";)

(targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
idnssubstitutionvariable")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl 
"permission:System:
Modify DNS Servers Configuration";allow (write) groupdn = 
"ldap:///cn=System:

Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)


BIND DN
krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel 


is member of
cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel
which is member of
cn=System: Read DNS Servers 
Configuration,cn=permissions,cn=pbac,dc=toplevel


so we should be all good.



Now was totally confused and was looking for a bug in bind-dyndb-ldap 
until I

realized that DS is returning weird results... Upgrade to
389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that.
I'm still not sure that I get your 5 and 4 OR filter searches, as in 
the example you provided there was also an AND involved, but there is 
a fix in 1.3.5.6. which makes a differe

Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

2016-06-16 Thread Ludwig Krispenz 


On 06/16/2016 06:55 AM, Petr Spacek wrote:

Hello,

TL;DR version:
Upgrade to 389-ds-base-1.3.5.6-1.fc24.

I was facing weird filter/ACI evaluation with 389 DS
389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
realized that DS is old one ...):


Test

First, let's try LDAP search with OR filter consisting of 5 components:

[16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
[16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
attrs="objectClass"
[16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
[16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1

It returns 1 entry - the idnsServerConfigObject object.



Now let us re-try shortened filter containing only 4 OR components. I would
expect to get less entries but that is not the case:

[16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection
from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2
[16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
[16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
[16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
attrs="objectClass"
[16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101
nentries=11 etime=0

Huh? Now we got 11 entries.


When I do the first search as Directory Manager it returns all 12 matching
entries (which is expected number, at least according to my match-by-eye
algorithm :-)).


Schema
==
idnsServerId attribute definition contains an equality specification:
( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier'
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
X-ORIGIN 'IPA v4.4' )


Indices
===
The attribute itself is not indexed but that should not hurt I guess.

Mere addition of equality index to the attribute did not help.

Reindexing using
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks
did not help either.



ACI
===
Relevant ACIs are:
(targetattr = "createtimestamp || entryusn || idnsforwarders ||
idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable
|| modifytimestamp || objectclass")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Read DNS Servers Configuration";allow (compare,read,search) groupdn =
"ldap:///cn=System: Read DNS Servers
Configuration,cn=permissions,cn=pbac,dc=toplevel";)

(targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
idnssubstitutionvariable")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System:
Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)


BIND DN
krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel
is member of
cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel
which is member of
cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel

so we should be all good.



Now was totally confused and was looking for a bug in bind-dyndb-ldap until I
realized that DS is returning weird results... Upgrade to
389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that.
I'm still not sure that I get your 5 and 4 OR filter searches, as in the 
example you provided there was also an AND involved, but there is a fix 
in 1.3.5.6. which makes a difference: 48275


Before we requested that in an OR filter the user has to have access to 
ALL attributes m

Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

2016-06-16 Thread thierry bordaz 



On 06/16/2016 10:50 AM, Petr Spacek wrote:

On 16.6.2016 10:47, thierry bordaz wrote:

On 06/16/2016 06:55 AM, Petr Spacek wrote:

Hello,

TL;DR version:
Upgrade to 389-ds-base-1.3.5.6-1.fc24.

I was facing weird filter/ACI evaluation with 389 DS
389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
realized that DS is old one ...):


Test

First, let's try LDAP search with OR filter consisting of 5 components:

[16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"

[16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"

attrs="objectClass"
[16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
[16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1

It returns 1 entry - the idnsServerConfigObject object.

Hi Petr,

In fact it is difficult to justify and identify which fix fixes this issue (I
suspect https://fedorahosted.org/389/ticket/48275 but not clear why it
participates).

in 1.3.5.6-1, it returns 11 entries. How many of them are
idnsServerConfigObject ? thanks theirry

Exactly one.


So "permission:System:Read DNS Servers Configuration" should  grant 
read/search rights only for this one.

There should be  others ACI that grant you the access to the 10 others.
You may turn on ACI logging ("nsslapd-errorlog-level: 262272") to 
identify which ACIs granted you this read/search access.


thanks
thierry


Petr^2 Spacek


Now let us re-try shortened filter containing only 4 OR components. I would
expect to get less entries but that is not the case:

[16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection
from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2
[16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
[16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"

[16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"

attrs="objectClass"
[16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101
nentries=11 etime=0

Huh? Now we got 11 entries.


When I do the first search as Directory Manager it returns all 12 matching
entries (which is expected number, at least according to my match-by-eye
algorithm :-)).


Schema
==
idnsServerId attribute definition contains an equality specification:
( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier'
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
X-ORIGIN 'IPA v4.4' )


Indices
===
The attribute itself is not indexed but that should not hurt I guess.

Mere addition of equality index to the attribute did not help.

Reindexing using
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks

did not help either.



ACI
===
Relevant ACIs are:
(targetattr = "createtimestamp || entryusn || idnsforwarders ||
idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable
|| modifytimestamp || objectclass")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Read DNS Servers Configuration";allow (compare,read,search) groupdn =
"ldap:///cn=System: Read DNS Servers
Configuration,cn=permissions,cn=pbac,dc=toplevel";)

(targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
idnssubstitutionvariable")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System:
Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)


BIND DN
krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.

Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

2016-06-16 Thread Ludwig Krispenz 


On 06/16/2016 06:55 AM, Petr Spacek wrote:

Hello,

TL;DR version:
Upgrade to 389-ds-base-1.3.5.6-1.fc24.

I was facing weird filter/ACI evaluation with 389 DS
389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
realized that DS is old one ...):


Test

First, let's try LDAP search with OR filter consisting of 5 components:

[16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
[16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
you don't have 5 OR components, you have only 2, the second one is an 
AND with 4 components,

attrs="objectClass"
[16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
[16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1

It returns 1 entry - the idnsServerConfigObject object.



Now let us re-try shortened filter containing only 4 OR components. I would
expect to get less entries but that is not the case:

[16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection
from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2
[16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
[16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
[16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
attrs="objectClass"
[16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101
nentries=11 etime=0

Huh? Now we got 11 entries.


When I do the first search as Directory Manager it returns all 12 matching
entries (which is expected number, at least according to my match-by-eye
algorithm :-)).


Schema
==
idnsServerId attribute definition contains an equality specification:
( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier'
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
X-ORIGIN 'IPA v4.4' )


Indices
===
The attribute itself is not indexed but that should not hurt I guess.

Mere addition of equality index to the attribute did not help.

Reindexing using
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks
did not help either.



ACI
===
Relevant ACIs are:
(targetattr = "createtimestamp || entryusn || idnsforwarders ||
idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable
|| modifytimestamp || objectclass")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Read DNS Servers Configuration";allow (compare,read,search) groupdn =
"ldap:///cn=System: Read DNS Servers
Configuration,cn=permissions,cn=pbac,dc=toplevel";)

(targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
idnssubstitutionvariable")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System:
Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)


BIND DN
krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel
is member of
cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel
which is member of
cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel

so we should be all good.



Now was totally confused and was looking for a bug in bind-dyndb-ldap until I
realized that DS is returning weird results... Upgrade to
389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that.

This would be a blocker for FreeIPA 4.4 because the old version totally breaks
bind-dyndb-ldap.



--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial regi

Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

2016-06-16 Thread Petr Spacek 
On 16.6.2016 10:47, thierry bordaz wrote:
> On 06/16/2016 06:55 AM, Petr Spacek wrote:
>> Hello,
>>
>> TL;DR version:
>> Upgrade to 389-ds-base-1.3.5.6-1.fc24.
>>
>> I was facing weird filter/ACI evaluation with 389 DS
>> 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
>> realized that DS is old one ...):
>>
>>
>> Test
>> 
>> First, let's try LDAP search with OR filter consisting of 5 components:
>>
>> [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
>> nentries=0 etime=0
>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
>>
>> [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
>> base="cn=dns,dc=toplevel" scope=2
>> filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
>>
>> attrs="objectClass"
>> [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101
>> nentries=1 etime=0
>> [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
>> [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1
>>
>> It returns 1 entry - the idnsServerConfigObject object.
> Hi Petr,
> 
> In fact it is difficult to justify and identify which fix fixes this issue (I
> suspect https://fedorahosted.org/389/ticket/48275 but not clear why it
> participates).
> 
> in 1.3.5.6-1, it returns 11 entries. How many of them are
> idnsServerConfigObject ? thanks theirry

Exactly one.

Petr^2 Spacek

>> Now let us re-try shortened filter containing only 4 OR components. I would
>> expect to get less entries but that is not the case:
>>
>> [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL 
>> connection
>> from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2
>> [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
>> [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl
>> version=3 mech=GSSAPI
>> [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97
>> nentries=0 etime=0, SASL bind in progress
>> [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl
>> version=3 mech=GSSAPI
>> [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97
>> nentries=0 etime=0, SASL bind in progress
>> [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl
>> version=3 mech=GSSAPI
>> [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
>> nentries=0 etime=0
>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
>>
>> [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
>> base="cn=dns,dc=toplevel" scope=2
>> filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
>>
>> attrs="objectClass"
>> [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101
>> nentries=11 etime=0
>>
>> Huh? Now we got 11 entries.
>>
>>
>> When I do the first search as Directory Manager it returns all 12 matching
>> entries (which is expected number, at least according to my match-by-eye
>> algorithm :-)).
>>
>>
>> Schema
>> ==
>> idnsServerId attribute definition contains an equality specification:
>> ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier'
>> EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
>> X-ORIGIN 'IPA v4.4' )
>>
>>
>> Indices
>> ===
>> The attribute itself is not indexed but that should not hurt I guess.
>>
>> Mere addition of equality index to the attribute did not help.
>>
>> Reindexing using
>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks
>>
>> did not help either.
>>
>>
>>
>> ACI
>> ===
>> Relevant ACIs are:
>> (targetattr = "createtimestamp || entryusn || idnsforwarders ||
>> idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable
>> || modifytimestamp || objectclass")(targetfilter =
>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
>> Read DNS Servers Configuration";allow (compare,read,search) groupdn =
>> "ldap:///cn=System: Read DNS Servers
>> Configuration,cn=permissions,cn=pbac,dc=toplevel";)
>>
>> (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
>> idnssubstitutionvariable")(targetfilter =
>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
>> Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System:
>> Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)
>>
>>
>> BIND DN
>> krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=topl

Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

2016-06-16 Thread thierry bordaz 



On 06/16/2016 06:55 AM, Petr Spacek wrote:

Hello,

TL;DR version:
Upgrade to 389-ds-base-1.3.5.6-1.fc24.

I was facing weird filter/ACI evaluation with 389 DS
389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
realized that DS is old one ...):


Test

First, let's try LDAP search with OR filter consisting of 5 components:

[16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
[16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
attrs="objectClass"
[16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
[16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1

It returns 1 entry - the idnsServerConfigObject object.

Hi Petr,

In fact it is difficult to justify and identify which fix fixes this 
issue (I suspect https://fedorahosted.org/389/ticket/48275 but not clear 
why it participates).


in 1.3.5.6-1, it returns 11 entries. How many of them are 
idnsServerConfigObject ? thanks theirry






Now let us re-try shortened filter containing only 4 OR components. I would
expect to get less entries but that is not the case:

[16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection
from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2
[16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
[16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
[16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
base="cn=dns,dc=toplevel" scope=2
filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
attrs="objectClass"
[16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101
nentries=11 etime=0

Huh? Now we got 11 entries.


When I do the first search as Directory Manager it returns all 12 matching
entries (which is expected number, at least according to my match-by-eye
algorithm :-)).


Schema
==
idnsServerId attribute definition contains an equality specification:
( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier'
EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
X-ORIGIN 'IPA v4.4' )


Indices
===
The attribute itself is not indexed but that should not hurt I guess.

Mere addition of equality index to the attribute did not help.

Reindexing using
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks
did not help either.



ACI
===
Relevant ACIs are:
(targetattr = "createtimestamp || entryusn || idnsforwarders ||
idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable
|| modifytimestamp || objectclass")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Read DNS Servers Configuration";allow (compare,read,search) groupdn =
"ldap:///cn=System: Read DNS Servers
Configuration,cn=permissions,cn=pbac,dc=toplevel";)

(targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
idnssubstitutionvariable")(targetfilter =
"(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System:
Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)


BIND DN
krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel
is member of
cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel
which is member of
cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel

so we should be all good.



Now was totally confused and was looking for a bug in bind-dyndb-ldap until I
realized that DS is returning weird results... Upgrade to
389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that.

[Freeipa-devel] [Patch-0046] Increased certmonger timeout to address ticket N 5758

2016-06-16 Thread Oleg Fayans 
With this change the certmonger timeout issue is no longer observed in
abcd lab.

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
From 2063d59f3d8303abf056d38a68ac75f9f2d9cd24 Mon Sep 17 00:00:00 2001
From: Oleg Fayans 
Date: Thu, 16 Jun 2016 10:25:59 +0200
Subject: [PATCH] Increased certmonger timeout

https://fedorahosted.org/freeipa/ticket/5758
---
 ipaserver/install/certs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/install/certs.py b/ipaserver/install/certs.py
index 76f62751db8abbb27ca5849bcb09c5b5540e2cda..b3d273ff107f0493516845745c4f14242fc518ca 100644
--- a/ipaserver/install/certs.py
+++ b/ipaserver/install/certs.py
@@ -654,7 +654,7 @@ class CertDB(object):
 subject=host,
 passwd_fname=self.passwd_fname)
 # Now wait for the cert to appear. Check three times then abort
-certmonger.wait_for_request(reqid, timeout=15)
+certmonger.wait_for_request(reqid, timeout=60)
 
 
 class _CrossProcessLock(object):
-- 
1.8.3.1

-- 
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 0047] Fix uninitialized variables in replicainstall

2016-06-16 Thread Stanislav Laznicka 

Hello,

There was a possible use of uninitialized variables in replicainstall.

From 1b26d42e00506b007e087c74cafc0327090aec40 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Thu, 16 Jun 2016 10:05:34 +0200
Subject: [PATCH] Fix unitialized variables in replicainstall

ipaconf and target_fname variables would have been used uninitialized in finally block
should an exception occur in the try block before their initialization.
---
 ipaserver/install/server/replicainstall.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py
index f597880471eb3710ebc7163f771d4e6dc9f1e3d6..8864944d814239eec82c8c5d862f0f9ca04b23d2 100644
--- a/ipaserver/install/server/replicainstall.py
+++ b/ipaserver/install/server/replicainstall.py
@@ -1304,10 +1304,12 @@ def promote(installer):
 http_pkcs12_info = installer._http_pkcs12_info
 pkinit_pkcs12_file = installer._pkinit_pkcs12_file
 pkinit_pkcs12_info = installer._pkinit_pkcs12_info
+target_fname = paths.IPA_DEFAULT_CONF
 
 ccache = os.environ['KRB5CCNAME']
 remote_api = installer._remote_api
 conn = remote_api.Backend.ldap2
+ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Replica Promote")
 try:
 conn.connect(ccache=installer._ccache)
 
@@ -1318,9 +1320,7 @@ def promote(installer):
 )
 
 # Save client file and merge in server directives
-target_fname = paths.IPA_DEFAULT_CONF
 fstore.backup_file(target_fname)
-ipaconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Replica Promote")
 ipaconf.setOptionAssignment(" = ")
 ipaconf.setSectionNameDelimiters(("[", "]"))
 
-- 
2.5.5

-- 
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 0413-0416] Support fake_mname option in per-server configuration in LDAP

2016-06-16 Thread Petr Spacek 
On 16.6.2016 09:19, Petr Spacek wrote:
> On 13.6.2016 09:56, Petr Spacek wrote:
>> On 11.6.2016 20:36, Petr Spacek wrote:
>>> Hello,
>>>
>>> Support fake_mname option in per-server configuration in LDAP.
>>>
>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/162
>>>
>>>
>>> Patch set contains necessary infrastructure changes so the configuration is
>>> read before zone loading starts.
>>
>> This version fixes crash which could be triggered by failure in second
>> syncrepl session.
>>
>> (I.e. config sync succeeded but data sync failed.)
> 
> This version fixes another crash triggered by empty set of zones in LDAP.
> 
> I've force-pushed this version to branch
> https://github.com/pspacek/bind-dyndb-ldap/tree/server_config_in_ldap4 .

And here are the patches :-D

-- 
Petr^2 Spacek
From d1c67a763f1d84599cfae8b222fd90e575bd1d87 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Fri, 10 Jun 2016 12:57:48 +0200
Subject: [PATCH] Do not log "connection to the LDAP server was lost" on forced
 reconnects.

This is a cosmetic change which will be used in code which opens and
closes multiple SyncRepl connections.

https://fedorahosted.org/bind-dyndb-ldap/ticket/162
---
 src/ldap_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index af7f5c40500c7843dbf5e4533b83982b52088ced..b922371ae2392ca8bd1069df738d69617bb81905 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -2726,7 +2726,7 @@ handle_connection_error(ldap_instance_t *ldap_inst, ldap_connection_t *ldap_conn
 		/* Try to reconnect on other errors. */
 		log_ldap_error(ldap_conn->handle, "connection error");
 reconnect:
-		if (ldap_conn->handle == NULL)
+		if (ldap_conn->handle == NULL && force == ISC_FALSE)
 			log_error("connection to the LDAP server was lost");
 		result = ldap_connect(ldap_inst, ldap_conn, force);
 		if (result == ISC_R_SUCCESS)
-- 
2.5.5

From 78acc6cff0b506e8a1baf348ac8eca5ffc79a7d9 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Fri, 10 Jun 2016 13:59:26 +0200
Subject: [PATCH] Refactor LDAP SyncRepl connection handling to make it
 reusable.

Now it is easy to sequentially run more SyncRepl sessions with different
parameters. It will be handy for per-server config.

https://fedorahosted.org/bind-dyndb-ldap/ticket/126
---
 src/ldap_helper.c | 190 ++
 1 file changed, 121 insertions(+), 69 deletions(-)

diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index b922371ae2392ca8bd1069df738d69617bb81905..ef810de74094da0d3cbb6db1c52151f5c38f 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -4274,44 +4274,29 @@ ldap_sync_cleanup(ldap_sync_t **ldap_syncp) {
 	*ldap_syncp = NULL;
 }
 
-
+/**
+ * Initialize ldap_sync_t structure. Is has to be freed by ldap_sync_cleanup().
+ * In case of failure, the conn parameter may be invalid and LDAP connection
+ * needs to be re-established.
+ *
+ * @param[in]  filter  LDAP filter to be used in SyncRepl session
+ */
 static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT
 ldap_sync_prepare(ldap_instance_t *inst, settings_set_t *settings,
-		  ldap_connection_t *conn, ldap_sync_t **ldap_syncp) {
+		  const char *filter, ldap_connection_t *conn,
+		  ldap_sync_t **ldap_syncp) {
 	isc_result_t result;
 	const char *base = NULL;
-	isc_uint32_t reconnect_interval;
 	ldap_sync_t *ldap_sync = NULL;
-	const char *server_id = NULL;
-	char filter[1024];
-	const char filter_template[] =
-		"(|(objectClass=idnsConfigObject)"
-		"  (objectClass=idnsZone)"
-		"  (objectClass=idnsForwardZone)"
-		"  (objectClass=idnsRecord)"
-		"  %s%s%s"
-		")";
 
 	REQUIRE(inst != NULL);
 	REQUIRE(ldap_syncp != NULL && *ldap_syncp == NULL);
 
 	/* Remove stale zone & journal files. */
 	CHECK(cleanup_files(inst));
 
-	/* Try to connect. */
-	while (conn->handle == NULL) {
-		result = ISC_R_SHUTTINGDOWN;
-		CHECK_EXIT;
-		CHECK(setting_get_uint("reconnect_interval", settings,
-   &reconnect_interval));
-
-		log_error("ldap_syncrepl will reconnect in %d second%s",
-			  reconnect_interval,
-			  reconnect_interval == 1 ? "": "s");
-		if (!sane_sleep(inst, reconnect_interval))
-			CLEANUP_WITH(ISC_R_SHUTTINGDOWN);
-		handle_connection_error(inst, conn, ISC_TRUE);
-	}
+	if(conn->handle == NULL)
+		CLEANUP_WITH(ISC_R_NOTCONNECTED);
 
 	ldap_sync = ldap_sync_initialize(NULL);
 	if (ldap_sync == NULL) {
@@ -4325,20 +4310,10 @@ ldap_sync_prepare(ldap_instance_t *inst, settings_set_t *settings,
 	if (ldap_sync->ls_base == NULL)
 		CLEANUP_WITH(ISC_R_NOMEMORY);
 	ldap_sync->ls_scope = LDAP_SCOPE_SUBTREE;
-
-	/* request idnsServerConfig object only if server_id is specified */
-	CHECK(setting_get_str("server_id", settings, &server_id));
-	if (strlen(server_id) == 0)
-		CHECK(isc_string_printf(filter, sizeof(filter), filter_template,
-"", "", ""));
-	else
-		CHECK(isc_string_printf(filter, sizeof(filter), filter_template,
-"  (&(objectClass=idnsServerConfigObject)"
-"(idnsSe

Re: [Freeipa-devel] [PATCH 0413-0416] Support fake_mname option in per-server configuration in LDAP

2016-06-16 Thread Petr Spacek 
On 13.6.2016 09:56, Petr Spacek wrote:
> On 11.6.2016 20:36, Petr Spacek wrote:
>> Hello,
>>
>> Support fake_mname option in per-server configuration in LDAP.
>>
>> https://fedorahosted.org/bind-dyndb-ldap/ticket/162
>>
>>
>> Patch set contains necessary infrastructure changes so the configuration is
>> read before zone loading starts.
> 
> This version fixes crash which could be triggered by failure in second
> syncrepl session.
> 
> (I.e. config sync succeeded but data sync failed.)

This version fixes another crash triggered by empty set of zones in LDAP.

I've force-pushed this version to branch
https://github.com/pspacek/bind-dyndb-ldap/tree/server_config_in_ldap4 .

-- 
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] Schema caching for thin client

2016-06-16 Thread David Kupka 

On 06/15/2016 08:15 PM, Petr Vobornik wrote:

On 06/15/2016 02:36 PM, David Kupka wrote:

Hello!
Schema caching for thin client is available here:

https://github.com/dkupka/freeipa/commits/schema_cache

Comments and reviews welcome.

Enjoy!


Not doing proper review. I'll test by using it. But:

1. lint fails

Pylint is running, please wait ...
* Module ipaclient.remote_plugins.schema_cache
ipaclient/remote_plugins/schema_cache.py:283: [W1612(unicode-builtin),
_refresh_schema] unicode built-in referenced)
Makefile:137: recipe for target 'lint' failed
make: *** [lint] Error 1

I.e, you miss:

  import six

  if six.PY3:
  unicode = str



Thanks for the catch, fixed version force-pushed.

--
David Kupka

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