Re: [Freeipa-devel] [PATCH] ca-less tests updated - POC
Hi Jan, Could you take a look at these, whenever you are free? On 10/30/2015 02:57 PM, Oleg Fayans wrote: Hi, The following patches contain updates to ca-less integration tests. It's still a proof of concept: 2 tests still fail seemingly due to the change in target system logic (marked as xfail with "ask jcholast comment") The test output looks like this: $ ipa-run-tests test_integration/test_caless.py --pdb test session starts = platform linux2 -- Python 2.7.10 -- py-1.4.30 -- pytest-2.6.4 plugins: multihost, sourceorder collected 88 items test_integration/test_caless.py ..xx..sssss.ss.xx..ssxx. 53 passed, 29 skipped, 6 xfailed in 5620.17 seconds = Numerous skips correspond to the tests related to ipa-replica-prepare (unsupported under domain level 1) -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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] SPEC: Drop sssd from BuildRequires
On (05/11/15 09:24), Alexander Bokovoy wrote: >On Thu, 05 Nov 2015, Lukas Slebodnik wrote: >>On (04/11/15 18:12), Alexander Bokovoy wrote: >>>On Tue, 03 Nov 2015, Lukas Slebodnik wrote: >From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Mon, 2 Nov 2015 19:52:57 + Subject: [PATCH] SPEC: Drop sssd from BuildRequires Packaging of sssd was changed and more sub-packages are build from sssd.src.rpm. Especially python bindings and development packages are already in sub-packages. As a result of this change the meta package sssd can be removed from BuildRequires without any problem. FreeIPA spec file contained build requirement for latest version of sssd even though the latest sssd was not required for building FreeIPA rpms. In many cases, it was sufficient just to change requirements for FreeIPA packages instead of build requirements. >>>ACK -- we have explicit requirements to separate SSSD components >>>(libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). >>> >>Thank you very much for review. >> >>>Perhaps, telling that your goal is to build without SSSD is somewhat >>>misleading -- SSSD subpackages will be installed anyway and at least >>>1.12.1 will be required. >>> >>Did we test the same patch? >> >>I cannot see installed sssd in build root on rawhide >>http://paste.fedoraproject.org/287115/46707060 >> >>[build@526468c6ceac rpms]$ grep sssd root.log >>[build@526468c6ceac rpms]$ grep 1.13.1-4.fc24 root.log >>DEBUG util.py:393: libipa_hbac x86_64 1.13.1-4.fc24 >>fedora 73 k >>DEBUG util.py:393: libsss_idmap x86_64 1.13.1-4.fc24 >>fedora 77 k >>DEBUG util.py:393: libsss_idmap-devel x86_64 1.13.1-4.fc24 >>fedora 140 k >>DEBUG util.py:393: libsss_nss_idmap x86_64 1.13.1-4.fc24 >>fedora 77 k >>DEBUG util.py:393: libsss_nss_idmap-devel x86_64 1.13.1-4.fc24 >>fedora 125 k >>DEBUG util.py:393: python-libipa_hbac x86_64 1.13.1-4.fc24 >>fedora 68 k >>DEBUG util.py:393: [SKIPPED] python-libipa_hbac-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: [SKIPPED] libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already >>downloaded >>DEBUG util.py:393: [SKIPPED] libsss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: [SKIPPED] libsss_idmap-1.13.1-4.fc24.x86_64.rpm: Already >>downloaded >>DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-1.13.1-4.fc24.x86_64.rpm: >>Already downloaded >>DEBUG util.py:393: Installing : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >>91/241 >>DEBUG util.py:393: Installing : libsss_idmap-1.13.1-4.fc24.x86_64 >>92/241 >>DEBUG util.py:393: Installing : libipa_hbac-1.13.1-4.fc24.x86_64 >>195/241 >>DEBUG util.py:393: Installing : python-libipa_hbac-1.13.1-4.fc24.x86_64 >>212/241 >>DEBUG util.py:393: Installing : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >>224/241 >>DEBUG util.py:393: Installing : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >>225/241 >>DEBUG util.py:393: Verifying : python-libipa_hbac-1.13.1-4.fc24.x86_64 >>19/241 >>DEBUG util.py:393: Verifying : libipa_hbac-1.13.1-4.fc24.x86_64 >>77/241 >>DEBUG util.py:393: Verifying : libsss_idmap-devel-1.13.1-4.fc24.x86_64 >>187/241 >>DEBUG util.py:393: Verifying : libsss_idmap-1.13.1-4.fc24.x86_64 >>188/241 >>DEBUG util.py:393: Verifying : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 >>189/241 >>DEBUG util.py:393: Verifying : libsss_nss_idmap-1.13.1-4.fc24.x86_64 >>190/241 >>DEBUG util.py:393: libipa_hbac.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_idmap.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_idmap-devel.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_nss_idmap.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: libsss_nss_idmap-devel.x86_64 1.13.1-4.fc24 >>DEBUG util.py:393: python-libipa_hbac.x86_64 1.13.1-4.fc24 >> >>and freeipa packages were successfully built. >>http://paste.fedoraproject.org/287118/07222144 >Right and as I said, SSSD subpackages are installed. You listed them >above. That's all we needed. Ahh, I'm sorry. I misread the sentense. I saw "sssd pacakge" instead of "sssd subpackages" LS -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires
On Thu, 05 Nov 2015, Lukas Slebodnik wrote: On (04/11/15 18:12), Alexander Bokovoy wrote: On Tue, 03 Nov 2015, Lukas Slebodnik wrote: From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Mon, 2 Nov 2015 19:52:57 + Subject: [PATCH] SPEC: Drop sssd from BuildRequires Packaging of sssd was changed and more sub-packages are build from sssd.src.rpm. Especially python bindings and development packages are already in sub-packages. As a result of this change the meta package sssd can be removed from BuildRequires without any problem. FreeIPA spec file contained build requirement for latest version of sssd even though the latest sssd was not required for building FreeIPA rpms. In many cases, it was sufficient just to change requirements for FreeIPA packages instead of build requirements. ACK -- we have explicit requirements to separate SSSD components (libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). Thank you very much for review. Perhaps, telling that your goal is to build without SSSD is somewhat misleading -- SSSD subpackages will be installed anyway and at least 1.12.1 will be required. Did we test the same patch? I cannot see installed sssd in build root on rawhide http://paste.fedoraproject.org/287115/46707060 [build@526468c6ceac rpms]$ grep sssd root.log [build@526468c6ceac rpms]$ grep 1.13.1-4.fc24 root.log DEBUG util.py:393: libipa_hbac x86_64 1.13.1-4.fc24 fedora 73 k DEBUG util.py:393: libsss_idmap x86_64 1.13.1-4.fc24 fedora 77 k DEBUG util.py:393: libsss_idmap-devel x86_64 1.13.1-4.fc24 fedora 140 k DEBUG util.py:393: libsss_nss_idmap x86_64 1.13.1-4.fc24 fedora 77 k DEBUG util.py:393: libsss_nss_idmap-devel x86_64 1.13.1-4.fc24 fedora 125 k DEBUG util.py:393: python-libipa_hbac x86_64 1.13.1-4.fc24 fedora 68 k DEBUG util.py:393: [SKIPPED] python-libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_idmap-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: Installing : libsss_nss_idmap-1.13.1-4.fc24.x86_64 91/241 DEBUG util.py:393: Installing : libsss_idmap-1.13.1-4.fc24.x86_64 92/241 DEBUG util.py:393: Installing : libipa_hbac-1.13.1-4.fc24.x86_64 195/241 DEBUG util.py:393: Installing : python-libipa_hbac-1.13.1-4.fc24.x86_64 212/241 DEBUG util.py:393: Installing : libsss_idmap-devel-1.13.1-4.fc24.x86_64 224/241 DEBUG util.py:393: Installing : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 225/241 DEBUG util.py:393: Verifying : python-libipa_hbac-1.13.1-4.fc24.x86_64 19/241 DEBUG util.py:393: Verifying : libipa_hbac-1.13.1-4.fc24.x86_64 77/241 DEBUG util.py:393: Verifying : libsss_idmap-devel-1.13.1-4.fc24.x86_64 187/241 DEBUG util.py:393: Verifying : libsss_idmap-1.13.1-4.fc24.x86_64 188/241 DEBUG util.py:393: Verifying : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 189/241 DEBUG util.py:393: Verifying : libsss_nss_idmap-1.13.1-4.fc24.x86_64 190/241 DEBUG util.py:393: libipa_hbac.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_idmap.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_idmap-devel.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_nss_idmap.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_nss_idmap-devel.x86_64 1.13.1-4.fc24 DEBUG util.py:393: python-libipa_hbac.x86_64 1.13.1-4.fc24 and freeipa packages were successfully built. http://paste.fedoraproject.org/287118/07222144 Right and as I said, SSSD subpackages are installed. You listed them above. That's all we needed. -- / 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] SPEC: Drop sssd from BuildRequires
On (04/11/15 18:12), Alexander Bokovoy wrote: >On Tue, 03 Nov 2015, Lukas Slebodnik wrote: >>>From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 >>From: Lukas Slebodnik >>Date: Mon, 2 Nov 2015 19:52:57 + >>Subject: [PATCH] SPEC: Drop sssd from BuildRequires >> >>Packaging of sssd was changed and more sub-packages are build >>from sssd.src.rpm. Especially python bindings and development packages >>are already in sub-packages. As a result of this change the meta package >>sssd can be removed from BuildRequires without any problem. >> >>FreeIPA spec file contained build requirement for latest version of >>sssd even though the latest sssd was not required for building >>FreeIPA rpms. In many cases, it was sufficient just to change requirements >>for FreeIPA packages instead of build requirements. >ACK -- we have explicit requirements to separate SSSD components >(libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). > Thank you very much for review. >Perhaps, telling that your goal is to build without SSSD is somewhat >misleading -- SSSD subpackages will be installed anyway and at least >1.12.1 will be required. > Did we test the same patch? I cannot see installed sssd in build root on rawhide http://paste.fedoraproject.org/287115/46707060 [build@526468c6ceac rpms]$ grep sssd root.log [build@526468c6ceac rpms]$ grep 1.13.1-4.fc24 root.log DEBUG util.py:393: libipa_hbac x86_64 1.13.1-4.fc24 fedora 73 k DEBUG util.py:393: libsss_idmap x86_64 1.13.1-4.fc24 fedora 77 k DEBUG util.py:393: libsss_idmap-devel x86_64 1.13.1-4.fc24 fedora 140 k DEBUG util.py:393: libsss_nss_idmap x86_64 1.13.1-4.fc24 fedora 77 k DEBUG util.py:393: libsss_nss_idmap-devel x86_64 1.13.1-4.fc24 fedora 125 k DEBUG util.py:393: python-libipa_hbac x86_64 1.13.1-4.fc24 fedora 68 k DEBUG util.py:393: [SKIPPED] python-libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libipa_hbac-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_idmap-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: [SKIPPED] libsss_nss_idmap-1.13.1-4.fc24.x86_64.rpm: Already downloaded DEBUG util.py:393: Installing : libsss_nss_idmap-1.13.1-4.fc24.x86_64 91/241 DEBUG util.py:393: Installing : libsss_idmap-1.13.1-4.fc24.x86_64 92/241 DEBUG util.py:393: Installing : libipa_hbac-1.13.1-4.fc24.x86_64 195/241 DEBUG util.py:393: Installing : python-libipa_hbac-1.13.1-4.fc24.x86_64 212/241 DEBUG util.py:393: Installing : libsss_idmap-devel-1.13.1-4.fc24.x86_64 224/241 DEBUG util.py:393: Installing : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 225/241 DEBUG util.py:393: Verifying : python-libipa_hbac-1.13.1-4.fc24.x86_64 19/241 DEBUG util.py:393: Verifying : libipa_hbac-1.13.1-4.fc24.x86_64 77/241 DEBUG util.py:393: Verifying : libsss_idmap-devel-1.13.1-4.fc24.x86_64 187/241 DEBUG util.py:393: Verifying : libsss_idmap-1.13.1-4.fc24.x86_64 188/241 DEBUG util.py:393: Verifying : libsss_nss_idmap-devel-1.13.1-4.fc24.x86_64 189/241 DEBUG util.py:393: Verifying : libsss_nss_idmap-1.13.1-4.fc24.x86_64 190/241 DEBUG util.py:393: libipa_hbac.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_idmap.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_idmap-devel.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_nss_idmap.x86_64 1.13.1-4.fc24 DEBUG util.py:393: libsss_nss_idmap-devel.x86_64 1.13.1-4.fc24 DEBUG util.py:393: python-libipa_hbac.x86_64 1.13.1-4.fc24 and freeipa packages were successfully built. http://paste.fedoraproject.org/287118/07222144 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] Normalize manager name in user-add
Hi All, Please find the patch for https://fedorahosted.org/freeipa/ticket/5387 Thanks, Abhijeet Kasurde From 4be9fef17e6b31ad2b3ebb496d4a60887ca97b5c Mon Sep 17 00:00:00 2001 From: Abhijeet Kasurde Date: Thu, 5 Nov 2015 12:22:59 +0530 Subject: [PATCH] Added fix to normalize manager name in user-add This fix allows to normalize manager name to human readable name as specified in user-add command instead of actual DN. Fixes: https://fedorahosted.org/freeipa/ticket/5387 Signed-off-by: Abhijeet Kasurde --- ipalib/plugins/baseuser.py | 1 + 1 file changed, 1 insertion(+) diff --git a/ipalib/plugins/baseuser.py b/ipalib/plugins/baseuser.py index b974e3fb18659e7eb6e75557e0d4db3ec1197dcd..a22923048002e1ac38cf007e871d7ee8ffc44da1 100644 --- a/ipalib/plugins/baseuser.py +++ b/ipalib/plugins/baseuser.py @@ -490,6 +490,7 @@ class baseuser_add(LDAPCreate): def post_common_callback(self, ldap, dn, entry_attrs, **options): assert isinstance(dn, DN) +self.obj.convert_manager(entry_attrs, **options) self.obj.convert_usercertificate_post(entry_attrs, **options) class baseuser_del(LDAPDelete): -- 2.4.3 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0062] custodia: ipa-upgrade failed on replica
Hello, Fix for https://fedorahosted.org/freeipa/ticket/5374. I could reproduce it as the Custodia update file was missing from the updates Makefile which in turn was not being packaged into the rpms. Thanks, Gabe From 871822779696ece33f36e6940ecc96fc090b7ea2 Mon Sep 17 00:00:00 2001 From: Gabe Date: Wed, 4 Nov 2015 19:09:58 -0700 Subject: [PATCH] custodia: ipa-upgrade failed on replica - Add 73-custodia.update to install/updates/Makefile.am https://fedorahosted.org/freeipa/ticket/5374 --- install/updates/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/install/updates/Makefile.am b/install/updates/Makefile.am index 04ddeb96de4e88d5909f13b13885d3207184e798..6c8fa11e57a7d2119f837932e72ac13b6224aca7 100644 --- a/install/updates/Makefile.am +++ b/install/updates/Makefile.am @@ -51,6 +51,7 @@ app_DATA =\ 62-ranges.update \ 71-idviews.update \ 72-domainlevels.update \ + 73-custodia.update \ 73-winsync.update \ 90-post_upgrade_plugins.update \ $(NULL) -- 2.5.0 -- 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 0093] perform connectivity checks for all topology suffixes during node deletion
On 11/04/2015 01:30 PM, Martin Babinsky wrote: On 10/30/2015 05:06 PM, Martin Babinsky wrote: On 10/30/2015 03:38 PM, Petr Vobornik wrote: On 10/30/2015 03:26 PM, Martin Babinsky wrote: patch for https://fedorahosted.org/freeipa/ticket/5309 The ticket itself is about connectivity checks in topology suffixes, but there is a code (install/tools/ipa-replica-manage starting at line 788 after applying my patch) which monitors whether the segments pointing to/from the deleted host are already deleted. These checks are currently hardcoded for 'realm' prefix, should we generalize them as well or is it a part of other effort? Could be separate patch but yes. Ok I have included it in the attached patch so that both of these operations are performed for all suffixes. Hmm, I'm thinking whether the 'check_last_link_managed' and 'check_deleted_segments' should not be called per-suffix, but should themselves check all suffixes available. This could make the fix for https://fedorahosted.org/freeipa/ticket/5409 also easier. Depends if the output is reusable. If so then why not. check_last_link_managed basically adds text to several get_topology_connection_errors calls. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] SPEC: Drop sssd from BuildRequires
On Tue, 03 Nov 2015, Lukas Slebodnik wrote: From c466be0e769a80fe204fc70675b8fa0ea3efb7b2 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Mon, 2 Nov 2015 19:52:57 + Subject: [PATCH] SPEC: Drop sssd from BuildRequires Packaging of sssd was changed and more sub-packages are build from sssd.src.rpm. Especially python bindings and development packages are already in sub-packages. As a result of this change the meta package sssd can be removed from BuildRequires without any problem. FreeIPA spec file contained build requirement for latest version of sssd even though the latest sssd was not required for building FreeIPA rpms. In many cases, it was sufficient just to change requirements for FreeIPA packages instead of build requirements. ACK -- we have explicit requirements to separate SSSD components (libsss_idmap, libsss_nss_idmap, python-libipa_hbac, to name a few). Perhaps, telling that your goal is to build without SSSD is somewhat misleading -- SSSD subpackages will be installed anyway and at least 1.12.1 will be required. -- / 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
[Freeipa-devel] [PATCH 0344] Use absolute domain name in detection of A/AAAA records
Patch attached. https://fedorahosted.org/freeipa/ticket/5421 From 5e1ff605e30e0b72bf43d90cd72397ba08e68bd3 Mon Sep 17 00:00:00 2001 From: Martin Basti Date: Wed, 4 Nov 2015 16:09:21 +0100 Subject: [PATCH] Use absolute domain in detection of A/ records Python dns resolver append configured domain to queries which may lead to false positive answer. Exmaple: resolving "ipa.example.com" may return records for "ipa.example.com.example.com" if domain is configured as "example.com" https://fedorahosted.org/freeipa/ticket/5421 --- ipapython/ipautil.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py index 4acdd1a98818bf311a8fef103e7219cc62a28ec1..f04e1a87a8d93486852c5733d97b6ed49c7a7cd7 100644 --- a/ipapython/ipautil.py +++ b/ipapython/ipautil.py @@ -911,6 +911,8 @@ def bind_port_responder(port, socket_type=socket.SOCK_STREAM, socket_timeout=Non raise last_socket_error # pylint: disable=E0702 def is_host_resolvable(fqdn): +if not fqdn.endswith("."): +fqdn = fqdn + "." for rdtype in (rdatatype.A, rdatatype.): try: resolver.query(fqdn, rdtype) -- 2.4.3 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [Update]Time-Based Account Policies
On 04.11.2015 13:46, Stanislav Laznicka wrote: Hi, The fixed patches to Martin^2's and Jakub's reviews are almost ready, there are just a few things left. Martin B. mentioned in his review that '~' might not be the best delimiter for range values in the HBAC time policies language as it is not commonly used for that purpose. I started using it when the negative values were introduced (instead of '-'). The question here is, then, which delimiter would you rather use for ranges? Some choices are ':', '..', and, obviously, '~' but you are free to come up with your own. The delimiters '-' and ',' are not suitable as their use is different here. However small this might seem to be, lets be rigorous here and design it properly. Also, with some time, I got uncertain about one thing with the 'repeat' keyword. What behaviour would you expect when 'repeat' is on yearly repetition and 'dayofweek' is the only other thing set? RFC5545 (iCal) says: " Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time ("DTSTART") component attribute. For example, "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the month or a time. This information would be the same as what is specified for "DTSTART". " and also in an example "... if the BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY, or BYMONTH rule part were missing, the appropriate minute, hour, day, or month would have been retrieved from the "DTSTART" property.", but an example with BYDAY alone set with a day of week without numerical specifier is missing so it is not clear if this would apply to all specified weekdays of a certain month or the whole year. Currently, I am using only the months' weekdays. -- Standa Láznička Hello, we (Standa and I) had offline discussion and I proposed following idea: 1) create new entry in LDAP for "time rule" instead of adding the time rule string directly into HBACRule. This will allow to reuse time rules among various HBAC Rules (and maybe in future with sudo rules, etc.) HBACrule gets only reference to time rule entry stored in LDAP db. 2) Do not create a new time format, just reuse iCal (parts of iCal we need), to store time rule in LDAP in "time rule" entry (Or is possible to not store the values just as one string, we can use different attributes to store separate values, iCal can be used as export and import format) 3) We may provide nice CLI and webUI to construct/show "time rule", this may be more user friendly than just passing the string containing time data to HBAC rule. Martin^2 -- 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] [Update]Time-Based Account Policies
Hi, The fixed patches to Martin^2's and Jakub's reviews are almost ready, there are just a few things left. Martin B. mentioned in his review that '~' might not be the best delimiter for range values in the HBAC time policies language as it is not commonly used for that purpose. I started using it when the negative values were introduced (instead of '-'). The question here is, then, which delimiter would you rather use for ranges? Some choices are ':', '..', and, obviously, '~' but you are free to come up with your own. The delimiters '-' and ',' are not suitable as their use is different here. However small this might seem to be, lets be rigorous here and design it properly. Also, with some time, I got uncertain about one thing with the 'repeat' keyword. What behaviour would you expect when 'repeat' is on yearly repetition and 'dayofweek' is the only other thing set? RFC5545 (iCal) says: " Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time ("DTSTART") component attribute. For example, "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the month or a time. This information would be the same as what is specified for "DTSTART". " and also in an example "... if the BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY, or BYMONTH rule part were missing, the appropriate minute, hour, day, or month would have been retrieved from the "DTSTART" property.", but an example with BYDAY alone set with a day of week without numerical specifier is missing so it is not clear if this would apply to all specified weekdays of a certain month or the whole year. Currently, I am using only the months' weekdays. -- Standa Láznička -- 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 0093] perform connectivity checks for all topology suffixes during node deletion
On 10/30/2015 05:06 PM, Martin Babinsky wrote: On 10/30/2015 03:38 PM, Petr Vobornik wrote: On 10/30/2015 03:26 PM, Martin Babinsky wrote: patch for https://fedorahosted.org/freeipa/ticket/5309 The ticket itself is about connectivity checks in topology suffixes, but there is a code (install/tools/ipa-replica-manage starting at line 788 after applying my patch) which monitors whether the segments pointing to/from the deleted host are already deleted. These checks are currently hardcoded for 'realm' prefix, should we generalize them as well or is it a part of other effort? Could be separate patch but yes. Ok I have included it in the attached patch so that both of these operations are performed for all suffixes. Hmm, I'm thinking whether the 'check_last_link_managed' and 'check_deleted_segments' should not be called per-suffix, but should themselves check all suffixes available. This could make the fix for https://fedorahosted.org/freeipa/ticket/5409 also easier. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0006-0010] Low hanging fruit for #5343 -- platform abstractions
On 11/04/2015 12:58 PM, Tomas Babej wrote: > On 10/21/2015 06:05 PM, Timo Aaltonen wrote: >> On 07.10.2015 17:26, Martin Basti wrote: >>> thanks comments inline >> >> Hey, >> >> I hope these versions address the issues in the first batch.. >> > > Hi Timo, > > this patchset works fine, thanks. > > Seems you generated it in a non-standard way, it could not be applied > directly, as the patch format wasn't detected. It also required a > rebase, but I've solved both issues. > > ACK. > > Tomas > Pushed to master: 43654c973c5977ae55250a30b5652f160b11d590 -- 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 0006-0010] Low hanging fruit for #5343 -- platform abstractions
On 10/21/2015 06:05 PM, Timo Aaltonen wrote: > On 07.10.2015 17:26, Martin Basti wrote: >> thanks comments inline > > Hey, > > I hope these versions address the issues in the first batch.. > Hi Timo, this patchset works fine, thanks. Seems you generated it in a non-standard way, it could not be applied directly, as the patch format wasn't detected. It also required a rebase, but I've solved both issues. ACK. Tomas -- 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 0082] remove Kerberos authenticators after service uninstall
On 10/22/2015 05:32 PM, Petr Spacek wrote: On 21.10.2015 17:55, Martin Babinsky wrote: On 10/13/2015 09:17 AM, Petr Spacek wrote: On 12.10.2015 13:38, Martin Babinsky wrote: each service possessing Kerberos keytab wiil now remove it and destroy any associated credentials cache during its uninstall https://fedorahosted.org/freeipa/ticket/5243 BTW some time ago Simo proposed that we should remove caches and old keytabs during *install* so problems caused by failing uninstallation will be fixed on repeated install. This is yet another step towards idempotent installer. To me this makes more sense than doing so on uninstall. Does it make sense to you, too? Attaching updated patch that does cleanup also before each instance creation. It is a bit ugly I admit, but I couldn't think of a better way to do it and didn't want to poke into service/instance code more than neccesary. NACK, but we are almost there! * kdestroy -A is too aggressive and wipes root's keyring after each run of ipa-*-install utils. * There are some scattered leftovers of ipautil.run['kdestroy'...] in the tree. Please get rid of them. Thank you! Attaching updated patch. It got lost somewhere in the list. -- Martin^3 Babinsky From a6bc5bc86bcf319f26e2103b6d258ec8eb6d2d0c Mon Sep 17 00:00:00 2001 From: Martin Babinsky Date: Fri, 9 Oct 2015 18:08:38 +0200 Subject: [PATCH] remove Kerberos authenticators when installing/uninstalling service instance each service possessing Kerberos keytab/ccache will now perform their removal before service principal creation and during service uninstall https://fedorahosted.org/freeipa/ticket/5243 --- ipaserver/install/adtrustinstance.py | 4 ++-- ipaserver/install/bindinstance.py| 3 +++ ipaserver/install/dnskeysyncinstance.py | 3 +++ ipaserver/install/dsinstance.py | 4 ++-- ipaserver/install/httpinstance.py| 11 ++ ipaserver/install/installutils.py| 37 ipaserver/install/odsexporterinstance.py | 3 +++ 7 files changed, 57 insertions(+), 8 deletions(-) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index f7a7899906ca47b4901881fb6f4099ace1780741..6c083358081de7f5a47cf25f5d13469b2217978a 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -528,6 +528,7 @@ class ADTRUSTInstance(service.Service): self.print_msg("Cannot add CIFS service: %s" % e) self.clean_samba_keytab() +installutils.remove_ccache(paths.KRB5CC_SAMBA) try: ipautil.run(["ipa-getkeytab", "--server", self.fqdn, @@ -918,8 +919,7 @@ class ADTRUSTInstance(service.Service): self.print_msg('WARNING: ' + str(e)) # Remove samba's credentials cache -krb5cc_samba = paths.KRB5CC_SAMBA -installutils.remove_file(krb5cc_samba) +installutils.remove_ccache(ccache_path=paths.KRB5CC_SAMBA) # Remove samba's configuration file installutils.remove_file(self.smb_conf) diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py index 0bc0557cc10a6d32f71cc0426ce350c394216022..51c5d2df4e16b85c68698da45a1c4ce7b10c771d 100644 --- a/ipaserver/install/bindinstance.py +++ b/ipaserver/install/bindinstance.py @@ -1202,3 +1202,6 @@ class BindInstance(service.Service): if named_regular_running: self.named_regular.start() + +installutils.remove_keytab(paths.NAMED_KEYTAB) +installutils.remove_ccache(run_as='named') diff --git a/ipaserver/install/dnskeysyncinstance.py b/ipaserver/install/dnskeysyncinstance.py index 68130c92558a4feb8d08fa826dbf6333d4461d1f..b2ccc027469a352c815963abfd0c0a61dd37297f 100644 --- a/ipaserver/install/dnskeysyncinstance.py +++ b/ipaserver/install/dnskeysyncinstance.py @@ -417,6 +417,7 @@ class DNSKeySyncInstance(service.Service): def __setup_principal(self): assert self.ods_gid is not None +installutils.remove_keytab(paths.IPA_DNSKEYSYNCD_KEYTAB) dnssynckey_principal = "ipa-dnskeysyncd/" + self.fqdn + "@" + self.realm installutils.kadmin_addprinc(dnssynckey_principal) @@ -497,3 +498,5 @@ class DNSKeySyncInstance(service.Service): os.remove(paths.DNSSEC_SOFTHSM_PIN) except Exception: pass + +installutils.remove_keytab(paths.IPA_DNSKEYSYNCD_KEYTAB) diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 15b23a8704091fbcf54e5be52562f6da2eeb1d73..7bdcaea31dcdf593d1de3b98a2ddfb926c2ea990 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -937,8 +937,8 @@ class DsInstance(service.Service): root_logger.debug("Removing DS instance %s" % serverid) try: remove_ds_instance(serverid) -root_logger.debug("Removing DS keytab") -installutils.remove_file(paths.DS_KEYTAB) +
Re: [Freeipa-devel] misleading error message?
On 04.11.2015 11:25, Oleg Fayans wrote: Hi all, Is there a way to switch back to the old (based on ipa-replica-prepare) replica installation workflow having domain level=1? The following error message suggests that it is possible: $ ipa-replica-install --setup-ca --setup-dns --forwarder=10.38.5.26 -P testuser Password for testu...@idm.lab.eng.brq.redhat.com: ipa : ERRORThe Replication Managers group is not available in the domain. Replica promotion requires the use of Replication Managers to be able to replicate data. Upgrade the peer master or use the ipa-replica-prepare command on the master and use a prep file to install this replica. ipa.ipapython.install.cli.install_tool(Replica): ERRORThe ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information It it is not possible (and it is not, AFAIU) we should probably remove the ipa-replica-prepare part from this error message. The second issue with this error message is that adding an unprivileged user just to admins group fixes the promotion, i. e. no neeed in any special "Replication Managers" group. Thus the message is totally misleading. https://fedorahosted.org/freeipa/ticket/5400 https://fedorahosted.org/freeipa/ticket/5399 https://fedorahosted.org/freeipa/ticket/5401 -- 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] misleading error message?
Hi all, Is there a way to switch back to the old (based on ipa-replica-prepare) replica installation workflow having domain level=1? The following error message suggests that it is possible: $ ipa-replica-install --setup-ca --setup-dns --forwarder=10.38.5.26 -P testuser Password for testu...@idm.lab.eng.brq.redhat.com: ipa : ERRORThe Replication Managers group is not available in the domain. Replica promotion requires the use of Replication Managers to be able to replicate data. Upgrade the peer master or use the ipa-replica-prepare command on the master and use a prep file to install this replica. ipa.ipapython.install.cli.install_tool(Replica): ERRORThe ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information It it is not possible (and it is not, AFAIU) we should probably remove the ipa-replica-prepare part from this error message. The second issue with this error message is that adding an unprivileged user just to admins group fixes the promotion, i. e. no neeed in any special "Replication Managers" group. Thus the message is totally misleading. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- 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