Re: [Freeipa-devel] [PATCH 0166] Workaround: warning if CA did not start at end of upgrade instead of raising error
On 18/11/14 22:01, Martin Kosek wrote:
On 11/18/2014 08:20 PM, Martin Basti wrote:
Ticket: https://fedorahosted.org/freeipa/ticket/4676
Attached patches:
* Version A: uses wget to get status of CA
* Version B: write warning instead of raising exception (error is false
positive, CA is running)
I'm open to suggestions which approach is better
Martin^2
I like A, but I am concerned why you suddenly ignore the use_proxy
option. I added it for a reason as it affects to which port we need to
connect, regardless the transport library. See
https://fedorahosted.org/freeipa/ticket/3973
where I added this option.
Second, I am not happy by you duplicating the XML parsing code, I
would rather see it splited in dogtag.py in separate
_ca_status_parse or similar function call.
Given the obstacles, I am inclining for
- pushing B as a safe fix for Fedora 21 Final
- fixing issues in A and pushing it for minor release after that to
avoid the nasty warning and have some reasonable medium-term fix until
the framework migrates to something better than httpslib, line
python-requests maybe.
Martin
Sounds good to me.
Patch required for F21 attached. (with proper number)
I will send the second patch after release for fedora (or should I sooner?)
Martin^2
--
Martin Basti
From 61508160f5ce2947c78a4e1fd1319ddee538b7bc Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Tue, 18 Nov 2014 18:30:59 +0100
Subject: [PATCH] Show warning instead of error if CA did not start
This is just workaround, checking if CA is working raises false positive
exception during upgrade
Ticket: https://fedorahosted.org/freeipa/ticket/4676
---
install/tools/ipa-upgradeconfig | 4
1 file changed, 4 insertions(+)
diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index b81a474b2bb14f1582dabd649400c13f7ce6d369..02bfe3a79f83e65f428fe2220d940eb39fdbd928 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -1473,6 +1473,10 @@ def main():
ca.restart(dogtag.configured_constants().PKI_INSTANCE_NAME)
except ipautil.CalledProcessError, e:
root_logger.error(Failed to restart %s: %s, ca.service_name, e)
+# FIXME https://fedorahosted.org/freeipa/ticket/4676
+# workaround
+except RuntimeError as e:
+root_logger.warning(str(e))
set_sssd_domain_option('ipa_server_mode', 'True')
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Fix getkeytab operation
On Tue, 18 Nov 2014, Simo Sorce wrote: On Tue, 18 Nov 2014 15:01:15 -0500 Nathaniel McCallum npmccal...@redhat.com wrote: As I see it, we're setting out a new precedent. All new ASN.1 code will take this route (which is, indeed, better). So while it is small now, it won't stay small forever. Being that we are in the business of routinely handling ASN.1 stuff, this seems to me like a sensible architecture for the future. Ok, I think I should have fixed all the issues you brought up. And my tests still work fine :) Works fine. However, I'm getting wrong TGT enctype back from the KDC when I try to obtain TGT with des-cbc-crc key: [root@master ~]# ipa host-add --force f21test.f21.test - Added host f21test.f21.test - Host name: f21test.f21.test Principal name: host/f21test.f21.t...@f21.test Password: False Keytab: False Managed by: f21test.f21.test [root@master ~]# ipa service-add --force afs/f21test Added service afs/f21t...@f21.test Principal: afs/f21t...@f21.test Managed by: f21test.f21.test [root@master ~]# ipa-getkeytab -s `hostname` -p afs/f21test -k /tmp/afs.keytab -e des-cbc-crc:v4 -P New Principal Password: Verify Principal Password: Keytab successfully retrieved and stored in: /tmp/afs.keytab [root@master ~]# klist -kt /tmp/afs.keytab -K -e Keytab name: FILE:/tmp/afs.keytab KVNO Timestamp Principal - 1 11/19/14 12:13:01 afs/f21t...@f21.test (des-cbc-crc) (0xea1a0b29152cb383) [root@master ~]# KRB5_TRACE=/dev/stderr KRB5CCNAME=/tmp/afs.ccache kinit -kt /tmp/afs.keytab afs/f21test [28636] 1416392072.862773: Getting initial credentials for afs/f21t...@f21.test [28636] 1416392072.864408: Looked up etypes in keytab: des-cbc-crc [28636] 1416392072.864522: Sending request (175 bytes) to F21.TEST [28636] 1416392072.865127: Sending initial UDP request to dgram 192.168.5.169:88 [28636] 1416392072.866958: Received answer (283 bytes) from dgram 192.168.5.169:88 [28636] 1416392072.867028: Response was from master KDC [28636] 1416392072.867088: Received error from KDC: -1765328359/Additional pre-authentication required [28636] 1416392072.867140: Processing preauth types: 136, 19, 2, 133 [28636] 1416392072.867175: Selected etype info: etype des-cbc-crc, salt F21.TESTafsf21test, params [28636] 1416392072.867193: Received cookie: MIT [28636] 1416392072.867234: Retrieving afs/f21t...@f21.test from FILE:/tmp/afs.keytab (vno 0, enctype des-cbc-crc) with result: 0/Success [28636] 1416392072.867264: AS key obtained for encrypted timestamp: des-cbc-crc/0BE8 [28636] 1416392072.867304: Encrypted timestamp (for 1416392072.867050): plain 301AA011180F32303134313131393130313433325AA10502030D3AEA, encrypted 1C567557D395C0639CB417EE90C08CD41E4829D910166D62ACEDCC2168C23BAD8C70DFE4CD533A81 [28636] 1416392072.867331: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [28636] 1416392072.867349: Produced preauth for next request: 133, 2 [28636] 1416392072.867372: Sending request (252 bytes) to F21.TEST [28636] 1416392072.867416: Sending initial UDP request to dgram 192.168.5.169:88 [28636] 1416392072.946260: Received answer (649 bytes) from dgram 192.168.5.169:88 [28636] 1416392072.946391: Response was from master KDC [28636] 1416392072.946485: Processing preauth types: 19 [28636] 1416392072.946542: Selected etype info: etype des-cbc-crc, salt F21.TESTafsf21test, params [28636] 1416392072.946593: Produced preauth for next request: (empty) [28636] 1416392072.946626: AS key determined by preauth: des-cbc-crc/0BE8 [28636] 1416392072.946688: Decrypted AS reply; session key is: des-cbc-crc/9B41 [28636] 1416392072.946727: FAST negotiation: available [28636] 1416392072.946793: Initializing FILE:/tmp/afs.ccache with default princ afs/f21t...@f21.test [28636] 1416392072.947118: Removing afs/f21t...@f21.test - krbtgt/f21.t...@f21.test from FILE:/tmp/afs.ccache [28636] 1416392072.947146: Storing afs/f21t...@f21.test - krbtgt/f21.t...@f21.test in FILE:/tmp/afs.ccache [28636] 1416392072.947187: Storing config in FILE:/tmp/afs.ccache for krbtgt/f21.t...@f21.test: fast_avail: yes [28636] 1416392072.947219: Removing afs/f21t...@f21.test - krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST@X-CACHECONF: from FILE:/tmp/afs.ccache [28636] 1416392072.947240: Storing afs/f21t...@f21.test - krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST@X-CACHECONF: in FILE:/tmp/afs.ccache [28636] 1416392072.947419: Storing config in FILE:/tmp/afs.ccache for krbtgt/f21.t...@f21.test: pa_type: 2 [28636] 1416392072.947458: Removing afs/f21t...@f21.test - krb5_ccache_conf_data/pa_type/krbtgt\/F21.TEST\@F21.TEST@X-CACHECONF: from FILE:/tmp/afs.ccache [28636] 1416392072.947480: Storing afs/f21t...@f21.test - krb5_ccache_conf_data/pa_type/krbtgt\/F21.TEST\@F21.TEST@X-CACHECONF: in
[Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From 7a279fc809f812a6c7a91ed4a54550ea6589f1d3 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Wed, 19 Nov 2014 12:00:07 +0100 Subject: [PATCH] baseldap: Handle missing parent objects properly in *-find commands When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 --- ipalib/plugins/baseldap.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/baseldap.py b/ipalib/plugins/baseldap.py index 375441c0fd55efe70d5a6f5bed6700e618874082..e4cc699ee0be29c184e35b510c7a10c5ff3d5c07 100644 --- a/ipalib/plugins/baseldap.py +++ b/ipalib/plugins/baseldap.py @@ -1934,7 +1934,11 @@ class LDAPSearch(BaseLDAPCommand, crud.Search): term = args[-1] if self.obj.parent_object: -base_dn = self.api.Object[self.obj.parent_object].get_dn(*args[:-1]) +api_parent_obj = self.api.Object[self.obj.parent_object] +try: +base_dn = api_parent_obj.get_dn_if_exists(*args[:-1]) +except errors.NotFound: +api_parent_obj.handle_not_found(*args[:-1]) else: base_dn = DN(self.obj.container_dn, api.env.basedn) assert isinstance(base_dn, DN) -- 1.9.3 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
On 11/19/2014 12:03 PM, Tomas Babej wrote: Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 486 Lower pki-ca requires to 10.1.2
pki-core build in our Copr is finished:
https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/60561/
If the patch is OK, it should be committed to ipa-4-1 branch and F21+ Fedora
branches. When done, I will trigger SRPM build in Copr.
--
Current Dogtag 10.2 and it's requirements are not properly packaged for
CentOS, yet. To enable FreeIPA running on CentOS 7.0, lower the
Requires on Fedora 20 and CentOS platform on Dogtag 10.1.2 which
has the patches required by FreeIPA backported and which has all
dependencies avaiable.
https://fedorahosted.org/freeipa/ticket/4737
--
Martin Kosek mko...@redhat.com
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.
From 260f37f09b7fb8bdfb8bb0002fc65a7efc4f6ebd Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Wed, 19 Nov 2014 12:29:44 +0100
Subject: [PATCH] Lower pki-ca requires to 10.1.2
Current Dogtag 10.2 and it's requirements are not properly packaged for
CentOS, yet. To enable FreeIPA running on CentOS 7.0, lower the
Requires on Fedora 20 and CentOS platform on Dogtag 10.1.2 which
has the patches required by FreeIPA backported and which has all
dependencies avaiable.
https://fedorahosted.org/freeipa/ticket/4737
---
freeipa.spec.in | 7 +++
1 file changed, 7 insertions(+)
diff --git a/freeipa.spec.in b/freeipa.spec.in
index af367037eee27d45f0c825ad4518f269b2798045..2d1bcbf7db4ca91272dabb75d8caaf0383307f9f 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -130,7 +130,14 @@ Requires(post): systemd-units
Requires: selinux-policy = %{selinux_policy_version}
Requires(post): selinux-policy-base
Requires: slapi-nis = 0.54.1-1
+%if (0%{?fedora} = 20 || 0%{?rhel})
+# pki-ca 10.1.2-4 contains patches required by FreeIPA 4.1
+# The goal is to lower the requirement of pki-ca in Fedora 20
+# and CentOS until packaging of it's requirements is finished.
+Requires: pki-ca = 10.1.2-4
+%else
Requires: pki-ca = 10.2.0-3
+%endif
%if 0%{?rhel}
Requires: subscription-manager
%endif
--
1.9.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
On 11/19/2014 12:24 PM, Martin Kosek wrote: On 11/19/2014 12:03 PM, Tomas Babej wrote: Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? No it does not make all of our LDAP search slower. It only happens for the objects that have parent objects, such as idoverrides or dnsrecords. Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: Up to discussion. We would probably need to introduce a new exception, like ParentObjectNotFound. # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). Look into the get_dn_if_exists, it just wraps around get_dn, so no issue here. Any custom behaviour is preserved. To sum up, I think this is worth changing this behaviour by default, ignoring a non-matching value of the parent object is not a correct general approach in my opinion. -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI
On 13.11.2014 16:49, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4647 Patch attached. The change looses information about the zone apex record. User also might not know what is the message about because it lacks context. CLI option name as context is the cause of this bug but it could be replaced with, e.g., label. So what about: Semantic of setting Authoritative nameserver was changed. It's used only for setting the SOA MNAME attribute. NS record(s) can be edited in special zone apex record - '@'. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 486 Lower pki-ca requires to 10.1.2
On Wed, 19 Nov 2014, Martin Kosek wrote: pki-core build in our Copr is finished: https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/60561/ If the patch is OK, it should be committed to ipa-4-1 branch and F21+ Fedora branches. When done, I will trigger SRPM build in Copr. -- Current Dogtag 10.2 and it's requirements are not properly packaged for CentOS, yet. To enable FreeIPA running on CentOS 7.0, lower the Requires on Fedora 20 and CentOS platform on Dogtag 10.1.2 which has the patches required by FreeIPA backported and which has all dependencies avaiable. https://fedorahosted.org/freeipa/ticket/4737 ACK. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
On 11/19/2014 12:41 PM, Tomas Babej wrote: On 11/19/2014 12:24 PM, Martin Kosek wrote: On 11/19/2014 12:03 PM, Tomas Babej wrote: Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? No it does not make all of our LDAP search slower. It only happens for the objects that have parent objects, such as idoverrides or dnsrecords. ... and makes them slower. Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: Up to discussion. We would probably need to introduce a new exception, like ParentObjectNotFound. # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). Look into the get_dn_if_exists, it just wraps around get_dn, so no issue here. Any custom behaviour is preserved. Ah, ok, thanks for info. To sum up, I think this is worth changing this behaviour by default, ignoring a non-matching value of the parent object is not a correct general approach in my opinion. Well, that's the question. Whether we would leave DS to validate the search itself or do all the pre-check ourselves. To me, doing just one LDAP search and processing the error correctly looks better. But I can live even with your version then, I will leave the framework guardians like Honza or Petr3 to decide. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 486 Lower pki-ca requires to 10.1.2
On 11/19/2014 12:52 PM, Alexander Bokovoy wrote: On Wed, 19 Nov 2014, Martin Kosek wrote: pki-core build in our Copr is finished: https://copr.fedoraproject.org/coprs/mkosek/freeipa/build/60561/ If the patch is OK, it should be committed to ipa-4-1 branch and F21+ Fedora branches. When done, I will trigger SRPM build in Copr. -- Current Dogtag 10.2 and it's requirements are not properly packaged for CentOS, yet. To enable FreeIPA running on CentOS 7.0, lower the Requires on Fedora 20 and CentOS platform on Dogtag 10.1.2 which has the patches required by FreeIPA backported and which has all dependencies avaiable. https://fedorahosted.org/freeipa/ticket/4737 ACK. Pushed to ipa-4-1, F21+, Copr build triggered. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0656-0673 Switch the test suite to pytest
On 11/14/2014 09:55 AM, Petr Viktorin wrote: On 10/29/2014 04:52 PM, Petr Viktorin wrote: On 10/29/2014 01:22 PM, Tomas Babej wrote: On 10/27/2014 04:38 PM, Petr Viktorin wrote: On 10/15/2014 02:58 PM, Petr Viktorin wrote: This almost completes the switch to pytest. There are two missing things: - the details of test results (--with-xunit) are not read correctly by Jenkins. I have a theory I'm investigating here. - the beakerlib integration is still not ready I'll not be available for the rest of the week so I'm sending this early, in case someone wants to take a look. I've updated (and rearranged) the patches after some more testing. Both points above are fixed. Individual plugins are broken out; some would be nice to even release independently of IPA. (There is some demand for the BeakerLib plugin; for that I'd only need to break the dependency on ipa_log_manager.) These depend on my patches 0656-0660. Thanks for this effort! Patch 0656: tests: Use PEP8-compliant setup/teardown method names There are some references to the old names in the test_ipapython and test_install: [tbabej@thinkpad7 ipatests]$ git grep setUpClass [tbabej@thinkpad7 ipatests]$ git grep tearDownClass [tbabej@thinkpad7 ipatests]$ git grep setUp test_install/test_updates.py:def setUp(self): test_ipapython/test_cookie.py:def setUp(self): test_ipapython/test_cookie.py:def setUp(self): test_ipapython/test_cookie.py:def setUp(self): test_ipapython/test_dn.py:def setUp(self): test_ipapython/test_dn.py:def setUp(self): test_ipapython/test_dn.py:def setUp(self): test_ipapython/test_dn.py:def setUp(self): test_ipapython/test_dn.py:def setUp(self): [tbabej@thinkpad7 ipatests]$ git grep tearDown test_install/test_updates.py:def tearDown(self): These are in unittest.testCase. It would be nice to convert those as well, but that's for a larger cleanup. Patch 0657: tests: Add configuration for pytest Shouldn't we rather change the class names? Ideally yes, but I don't think renaming most of our test classes would be worth the benefit. Patch 0658: ipatests.util.ClassChecker: Raise AttributeError in get_subcls ACK. Patch 0659: test_automount_plugin: Fix test ordering ACK. PATCH 0660: Use setup_class/teardown_class in Declarative tests --- a/ipatests/test_ipaserver/test_changepw.py +++ b/ipatests/test_ipaserver/test_changepw.py @@ -33,8 +33,7 @@ class test_changepw(XMLRPC_test, Unauthorized_HTTP_test): app_uri = '/ipa/session/change_password' -def setup(self): -super(test_changepw, self).setup() +def setup(cls): try: api.Command['user_add'](uid=testuser, givenname=u'Test', sn=u'User') api.Command['passwd'](testuser, password=u'old_password') @@ -43,12 +42,11 @@ def setup(self): 'Cannot set up test user: %s' % e ) -def teardown(self): +def teardown(cls): try: api.Command['user_del']([testuser]) except errors.NotFound: pass -super(test_changepw, self).teardown() The setup/teardown methods are not classmethods, so the name of the first argument should remain self. Oops, thanks for the catch! PATCH 0661: dogtag plugin: Don't use doctest syntax for non-doctest examples ACK. PATCH 0662: test_webui: Don't use __init__ for test classes I don't think the following change will work: -def __init__(self, driver=None, config=None): +def setup(self, driver=None, config=None): self.request_timeout = 30 self.driver = driver self.config = config if not config: self.load_config() +self.get_driver().maximize_window() + +def teardown(self): +self.driver.quit() def load_config(self): @@ -161,20 +165,6 @@ def load_config(self): if 'type' not in c: c['type'] = DEFAULT_TYPE -def setup(self): - -Test setup - -if not self.driver: -self.driver = self.get_driver() -self.driver.maximize_window() - -def teardown(self): - -Test clean up - -self.driver.quit() The setup(self) method used to set the self.driver attribute on the class instance, now nothing sets it. The setup method should do: def setup(self, driver=None, config=None): self.request_timeout = 30 self.driver = driver self.config = config if not config: self.load_config()
Re: [Freeipa-devel] FreeIPA Copr repo plan
On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote: 1) What Copr repos do we want to maintain and what should be the expectations? My take: a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+, EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right? Does it fit your needs? It does not install, so no idea. Both the centos-7 tag of https://registry.hub.docker.com/u/adelton/freeipa-server/ and https://registry.hub.docker.com/u/centos/freeipa/ use the IdM in CentOS 7, not FreeIPA from your copr repo, at this point. b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and greatest release, would it make sense to have a Copr repo with *releases* per supported branch to give users a choice? I.e. * mkosek/freeipa-4.1 * mkosek/freeipa-4.0 It is not just users having a choice but the ability to quickly check behaviour on older version when developing or testing regression. These repos are there already, but not used consistently. I do not think we should build all the dependency chain (too much overhead) for older systems (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for these systems if it uses mkosek/freeipa as additional build root in Copr. I don't think it's necessary to build dependency chain to the oldest versions. But if the release was once built on a give OS (as a nightly, for example), we should be able to keep it, including the dependencies. Should it contain daily master builds for all tracked projects (FreeIPA, SSSD, 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across projects mkosek/freeipa-master, someone/sssd-master, someone/389-ds-base-master? Second option may scale better better, the list of such repos may be maintained somewhere (freeipa.org wiki). Having them into separate copr repos would certainly allow better insight into (for example) the dependency chains by people who know how their part should build and install. Currently when we see a huge dependency tree when installing freeipa-server package, it might not be immediatelly obvious, what is causing the possible bloat. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
On 11/19/2014 12:24 PM, Martin Kosek wrote: On 11/19/2014 12:03 PM, Tomas Babej wrote: Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hello, If there is an extra search, will it be done on the same connection/bind ? Testing that an entry exists, even if no attribute are requested, loads the entry in the cache and evaluate the aci. If the entry does not exist, I do not think there is a gain between search(base) and search(subtree). If the entry exists, it will add the overhead of first search (connect/bind/aci) and the benefit of the first search depends if this entry matches the filter. thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
On 11/19/2014 12:51 PM, Martin Kosek wrote: On 11/19/2014 12:41 PM, Tomas Babej wrote: On 11/19/2014 12:24 PM, Martin Kosek wrote: On 11/19/2014 12:03 PM, Tomas Babej wrote: Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? No it does not make all of our LDAP search slower. It only happens for the objects that have parent objects, such as idoverrides or dnsrecords. ... and makes them slower. Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: Up to discussion. We would probably need to introduce a new exception, like ParentObjectNotFound. # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). Look into the get_dn_if_exists, it just wraps around get_dn, so no issue here. Any custom behaviour is preserved. Ah, ok, thanks for info. To sum up, I think this is worth changing this behaviour by default, ignoring a non-matching value of the parent object is not a correct general approach in my opinion. Well, that's the question. Whether we would leave DS to validate the search itself or do all the pre-check ourselves. To me, doing just one LDAP search and processing the error correctly looks better. +1 But I can live even with your version then, I will leave the framework guardians like Honza or Petr3 to decide. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0165] --zonemgr options must be unicode
On 18.11.2014 12:43, David Kupka wrote: On 11/18/2014 12:07 PM, Martin Basti wrote: On 13/11/14 18:28, Martin Basti wrote: To allow IDNA zonemgr email, value must be unicode not ASCII Ticket: https://fedorahosted.org/freeipa/ticket/4724 Patch attached. Patch for ipa-4.0 added. Thanks, works for me, ACK. Pushed to: ipa-4-0: ca6958c348edac53c40423679340967749015dd4 ipa-4-1: 53cf615ad87c6a019eca31a924abd035c375c556 master: d2ffd176176e20860998d29ede4e9bd65f398bf2 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI
On 19/11/14 12:45, Petr Vobornik wrote:
On 13.11.2014 16:49, Martin Basti wrote:
Ticket: https://fedorahosted.org/freeipa/ticket/4647
Patch attached.
The change looses information about the zone apex record. User also
might not know what is the message about because it lacks context.
CLI option name as context is the cause of this bug but it could be
replaced with, e.g., label.
So what about:
Semantic of setting Authoritative nameserver was changed. It's
used only for setting the SOA MNAME attribute.
NS record(s) can be edited in special zone apex record - '@'.
Updated patch attached.
I used NS record(s) can be edited in zone apex - '@'. instead of yours.
--
Martin Basti
From 72abac759e43ca199c2b7dea36d21fca56f75cf3 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Thu, 13 Nov 2014 14:02:02 +0100
Subject: [PATCH] Fix warning message should not contain CLI commands
Message is now universal for both CLI and WebUI
Ticket: https://fedorahosted.org/freeipa/ticket/4647
---
ipalib/messages.py | 4 ++--
ipalib/plugins/dns.py | 9 -
ipatests/test_xmlrpc/test_dns_plugin.py | 9 ++---
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/ipalib/messages.py b/ipalib/messages.py
index 5eeab3c54caf3a7318d89a4aeaee1357fceb787f..102e35275dbe37328c84ecb3cd5b2a8d8578056f 100644
--- a/ipalib/messages.py
+++ b/ipalib/messages.py
@@ -175,8 +175,8 @@ class OptionSemanticChangedWarning(PublicMessage):
errno = 13005
type = warning
-format = _(usemantic of '%(option)s' option was changed:
- u%(current_behavior)s.\n%(hint)s)
+format = _(uSemantic of %(label)s was changed. %(current_behavior)s\n
+ u%(hint)s)
class DNSServerNotRespondingWarning(PublicMessage):
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index dd1e640f4062a32921bf1edf316e122b81a6d485..c5d96a8c4fcdf101254ecefb60cb83d63bee6310 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -2369,11 +2369,10 @@ class dnszone(DNSZoneBase):
messages.add_message(
options['version'],
result, messages.OptionSemanticChangedWarning(
-option=u--name-server,
-current_behavior=_(uthe option is used only for
- usetting up the SOA MNAME attribute),
-hint=_(uTo edit NS record(s) in zone apex, use command
- u'dnsrecord-mod [zone] @ --ns-rec=nameserver'.)
+label=_(usetting Authoritative nameserver),
+current_behavior=_(uIt is used only for setting the
+ uSOA MNAME attribute.),
+hint=_(uNS record(s) can be edited in zone apex - '@'. )
)
)
diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py
index a34d11a3278c67a3d00ca8f59bb8d8d19cf8a46e..fb53853147ecf663cf7015867131445f32364cfb 100644
--- a/ipatests/test_xmlrpc/test_dns_plugin.py
+++ b/ipatests/test_xmlrpc/test_dns_plugin.py
@@ -497,9 +497,12 @@ class test_dns(Declarative):
'objectclass': objectclasses.dnszone,
},
'messages': (
-{'message': usemantic of '--name-server' option was changed: the option is used only for setting up
-u the SOA MNAME attribute.\nTo edit NS record(s) in zone apex, use command
-u'dnsrecord-mod [zone] @ --ns-rec=nameserver'.,
+{'message': uSemantic of setting Authoritative nameserver
+uwas changed.
+uIt is used only for setting the SOA MNAME
+uattribute.\n
+uNS record(s) can be edited in zone
+uapex - '@'. ,
'code': 13005,
'type': u'warning',
'name': u'OptionSemanticChangedWarning'},
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1
On 18.11.2014 23:29, Nathaniel McCallum wrote: On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4645. ACK Shouldn't the version be 10.1.2-4 ? http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1
Dne 19.11.2014 v 13:55 Petr Vobornik napsal(a): On 18.11.2014 23:29, Nathaniel McCallum wrote: On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4645. ACK Shouldn't the version be 10.1.2-4 ? http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 No. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
On 11/19/2014 01:44 PM, Tomas Babej wrote: On 11/19/2014 12:51 PM, Martin Kosek wrote: On 11/19/2014 12:41 PM, Tomas Babej wrote: On 11/19/2014 12:24 PM, Martin Kosek wrote: On 11/19/2014 12:03 PM, Tomas Babej wrote: Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? No it does not make all of our LDAP search slower. It only happens for the objects that have parent objects, such as idoverrides or dnsrecords. ... and makes them slower. What I was pointing out here is that this is not a issue for ALL *-find commands (e.g user-find, group-find will not suffer from it), as you incorrectly stated. I understood that. But it does not make idview-* or dnsrecord-* any faster :-) Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: Up to discussion. We would probably need to introduce a new exception, like ParentObjectNotFound. # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). Look into the get_dn_if_exists, it just wraps around get_dn, so no issue here. Any custom behaviour is preserved. Ah, ok, thanks for info. To sum up, I think this is worth changing this behaviour by default, ignoring a non-matching value of the parent object is not a correct general approach in my opinion. Well, that's the question. Whether we would leave DS to validate the search itself or do all the pre-check ourselves. To me, doing just one LDAP search and processing the error correctly looks better. But I can live even with your version then, I will leave the framework guardians like Honza or Petr3 to decide. I see now what you're trying to suggest. However, the reason boils down to ipaldap.find_entries method not differentiating between a LDAP search that returns error code 32 (No such object) and LDAP search returning error code 0 (Success), but returning no results. In both cases errors.NotFound is raised. The reason I did not go this way is that changing the find_entries method is quite more invasive as this is the method subsenqently called by almost any command. Right. To avoid potential issues, the ParentNotFound would need to be a subclass to NotFoundError so that except NotFound still works. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
Dne 19.11.2014 v 13:44 Tomas Babej napsal(a): On 11/19/2014 12:51 PM, Martin Kosek wrote: On 11/19/2014 12:41 PM, Tomas Babej wrote: On 11/19/2014 12:24 PM, Martin Kosek wrote: On 11/19/2014 12:03 PM, Tomas Babej wrote: Hi, When constructing a parent DN in LDAPSearch, we should always check that the parent object exists (hence use get_dn_if_exists), rather than search on unexistant containers (which can happen with get_dn). Replaces get_dn calls with get_dn_if_exists in *-find commands and makes sure proper error message is raised. https://fedorahosted.org/freeipa/ticket/4659 Doesn't it produce extra LDAP search thus making all our search commands slower? Is that what we want? No it does not make all of our LDAP search slower. It only happens for the objects that have parent objects, such as idoverrides or dnsrecords. ... and makes them slower. What I was pointing out here is that this is not a issue for ALL *-find commands (e.g user-find, group-find will not suffer from it), as you incorrectly stated. Wouldn't it be better to distinguish between LDAP search with no results and LDAP search with missing parent DN? The reply looks different, at least in CLI: Up to discussion. We would probably need to introduce a new exception, like ParentObjectNotFound. # search result search: 4 result: 0 Success # search result search: 4 result: 32 No such object matchedDN: cn=accounts,dc=mkosek-f20,dc=test Also, I do not think you can just stop using get_dn(), some commands override this call to get more complex searches (like host-find searching for shortname). Look into the get_dn_if_exists, it just wraps around get_dn, so no issue here. Any custom behaviour is preserved. Ah, ok, thanks for info. To sum up, I think this is worth changing this behaviour by default, ignoring a non-matching value of the parent object is not a correct general approach in my opinion. Well, that's the question. Whether we would leave DS to validate the search itself or do all the pre-check ourselves. To me, doing just one LDAP search and processing the error correctly looks better. But I can live even with your version then, I will leave the framework guardians like Honza or Petr3 to decide. +1 on single LDAP search and proper error processing. I see now what you're trying to suggest. However, the reason boils down to ipaldap.find_entries method not differentiating between a LDAP search that returns error code 32 (No such object) and LDAP search returning error code 0 (Success), but returning no results. In both cases errors.NotFound is raised. The reason I did not go this way is that changing the find_entries method is quite more invasive as this is the method subsenqently called by almost any command. You can always derive the new error (ParentNotFound or whatever) on NotFound, so old code won't break. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Fix getkeytab operation
On Wed, 19 Nov 2014 12:53:01 +0200 Alexander Bokovoy aboko...@redhat.com wrote: On Tue, 18 Nov 2014, Simo Sorce wrote: On Tue, 18 Nov 2014 15:01:15 -0500 Nathaniel McCallum npmccal...@redhat.com wrote: As I see it, we're setting out a new precedent. All new ASN.1 code will take this route (which is, indeed, better). So while it is small now, it won't stay small forever. Being that we are in the business of routinely handling ASN.1 stuff, this seems to me like a sensible architecture for the future. Ok, I think I should have fixed all the issues you brought up. And my tests still work fine :) Works fine. However, I'm getting wrong TGT enctype back from the KDC when I try to obtain TGT with des-cbc-crc key: [root@master ~]# ipa host-add --force f21test.f21.test - Added host f21test.f21.test - Host name: f21test.f21.test Principal name: host/f21test.f21.t...@f21.test Password: False Keytab: False Managed by: f21test.f21.test [root@master ~]# ipa service-add --force afs/f21test Added service afs/f21t...@f21.test Principal: afs/f21t...@f21.test Managed by: f21test.f21.test [root@master ~]# ipa-getkeytab -s `hostname` -p afs/f21test -k /tmp/afs.keytab -e des-cbc-crc:v4 -P New Principal Password: Verify Principal Password: Keytab successfully retrieved and stored in: /tmp/afs.keytab [root@master ~]# klist -kt /tmp/afs.keytab -K -e Keytab name: FILE:/tmp/afs.keytab KVNO Timestamp Principal - 1 11/19/14 12:13:01 afs/f21t...@f21.test (des-cbc-crc) (0xea1a0b29152cb383) The key is des-cbc-crc [root@master ~]# KRB5_TRACE=/dev/stderr KRB5CCNAME=/tmp/afs.ccache kinit -kt /tmp/afs.keytab afs/f21test [28636] 1416392072.862773: Getting initial credentials for afs/f21t...@f21.test [28636] 1416392072.864408: Looked up etypes in keytab: des-cbc-crc [28636] 1416392072.864522: Sending request (175 bytes) to F21.TEST [28636] 1416392072.865127: Sending initial UDP request to dgram 192.168.5.169:88 [28636] 1416392072.866958: Received answer (283 bytes) from dgram 192.168.5.169:88 [28636] 1416392072.867028: Response was from master KDC [28636] 1416392072.867088: Received error from KDC: -1765328359/Additional pre-authentication required [28636] 1416392072.867140: Processing preauth types: 136, 19, 2, 133 [28636] 1416392072.867175: Selected etype info: etype des-cbc-crc, salt F21.TESTafsf21test, params [28636] 1416392072.867193: Received cookie: MIT [28636] 1416392072.867234: Retrieving afs/f21t...@f21.test from FILE:/tmp/afs.keytab (vno 0, enctype des-cbc-crc) with result: 0/Success [28636] 1416392072.867264: AS key obtained for encrypted timestamp: des-cbc-crc/0BE8 [28636] 1416392072.867304: Encrypted timestamp (for 1416392072.867050): plain 301AA011180F32303134313131393130313433325AA10502030D3AEA, encrypted 1C567557D395C0639CB417EE90C08CD41E4829D910166D62ACEDCC2168C23BAD8C70DFE4CD533A81 [28636] 1416392072.867331: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [28636] 1416392072.867349: Produced preauth for next request: 133, 2 [28636] 1416392072.867372: Sending request (252 bytes) to F21.TEST [28636] 1416392072.867416: Sending initial UDP request to dgram 192.168.5.169:88 [28636] 1416392072.946260: Received answer (649 bytes) from dgram 192.168.5.169:88 [28636] 1416392072.946391: Response was from master KDC [28636] 1416392072.946485: Processing preauth types: 19 [28636] 1416392072.946542: Selected etype info: etype des-cbc-crc, salt F21.TESTafsf21test, params [28636] 1416392072.946593: Produced preauth for next request: (empty) [28636] 1416392072.946626: AS key determined by preauth: des-cbc-crc/0BE8 [28636] 1416392072.946688: Decrypted AS reply; session key is: des-cbc-crc/9B41 [28636] 1416392072.946727: FAST negotiation: available [28636] 1416392072.946793: Initializing FILE:/tmp/afs.ccache with default princ afs/f21t...@f21.test [28636] 1416392072.947118: Removing afs/f21t...@f21.test - krbtgt/f21.t...@f21.test from FILE:/tmp/afs.ccache [28636] 1416392072.947146: Storing afs/f21t...@f21.test - krbtgt/f21.t...@f21.test in FILE:/tmp/afs.ccache [28636] 1416392072.947187: Storing config in FILE:/tmp/afs.ccache for krbtgt/f21.t...@f21.test: fast_avail: yes [28636] 1416392072.947219: Removing afs/f21t...@f21.test - krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST@X-CACHECONF: from FILE:/tmp/afs.ccache [28636] 1416392072.947240: Storing afs/f21t...@f21.test - krb5_ccache_conf_data/fast_avail/krbtgt\/F21.TEST\@F21.TEST@X-CACHECONF: in FILE:/tmp/afs.ccache [28636] 1416392072.947419: Storing config in FILE:/tmp/afs.ccache for krbtgt/f21.t...@f21.test: pa_type: 2 [28636] 1416392072.947458: Removing afs/f21t...@f21.test -
Re: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1
On 19.11.2014 13:59, Jan Cholasta wrote: Dne 19.11.2014 v 13:55 Petr Vobornik napsal(a): On 18.11.2014 23:29, Nathaniel McCallum wrote: On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4645. ACK Shouldn't the version be 10.1.2-4 ? http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 No. ok, nevermind, f21 has 10.2.1-0.1, but it doesn't list the fix in the changelog. But the patch needs a rebase because of Martin's patch. http://koji.fedoraproject.org/koji/buildinfo?buildID=588670 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0078] Enable QR code display by default in otptoken-add
On 18.11.2014 18:27, Petr Vobornik wrote: On 18.11.2014 17:27, Nathaniel McCallum wrote: This patch still needs to land in 4.1.2, so is it okay as it is? I don't think the label is necessary but it doesn't hurt either, at least it's clear, so ACK. Pushed to: master: 3c900ba7a8d98a72ff4e040b688fe3213c722a64 ipa-4-1: 1cd2ca11c5b22dc3bd555e63dba69e9475817872 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 373 Update Requires on pki-ca to 10.2.1-0.1
Dne 19.11.2014 v 14:07 Petr Vobornik napsal(a): On 19.11.2014 13:59, Jan Cholasta wrote: Dne 19.11.2014 v 13:55 Petr Vobornik napsal(a): On 18.11.2014 23:29, Nathaniel McCallum wrote: On Tue, 2014-11-18 at 19:56 +0100, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4645. ACK Shouldn't the version be 10.1.2-4 ? http://koji.fedoraproject.org/koji/buildinfo?buildID=594223 No. ok, nevermind, f21 has 10.2.1-0.1, but it doesn't list the fix in the changelog. But the patch needs a rebase because of Martin's patch. http://koji.fedoraproject.org/koji/buildinfo?buildID=588670 Rebased and pushed to ipa-4-1: 4e1193119b3e7f7c13f504f24445509958887927 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 374 Fix wrong expiration date on renewed IPA CA certificates
On 11/19/2014 08:32 AM, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4717. Honza ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, thanks, ACK. -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0167] DNS: Raise proper exception instead UnicodeError
Ticket: https://fedorahosted.org/freeipa/ticket/4734 Patch attached. -- Martin Basti From 0af7b841365a9d37d4ea67c396ac53ece6982429 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Wed, 19 Nov 2014 14:51:20 +0100 Subject: [PATCH] Raise right exception if domain name is not valid Because of dnspython implementation, in some cases UnicodeError is raised instead of DNS SyntaxError Ticket: https://fedorahosted.org/freeipa/ticket/4734 --- ipapython/dnsutil.py | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/ipapython/dnsutil.py b/ipapython/dnsutil.py index d7841fe2548dd100d51e60ea11bc6e468f3475cf..f08cddad959658a11623a31cb591655f1a5fdabf 100644 --- a/ipapython/dnsutil.py +++ b/ipapython/dnsutil.py @@ -26,15 +26,16 @@ class DNSName(dns.name.Name): labels = None # make pylint happy def __init__(self, labels, origin=None): -if isinstance(labels, str): -#pylint: disable=E1101 -labels = dns.name.from_text(labels, origin).labels -elif isinstance(labels, unicode): -#pylint: disable=E1101 -labels = dns.name.from_unicode(labels, origin).labels -elif isinstance(labels, dns.name.Name): -labels = labels.labels try: +if isinstance(labels, str): +#pylint: disable=E1101 +labels = dns.name.from_text(labels, origin).labels +elif isinstance(labels, unicode): +#pylint: disable=E1101 +labels = dns.name.from_unicode(labels, origin).labels +elif isinstance(labels, dns.name.Name): +labels = labels.labels + super(DNSName, self).__init__(labels) except UnicodeError, e: # dnspython bug, an invalid domain name returns the UnicodeError -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0286] baseldap: Handle missing parent objects properly in *-find
On 11/19/2014 02:03 PM, Jan Cholasta wrote:
Dne 19.11.2014 v 13:44 Tomas Babej napsal(a):
On 11/19/2014 12:51 PM, Martin Kosek wrote:
On 11/19/2014 12:41 PM, Tomas Babej wrote:
On 11/19/2014 12:24 PM, Martin Kosek wrote:
On 11/19/2014 12:03 PM, Tomas Babej wrote:
Hi,
When constructing a parent DN in LDAPSearch, we should always
check that the parent object exists (hence use get_dn_if_exists),
rather than search on unexistant containers (which can happen
with get_dn).
Replaces get_dn calls with get_dn_if_exists in *-find commands
and makes sure proper error message is raised.
https://fedorahosted.org/freeipa/ticket/4659
Doesn't it produce extra LDAP search thus making all our search
commands
slower? Is that what we want?
No it does not make all of our LDAP search slower. It only happens for
the objects that have parent objects, such as idoverrides or
dnsrecords.
... and makes them slower.
What I was pointing out here is that this is not a issue for ALL *-find
commands (e.g user-find, group-find will not suffer from it), as you
incorrectly stated.
Wouldn't it be better to distinguish between LDAP
search with no results and LDAP search with missing parent DN? The
reply looks
different, at least in CLI:
Up to discussion. We would probably need to introduce a new exception,
like ParentObjectNotFound.
# search result
search: 4
result: 0 Success
# search result
search: 4
result: 32 No such object
matchedDN: cn=accounts,dc=mkosek-f20,dc=test
Also, I do not think you can just stop using get_dn(), some
commands override
this call to get more complex searches (like host-find searching
for shortname).
Look into the get_dn_if_exists, it just wraps around get_dn, so no
issue
here. Any custom behaviour is preserved.
Ah, ok, thanks for info.
To sum up, I think this is worth changing this behaviour by default,
ignoring a non-matching value of the parent object is not a correct
general approach in my opinion.
Well, that's the question. Whether we would leave DS to validate the
search
itself or do all the pre-check ourselves. To me, doing just one LDAP
search and
processing the error correctly looks better. But I can live even
with your
version then, I will leave the framework guardians like Honza or
Petr3 to decide.
+1 on single LDAP search and proper error processing.
I see now what you're trying to suggest. However, the reason boils
down to ipaldap.find_entries method not differentiating between a
LDAP search that returns error code 32 (No such object) and LDAP
search returning error code 0 (Success), but returning no results.
In both cases errors.NotFound is raised.
The reason I did not go this way is that changing the find_entries
method
is quite more invasive as this is the method subsenqently called by
almost
any command.
You can always derive the new error (ParentNotFound or whatever) on
NotFound, so old code won't break.
Thanks for the suggestsions.
Attached is a new patch which hooks into find_entries method and
differentiates between the cases.
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 2de4f0020a2a09b6328018652a49d8e4bf6c2c20 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 19 Nov 2014 12:00:07 +0100
Subject: [PATCH] baseldap: Handle missing parent objects properly in *-find
commands
The find_entries function in ipaldap does not differentiate between
a LDAP search that returns error code 32 (No such object) and LDAP
search returning error code 0 (Success), but returning no results.
In both cases errors.NotFound is raised. In turn, LDAPSearch
commands interpret NotFound exception as no results.
To differentiate between the cases, a new error ContainerNotFound
was added, which inherits from NotFound to preserve the compatibility
with the new code.
This error is raised by ipaldap.find_entries in case it is performing
a search with onelevel or subtree scope, and the target dn does not
exist.
https://fedorahosted.org/freeipa/ticket/4659
---
ipalib/errors.py | 16
ipalib/plugins/baseldap.py | 2 ++
ipapython/ipaldap.py | 12 +---
3 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/ipalib/errors.py b/ipalib/errors.py
index f0426583dae2982b661d8c6d1540fe4acea83cef..7436b5e4bce2c024ab7b686a94b6aa124ebb2840 100644
--- a/ipalib/errors.py
+++ b/ipalib/errors.py
@@ -1329,6 +1329,22 @@ class PosixGroupViolation(ExecutionError):
errno = 4030
format = _('This is already a posix group and cannot be converted to external one')
+class ContainerNotFound(NotFound):
+
+**4031** Raised when a container upon which a subtree or one-level search
+ is performed is not found.
+
+For example:
+
+ raise ContainerNotFound(reason='no such entry')
+Traceback (most recent call last):
+ ...
+ContainerNotFound: no such entry
+
+
+
+
Re: [Freeipa-devel] [PATCH] 374 Fix wrong expiration date on renewed IPA CA certificates
Dne 19.11.2014 v 15:02 David Kupka napsal(a): On 11/19/2014 08:32 AM, Jan Cholasta wrote: Hi, the attached patch fixes https://fedorahosted.org/freeipa/ticket/4717. Honza ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Works for me, thanks, ACK. Pushed to: master: 52b141ca6a257b8f12d9ad2ade812ec1bfebf0d7 ipa-4-1: 7aa855a37b1996588d7d2084176e38145b1587be -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0164] Fix warning message should not contain CLI commands due WebUI
On 19.11.2014 13:47, Martin Basti wrote: On 19/11/14 12:45, Petr Vobornik wrote: On 13.11.2014 16:49, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4647 Patch attached. The change looses information about the zone apex record. User also might not know what is the message about because it lacks context. CLI option name as context is the cause of this bug but it could be replaced with, e.g., label. So what about: Semantic of setting Authoritative nameserver was changed. It's used only for setting the SOA MNAME attribute. NS record(s) can be edited in special zone apex record - '@'. Updated patch attached. I used NS record(s) can be edited in zone apex - '@'. instead of yours. ACK Pushed to: master: 310e46452c41223afa0b1b318c503574567df105 ipa-4-1: 38130c632bda27711407f5c74f26031da5b52ad6 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0673 Do not restore SELinux settings that were not backed up
On 18.11.2014 12:17, Petr Viktorin wrote: This fixes https://fedorahosted.org/freeipa/ticket/4678 ACK Pushed to: master: a14ce85357419f41f0994625d29d3f1af7a53d4c ipa-4-1: 1d7407c06caa06119635910d34213167d97125a0 -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0166] Workaround: warning if CA did not start at end of upgrade instead of raising error
On Wed, 19 Nov 2014 10:17:03 +0100 Martin Basti mba...@redhat.com wrote: On 18/11/14 22:01, Martin Kosek wrote: On 11/18/2014 08:20 PM, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4676 Attached patches: * Version A: uses wget to get status of CA * Version B: write warning instead of raising exception (error is false positive, CA is running) I'm open to suggestions which approach is better Martin^2 I like A, but I am concerned why you suddenly ignore the use_proxy option. I added it for a reason as it affects to which port we need to connect, regardless the transport library. See https://fedorahosted.org/freeipa/ticket/3973 where I added this option. Second, I am not happy by you duplicating the XML parsing code, I would rather see it splited in dogtag.py in separate _ca_status_parse or similar function call. Given the obstacles, I am inclining for - pushing B as a safe fix for Fedora 21 Final - fixing issues in A and pushing it for minor release after that to avoid the nasty warning and have some reasonable medium-term fix until the framework migrates to something better than httpslib, line python-requests maybe. Martin Sounds good to me. Patch required for F21 attached. (with proper number) I will send the second patch after release for fedora (or should I sooner?) Martin^2 Ack. simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 788 webui: fix potential XSS vulnerabilities
Escape user defined text to prevent XSS attacks. Extra precaution was
taken to escape also parts which are unlikely to contain user-defined text.
https://fedorahosted.org/freeipa/ticket/4742
resolves CVE-2014-7850
f21 blocker candidate, requires priority review.
--
Petr Vobornik
From 4b60ecf583194c5d2f61a4f6ace992ea3477df05 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Mon, 10 Nov 2014 16:24:15 +0100
Subject: [PATCH] webui: fix potential XSS vulnerabilities
Escape user defined text to prevent XSS attacks. Extra precaution was taken
to escape also parts which are unlikely to contain user-defined text.
fixes CVE-2014-7850
https://fedorahosted.org/freeipa/ticket/4742
---
install/ui/src/freeipa/Application_controller.js | 4 ++--
install/ui/src/freeipa/facet.js | 12 +++-
install/ui/src/freeipa/ipa.js| 1 +
install/ui/src/freeipa/rule.js | 2 +-
install/ui/src/freeipa/widget.js | 4 ++--
5 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/install/ui/src/freeipa/Application_controller.js b/install/ui/src/freeipa/Application_controller.js
index 094bd3da7c4806a316ebe2589b98a523410f4a5f..4bf76f8f56a8e34e330c35956b8922cc3c8f79e3 100644
--- a/install/ui/src/freeipa/Application_controller.js
+++ b/install/ui/src/freeipa/Application_controller.js
@@ -252,12 +252,12 @@ define([
var error_container = $('div/', {
'class': 'container facet-content facet-error'
}).appendTo($('.app-container .content').empty());
-error_container.append('h1'+name+'/h1');
+error_container.append($('h1/', { text: name }));
var details = $('div/', {
'class': 'error-details'
}).appendTo(error_container);
-details.append('p Web UI got in unrecoverable state during '+error.phase+' phase./p');
+details.append($('p/', { text: 'Web UI got in unrecoverable state during ' + error.phase + ' phase' }));
if (error.name) window.console.error(error.name);
if (error.results) {
var msg = error.results.message;
diff --git a/install/ui/src/freeipa/facet.js b/install/ui/src/freeipa/facet.js
index 43627d9d531ed700ff780a0773451eaf17b1cbdd..b0121c75fd58493a3b5f7d1665a985a321fd 100644
--- a/install/ui/src/freeipa/facet.js
+++ b/install/ui/src/freeipa/facet.js
@@ -895,12 +895,12 @@ exp.facet = IPA.facet = function(spec, no_init) {
title = title.replace('${error}', error_thrown.name);
that.error_container.empty();
-that.error_container.append('h1'+title+'/h1');
+that.error_container.append($('h1/', { text: title }));
var details = $('div/', {
'class': 'error-details'
}).appendTo(that.error_container);
-details.append('p'+error_thrown.message+'/p');
+details.append($('p/', { text: error_thrown.message }));
$('div/', {
text: text.get('@i18n:error_report.options')
@@ -932,7 +932,9 @@ exp.facet = IPA.facet = function(spec, no_init) {
}
);
-that.error_container.append('p'+text.get('@i18n:error_report.problem_persists')+'/p');
+that.error_container.append($('p/', {
+text: text.get('@i18n:error_report.problem_persists')
+}));
that.show_error();
};
@@ -1214,7 +1216,7 @@ exp.facet_header = IPA.facet_header = function(spec) {
click: item.handler
}).appendTo(bc_item);
} else {
-bc_item.append(item.text);
+bc_item.text(item.text);
}
return bc_item;
};
@@ -1823,7 +1825,7 @@ exp.table_facet = IPA.table_facet = function(spec, no_init) {
function(xhr, text_status, error_thrown) {
that.load_records([]);
var summary = that.table.summary.empty();
-summary.append(error_thrown.name+': '+error_thrown.message);
+summary.text(error_thrown.name+': '+error_thrown.message);
}
);
};
diff --git a/install/ui/src/freeipa/ipa.js b/install/ui/src/freeipa/ipa.js
index 6d3aeca11dfdaf20935e5c9084c9ed106e6c..137f11e832ff8d0b6dd1b50060f8537c7b117616 100644
--- a/install/ui/src/freeipa/ipa.js
+++ b/install/ui/src/freeipa/ipa.js
@@ -1133,6 +1133,7 @@ IPA.notify = function(message, type, timeout) {
if (typeof message === 'string') {
message = text.get(message);
+message = document.createTextNode(message);
}
var notification_area = $('#notification .notification-area');
diff --git a/install/ui/src/freeipa/rule.js b/install/ui/src/freeipa/rule.js
index 8a2b01963b74e1892ac15127ae0050b35fe6ac27..706827190261efda136f6d1489bdb13543c00f7a 100644
--- a/install/ui/src/freeipa/rule.js
+++ b/install/ui/src/freeipa/rule.js
@@ -91,7 +91,7 @@ IPA.rule_radio_widget = function(spec) {
var
Re: [Freeipa-devel] [PATCHES] Fix getkeytab operation
On Wed, 2014-11-19 at 13:33 -0500, Simo Sorce wrote: - Original Message - From: Alexander Bokovoy aboko...@redhat.com [...] Regarding the patchset itself: Patch 0001: fix 'wuld' in the commit message. The rest is fine. Fixed. Patch 0002: - ticket number is missing in the commit message Added. - perhaps, an instruction how to regenerate asn1 code can be made a Makefile target? We don't need to call it ourselves but this would simplify things in future Added make regenerate target to asn1c makefile - I'm little uncomfortable how ASN_DEBUG() output goes explicitly to stderr but I guess this is something we currently cannot override with DS-specific log printing, so no big deal right now ASN_DEBUG() is currently disabled as EMIT_ASN_DEBUG is undefined, we can later provide a replacement ASN_DEBUG function to hook debugging, but given the same code is used in both DS plugins and ipa-getkeytab binary I did not want to assume anything, and how to wire it up (if we even want to) should probably be discussed at a later time. - any specific need to get asn1/compile committed? We don't commit it in the client code (ipa-client/compile). Added 'compile' to .gitignore in second patch Patch 0003: OK Nothing changed here. I also remembered the patch naming policy :-) so new patch names/numbers are 514,515,516, third revision. ACK from me so long as abokovoy has nothing else. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
