From freeipa-github-notification at redhat.com Mon Oct 3 07:06:09 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 03 Oct 2016 09:06:09 +0200 Subject: [Freeipa-devel] [freeipa PR#129][opened] Fix test_util.test_assert_deepequal test Message-ID: URL: https://github.com/freeipa/freeipa/pull/129 Author: stlaz Title: #129: Fix test_util.test_assert_deepequal test Action: opened PR body: """ The test would be failing because recent pretty-print changes that caused the inner members of a dictionary to be printed in a different order. https://fedorahosted.org/freeipa/ticket/6373 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/129/head:pr129 git checkout pr129 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-129.patch Type: text/x-diff Size: 2713 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 3 07:24:56 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 03 Oct 2016 09:24:56 +0200 Subject: [Freeipa-devel] [freeipa PR#117][-ack] Make ipa-replica-install run in interactive mode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/117 Title: #117: Make ipa-replica-install run in interactive mode Label: -ack From freeipa-github-notification at redhat.com Mon Oct 3 07:29:02 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 03 Oct 2016 09:29:02 +0200 Subject: [Freeipa-devel] [freeipa PR#129][synchronized] Fix test_util.test_assert_deepequal test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/129 Author: stlaz Title: #129: Fix test_util.test_assert_deepequal test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/129/head:pr129 git checkout pr129 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-129.patch Type: text/x-diff Size: 2742 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 3 07:35:45 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 03 Oct 2016 09:35:45 +0200 Subject: [Freeipa-devel] [freeipa PR#117][comment] Make ipa-replica-install run in interactive mode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/117 Title: #117: Make ipa-replica-install run in interactive mode jcholast commented: """ NACK, see inline comments. """ See the full comment at https://github.com/freeipa/freeipa/pull/117#issuecomment-251044036 From bind-dyndb-ldap-github-notification at redhat.com Mon Oct 3 08:42:14 2016 From: bind-dyndb-ldap-github-notification at redhat.com (mruprich) Date: Mon, 03 Oct 2016 10:42:14 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#1][comment] Port bind-dyndb-ldap to BIND 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/1 Title: #1: Port bind-dyndb-ldap to BIND 9.11 mruprich commented: """ ACK """ See the full comment at https://github.com/freeipa/bind-dyndb-ldap/pull/1#issuecomment-251054697 From freeipa-github-notification at redhat.com Mon Oct 3 10:15:15 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 03 Oct 2016 12:15:15 +0200 Subject: [Freeipa-devel] [freeipa PR#129][synchronized] Fix test_util.test_assert_deepequal test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/129 Author: stlaz Title: #129: Fix test_util.test_assert_deepequal test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/129/head:pr129 git checkout pr129 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-129.patch Type: text/x-diff Size: 2726 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 3 11:34:35 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 03 Oct 2016 13:34:35 +0200 Subject: [Freeipa-devel] [freeipa PR#129][+ack] Fix test_util.test_assert_deepequal test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/129 Title: #129: Fix test_util.test_assert_deepequal test Label: +ack From freeipa-github-notification at redhat.com Mon Oct 3 11:43:03 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 03 Oct 2016 13:43:03 +0200 Subject: [Freeipa-devel] [freeipa PR#112][comment] The first jab at fixing https://fedorahosted.org/freeipa/ticket/5809 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/112 Title: #112: The first jab at fixing https://fedorahosted.org/freeipa/ticket/5809 martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/4d994bee60560438178ad9f0215f611ca60e32c3 https://fedorahosted.org/freeipa/changeset/ee96384c3ed5d93c8042e05461253e0c2ed5f721 ipa-4-4: https://fedorahosted.org/freeipa/changeset/a6833222ff797ac615a2a41d4845a32d286e1001 https://fedorahosted.org/freeipa/changeset/aed346a3592beb0be95e7d449b34285252bd449c """ See the full comment at https://github.com/freeipa/freeipa/pull/112#issuecomment-251086248 From freeipa-github-notification at redhat.com Mon Oct 3 11:43:05 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 03 Oct 2016 13:43:05 +0200 Subject: [Freeipa-devel] [freeipa PR#112][+pushed] The first jab at fixing https://fedorahosted.org/freeipa/ticket/5809 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/112 Title: #112: The first jab at fixing https://fedorahosted.org/freeipa/ticket/5809 Label: +pushed From freeipa-github-notification at redhat.com Mon Oct 3 11:43:06 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 03 Oct 2016 13:43:06 +0200 Subject: [Freeipa-devel] [freeipa PR#112][closed] The first jab at fixing https://fedorahosted.org/freeipa/ticket/5809 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/112 Author: martbab Title: #112: The first jab at fixing https://fedorahosted.org/freeipa/ticket/5809 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/112/head:pr112 git checkout pr112 From freeipa-github-notification at redhat.com Mon Oct 3 12:25:39 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Mon, 03 Oct 2016 14:25:39 +0200 Subject: [Freeipa-devel] [freeipa PR#130][opened] Added --ip-address paramenter to client installation Message-ID: URL: https://github.com/freeipa/freeipa/pull/130 Author: ofayans Title: #130: Added --ip-address paramenter to client installation Action: opened PR body: """ A record for client machine is only created during client installation if the '--ip-address' parameter is provided. Without A record in some cases replica connection check fails making it impossible to promote the client to replica without '--skip-conncheck' option """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/130/head:pr130 git checkout pr130 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-130.patch Type: text/x-diff Size: 1158 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 3 14:12:51 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 03 Oct 2016 16:12:51 +0200 Subject: [Freeipa-devel] [freeipa PR#130][comment] Added --ip-address paramenter to client installation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/130 Title: #130: Added --ip-address paramenter to client installation mbasti-rh commented: """ It is not true, ipa-client-install is trying to update A records always, not just when IP address option is presented. """ See the full comment at https://github.com/freeipa/freeipa/pull/130#issuecomment-251116343 From freeipa-github-notification at redhat.com Mon Oct 3 15:01:54 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Mon, 03 Oct 2016 17:01:54 +0200 Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Title: #10: Client-side CSR autogeneration LiptonB commented: """ @jcholast, when you get a chance, could you take another look at this and let me know what else is needed? """ See the full comment at https://github.com/freeipa/freeipa/pull/10#issuecomment-251130680 From freeipa-github-notification at redhat.com Tue Oct 4 11:15:02 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 13:15:02 +0200 Subject: [Freeipa-devel] [freeipa PR#122][comment] Acceptance tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/122 Title: #122: Acceptance tests mbasti-rh commented: """ Please see my inline comments, I would not bother with removing DNS tests from suite because they are fast and should not affect CA/KRA """ See the full comment at https://github.com/freeipa/freeipa/pull/122#issuecomment-251360383 From freeipa-github-notification at redhat.com Tue Oct 4 11:49:59 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 04 Oct 2016 13:49:59 +0200 Subject: [Freeipa-devel] [freeipa PR#117][synchronized] Make ipa-replica-install run in interactive mode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/117 Author: stlaz Title: #117: Make ipa-replica-install run in interactive mode Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/117/head:pr117 git checkout pr117 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-117.patch Type: text/x-diff Size: 8343 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 12:09:12 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:09:12 +0200 Subject: [Freeipa-devel] [freeipa PR#130][closed] Added --ip-address paramenter to client installation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/130 Author: ofayans Title: #130: Added --ip-address paramenter to client installation Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/130/head:pr130 git checkout pr130 From freeipa-github-notification at redhat.com Tue Oct 4 12:09:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:09:14 +0200 Subject: [Freeipa-devel] [freeipa PR#130][comment] Added --ip-address paramenter to client installation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/130 Title: #130: Added --ip-address paramenter to client installation mbasti-rh commented: """ I don't see any disagreement so I'm closing this PR """ See the full comment at https://github.com/freeipa/freeipa/pull/130#issuecomment-251370026 From freeipa-github-notification at redhat.com Tue Oct 4 12:09:16 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:09:16 +0200 Subject: [Freeipa-devel] [freeipa PR#130][+rejected] Added --ip-address paramenter to client installation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/130 Title: #130: Added --ip-address paramenter to client installation Label: +rejected From freeipa-github-notification at redhat.com Tue Oct 4 12:12:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:12:14 +0200 Subject: [Freeipa-devel] [freeipa PR#129][+pushed] Fix test_util.test_assert_deepequal test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/129 Title: #129: Fix test_util.test_assert_deepequal test Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 4 12:12:16 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:12:16 +0200 Subject: [Freeipa-devel] [freeipa PR#129][comment] Fix test_util.test_assert_deepequal test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/129 Title: #129: Fix test_util.test_assert_deepequal test mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d70d71846d6eb7d8e6a730965e54e737e7b49f15 ipa-4-4: https://fedorahosted.org/freeipa/changeset/6982929c2053b574e433f6f4f17eaf6694150c21 """ See the full comment at https://github.com/freeipa/freeipa/pull/129#issuecomment-251370644 From freeipa-github-notification at redhat.com Tue Oct 4 12:12:17 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:12:17 +0200 Subject: [Freeipa-devel] [freeipa PR#129][closed] Fix test_util.test_assert_deepequal test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/129 Author: stlaz Title: #129: Fix test_util.test_assert_deepequal test Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/129/head:pr129 git checkout pr129 From freeipa-github-notification at redhat.com Tue Oct 4 12:15:12 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:15:12 +0200 Subject: [Freeipa-devel] [freeipa PR#114][+pushed] Raise errors from service.py:_ldap_mod() by default In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/114 Title: #114: Raise errors from service.py:_ldap_mod() by default Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 4 12:15:13 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:15:13 +0200 Subject: [Freeipa-devel] [freeipa PR#114][comment] Raise errors from service.py:_ldap_mod() by default In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/114 Title: #114: Raise errors from service.py:_ldap_mod() by default mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/c56256e2a29f076e6afa559225a66f58b0773eb5 """ See the full comment at https://github.com/freeipa/freeipa/pull/114#issuecomment-251371213 From freeipa-github-notification at redhat.com Tue Oct 4 12:15:15 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:15:15 +0200 Subject: [Freeipa-devel] [freeipa PR#114][closed] Raise errors from service.py:_ldap_mod() by default In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/114 Author: pspacek Title: #114: Raise errors from service.py:_ldap_mod() by default Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/114/head:pr114 git checkout pr114 From freeipa-github-notification at redhat.com Tue Oct 4 12:15:29 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Tue, 04 Oct 2016 14:15:29 +0200 Subject: [Freeipa-devel] [freeipa PR#131][opened] Fixed script generating certs to address untrusted sub-ca Message-ID: URL: https://github.com/freeipa/freeipa/pull/131 Author: ofayans Title: #131: Fixed script generating certs to address untrusted sub-ca Action: opened PR body: """ Changed the path length from 0 to -1 (unlimited length) https://fedorahosted.org/freeipa/ticket/6348 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/131/head:pr131 git checkout pr131 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-131.patch Type: text/x-diff Size: 874 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 12:18:28 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 14:18:28 +0200 Subject: [Freeipa-devel] [freeipa PR#125][comment] Add iSecStore.span In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/125 Title: #125: Add iSecStore.span mbasti-rh commented: """ Please fix PEP8 error, otherwise LGTM """ See the full comment at https://github.com/freeipa/freeipa/pull/125#issuecomment-251371815 From freeipa-github-notification at redhat.com Tue Oct 4 12:48:09 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 04 Oct 2016 14:48:09 +0200 Subject: [Freeipa-devel] [freeipa PR#132][opened] Draft for a new setup.py (WIP) Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: opened PR body: """ PREVIEW, please don't merge yet. This is my take on FreeIPA's setup.py files. I have moved all common code and constants into ipasetup.py.in and converted all setup.py.in to setup.py. Setup now uses setuptools instead of distutils. I had to move ipa.1 man page to client/man because setuptools does no longer support data_files. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 52115 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 12:51:10 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 04 Oct 2016 14:51:10 +0200 Subject: [Freeipa-devel] [freeipa PR#125][synchronized] Add iSecStore.span In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/125 Author: tiran Title: #125: Add iSecStore.span Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/125/head:pr125 git checkout pr125 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-125.patch Type: text/x-diff Size: 786 bytes Desc: not available URL: From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 4 14:19:27 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Tue, 04 Oct 2016 16:19:27 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#1][synchronized] Port bind-dyndb-ldap to BIND 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/1 Author: pspacek Title: #1: Port bind-dyndb-ldap to BIND 9.11 Action: synchronized To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/1/head:pr1 git checkout pr1 -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pr-1.patch Type: text/x-diff Size: 123182 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 14:44:34 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 04 Oct 2016 16:44:34 +0200 Subject: [Freeipa-devel] [freeipa PR#133][opened] Tests: print what was expected from exceptions and callables in xmlrpc_tests Message-ID: URL: https://github.com/freeipa/freeipa/pull/133 Author: pspacek Title: #133: Tests: print what was expected from exceptions and callables in xmlrpc_tests Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/133/head:pr133 git checkout pr133 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-133.patch Type: text/x-diff Size: 3647 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 15:18:58 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 04 Oct 2016 17:18:58 +0200 Subject: [Freeipa-devel] [freeipa PR#134][opened] DNS URI support Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-134.patch Type: text/x-diff Size: 33710 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 15:19:20 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 04 Oct 2016 17:19:20 +0200 Subject: [Freeipa-devel] [freeipa PR#134][synchronized] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-134.patch Type: text/x-diff Size: 29320 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 16:02:00 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 04 Oct 2016 18:02:00 +0200 Subject: [Freeipa-devel] [freeipa PR#73][+ack] Tests for certificates with SAN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/73 Title: #73: Tests for certificates with SAN Label: +ack From freeipa-github-notification at redhat.com Tue Oct 4 16:03:23 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 04 Oct 2016 18:03:23 +0200 Subject: [Freeipa-devel] [freeipa PR#73][+pushed] Tests for certificates with SAN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/73 Title: #73: Tests for certificates with SAN Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 4 16:03:25 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 04 Oct 2016 18:03:25 +0200 Subject: [Freeipa-devel] [freeipa PR#73][comment] Tests for certificates with SAN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/73 Title: #73: Tests for certificates with SAN martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/4f8e212c428b1fff63f38ea15d7ce9f230085c5c https://fedorahosted.org/freeipa/changeset/7eb78aa8dbc167c36869ddd6cfa525139aff7bbc https://fedorahosted.org/freeipa/changeset/10b4b155b6b411ab339bce92c1a335b4914cfc1c ipa-4-4: https://fedorahosted.org/freeipa/changeset/e607bd000b1593f6824ccc9ca8862eec43c442bb https://fedorahosted.org/freeipa/changeset/3fd233458bc7976790d48374c48d48f27596536e https://fedorahosted.org/freeipa/changeset/5d75842017a917ac7769e5c837bfffa1ba0e1c74 """ See the full comment at https://github.com/freeipa/freeipa/pull/73#issuecomment-251433037 From freeipa-github-notification at redhat.com Tue Oct 4 16:03:26 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 04 Oct 2016 18:03:26 +0200 Subject: [Freeipa-devel] [freeipa PR#73][closed] Tests for certificates with SAN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/73 Author: apophys Title: #73: Tests for certificates with SAN Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/73/head:pr73 git checkout pr73 From freeipa-github-notification at redhat.com Tue Oct 4 16:55:21 2016 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Tue, 04 Oct 2016 18:55:21 +0200 Subject: [Freeipa-devel] [freeipa PR#126][synchronized] Fix ipa migrate-ds when it finds a search reference In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/126 Author: flo-renaud Title: #126: Fix ipa migrate-ds when it finds a search reference Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/126/head:pr126 git checkout pr126 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-126.patch Type: text/x-diff Size: 3827 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 16:58:34 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 18:58:34 +0200 Subject: [Freeipa-devel] [freeipa PR#135][opened] Pylint: remove unused variables from install modules and scripts Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Author: mbasti-rh Title: #135: Pylint: remove unused variables from install modules and scripts Action: opened PR body: """ Would be nice to merge this patch before refactoring of installers starts """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/135/head:pr135 git checkout pr135 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-135.patch Type: text/x-diff Size: 70579 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 16:58:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 18:58:59 +0200 Subject: [Freeipa-devel] [freeipa PR#135][synchronized] Pylint: remove unused variables from install modules and scripts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Author: mbasti-rh Title: #135: Pylint: remove unused variables from install modules and scripts Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/135/head:pr135 git checkout pr135 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-135.patch Type: text/x-diff Size: 63097 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 18:03:20 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 20:03:20 +0200 Subject: [Freeipa-devel] [freeipa PR#135][synchronized] Pylint: remove unused variables from install modules and scripts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Author: mbasti-rh Title: #135: Pylint: remove unused variables from install modules and scripts Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/135/head:pr135 git checkout pr135 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-135.patch Type: text/x-diff Size: 98935 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 18:03:45 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 20:03:45 +0200 Subject: [Freeipa-devel] [freeipa PR#135][edited] Pylint: remove unused variables In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Author: mbasti-rh Title: #135: Pylint: remove unused variables Action: edited Changed field: title Original value: """ Pylint: remove unused variables from install modules and scripts """ From freeipa-github-notification at redhat.com Tue Oct 4 18:11:27 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 20:11:27 +0200 Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support mbasti-rh commented: """ jslint failed please fix it (you can leave pep8 as is, to be consistent with current code) """ See the full comment at https://github.com/freeipa/freeipa/pull/134#issuecomment-251467798 From freeipa-github-notification at redhat.com Tue Oct 4 21:15:50 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 04 Oct 2016 23:15:50 +0200 Subject: [Freeipa-devel] [freeipa PR#136][opened] [WIP] Fix KRA install tests Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Author: mbasti-rh Title: #136: [WIP] Fix KRA install tests Action: opened PR body: """ - in test_installation testsuite KRA related tests were duplicated, this PR removes it - in test_installation test suite with domain level 0, some KRA tests must be skipped because does not work under domain level 0 by design - because in previous commits I decreased amount of replicas in test_installation, I added KRA tests into replication_layout test suite to test how KRA install works with more replicas and various layouts (needed mainly for domain level 0) https://fedorahosted.org/freeipa/ticket/6088 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/136/head:pr136 git checkout pr136 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-136.patch Type: text/x-diff Size: 12480 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 4 22:30:30 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 05 Oct 2016 00:30:30 +0200 Subject: [Freeipa-devel] [freeipa PR#131][comment] Fixed script generating certs to address untrusted sub-ca In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/131 Title: #131: Fixed script generating certs to address untrusted sub-ca frasertweedale commented: """ Obvious ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/131#issuecomment-251532635 From freeipa-github-notification at redhat.com Wed Oct 5 00:59:32 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 05 Oct 2016 02:59:32 +0200 Subject: [Freeipa-devel] [freeipa PR#108][synchronized] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Author: frasertweedale Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/108/head:pr108 git checkout pr108 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-108.patch Type: text/x-diff Size: 3200 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 5 01:01:42 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 05 Oct 2016 03:01:42 +0200 Subject: [Freeipa-devel] [freeipa PR#108][comment] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete frasertweedale commented: """ @mbasti-rh I think the BuildRequires bump is appropriate. If we say (in the doc) that such and such will happen, we want to be sure that they are using the version of Dogtag that actually implements it. """ See the full comment at https://github.com/freeipa/freeipa/pull/108#issuecomment-251556213 From freeipa-github-notification at redhat.com Wed Oct 5 06:41:40 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 05 Oct 2016 08:41:40 +0200 Subject: [Freeipa-devel] [freeipa PR#108][comment] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete mbasti-rh commented: """ IMO for that there is 'Requires' statement. We don't need 10.3.5-6 during build time and IIRC Honza is working on 'Fix IPA dependencies' patch and he will even decrease BuildRequires for pki' """ See the full comment at https://github.com/freeipa/freeipa/pull/108#issuecomment-251594664 From freeipa-github-notification at redhat.com Wed Oct 5 07:20:18 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Wed, 05 Oct 2016 09:20:18 +0200 Subject: [Freeipa-devel] [freeipa PR#131][comment] Fixed script generating certs to address untrusted sub-ca In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/131 Title: #131: Fixed script generating certs to address untrusted sub-ca ofayans commented: """ Please disregard this PR: I've caught a false positive. The issue was not fixed """ See the full comment at https://github.com/freeipa/freeipa/pull/131#issuecomment-251600757 From freeipa-github-notification at redhat.com Wed Oct 5 08:10:44 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Wed, 05 Oct 2016 10:10:44 +0200 Subject: [Freeipa-devel] [freeipa PR#131][synchronized] Fixed script generating certs to address untrusted sub-ca In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/131 Author: ofayans Title: #131: Fixed script generating certs to address untrusted sub-ca Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/131/head:pr131 git checkout pr131 From freeipa-github-notification at redhat.com Wed Oct 5 08:10:46 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Wed, 05 Oct 2016 10:10:46 +0200 Subject: [Freeipa-devel] [freeipa PR#131][closed] Fixed script generating certs to address untrusted sub-ca In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/131 Author: ofayans Title: #131: Fixed script generating certs to address untrusted sub-ca Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/131/head:pr131 git checkout pr131 From freeipa-github-notification at redhat.com Wed Oct 5 08:25:08 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Wed, 05 Oct 2016 10:25:08 +0200 Subject: [Freeipa-devel] [freeipa PR#137][opened] Test: disabled wrong client domain tests for domlevel 0 Message-ID: URL: https://github.com/freeipa/freeipa/pull/137 Author: ofayans Title: #137: Test: disabled wrong client domain tests for domlevel 0 Action: opened PR body: """ These tests are only relevant for domain level 1 https://fedorahosted.org/freeipa/ticket/6382 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/137/head:pr137 git checkout pr137 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-137.patch Type: text/x-diff Size: 905 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 5 08:45:19 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 05 Oct 2016 10:45:19 +0200 Subject: [Freeipa-devel] [freeipa PR#131][+rejected] Fixed script generating certs to address untrusted sub-ca In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/131 Title: #131: Fixed script generating certs to address untrusted sub-ca Label: +rejected From freeipa-github-notification at redhat.com Wed Oct 5 09:15:03 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 05 Oct 2016 11:15:03 +0200 Subject: [Freeipa-devel] [freeipa PR#108][comment] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete frasertweedale commented: """ On Tue, Oct 04, 2016 at 11:41:39PM -0700, mbasti-rh wrote: > IMO for that there is 'Requires' statement. We don't need 10.3.5-6 during build time and IIRC Honza is working on 'Fix IPA dependencies' patch and he will even decrease BuildRequires for pki' > Ah right, yeah. Misunderstood earlier comment. I'll cut a new patch that doesn't touch BuildRequires (neither bumping it, nor removing). Thanks, Fraser > -- > You are receiving this because you authored the thread. > Reply to this email directly or view it on GitHub: > https://github.com/freeipa/freeipa/pull/108#issuecomment-251594664 """ See the full comment at https://github.com/freeipa/freeipa/pull/108#issuecomment-251623433 From freeipa-github-notification at redhat.com Wed Oct 5 09:28:33 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 05 Oct 2016 11:28:33 +0200 Subject: [Freeipa-devel] [freeipa PR#108][synchronized] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Author: frasertweedale Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/108/head:pr108 git checkout pr108 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-108.patch Type: text/x-diff Size: 2835 bytes Desc: not available URL: From ofayans at redhat.com Wed Oct 5 10:02:19 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 5 Oct 2016 12:02:19 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <87cb02c1-9d08-9f1e-25cd-731dd6e21155@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <87cb02c1-9d08-9f1e-25cd-731dd6e21155@redhat.com> Message-ID: Hi Ludwig, Could you please take a look at it when you have time? On 09/13/2016 10:10 AM, Oleg Fayans wrote: > Hi Ludwig, > > The ipa-replica-manage clean-ruv sometimes does not quite work. > > For example: I have a master and 2 replicas. Initial output of > 'ipa-replica-manage list-ruv' looks like this: > > > Replica Update Vectors: > f24replica2.pesen.net:389: 7 > f24master.pesen.net:389: 4 > f24replica1.pesen.net:389: 3 > Certificate Server Replica Update Vectors: > f24master.pesen.net:389: 6 > f24replica1.pesen.net:389: 5 > f24replica2.pesen.net:389: 8 > > > When I do 'ipa-replica-manage clean-ruv 5' and then list-ruv, it shows > the expected result: > > Replica Update Vectors: > f24replica2.pesen.net:389: 7 > f24master.pesen.net:389: 4 > f24replica1.pesen.net:389: 3 > Certificate Server Replica Update Vectors: > f24master.pesen.net:389: 6 > f24replica2.pesen.net:389: 8 > > But when I then do 'ipa-replica-manage clean-ruv 3', the command > executes successfully, but list-ruv still shows 5 RUVs instead of four. > > After all nodes are restarted still 5 RUV's are displaayed, but if I > clean the RUV N 3 manually again, it works and leaves (expected) 4 RUVs. > > Do you have an idea, what it might be and how to debug this? > > > On 08/05/2016 06:36 PM, Martin Basti wrote: >> >> >> On 03.08.2016 14:45, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Thanks for the review! Both patches were updated. >>> >>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>> >>>> >>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Thanks for the review! >>>>> >>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>> before >>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>> feature. >>>>>>> >>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>> One more test was added to the patch-0048 >>>>>>>> >>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases from >>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> IIUC, this will turn off the machine completely, how is cleanup done >>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>> cleanup, so >>>>>> you will not be able to run more tests on the same topology without >>>>>> manual cleanup and manual start. >>>>>> >>>>>> + replica = self.replicas[0] >>>>>> + replica.run_command(['poweroff']) >>>>>> >>>>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>>>> >>>>> Agreed! Fixed. >>>>> >>>>>> >>>>>> Martin^2 >>>>>> >>>>> >>>>> >>>>> >>>> *Automated ipa-replica-manage del tests* >>>> >>>> 1) >>>> + replica.run_command(['ipactl', 'stop']) >>>> + time.sleep(3) >>>> >>>> Why do you need sleep here? >>> >>> Removed, it was left from the old "poweroff" approach >>> >>>> >>>> >>>> 2) >>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>> + '-p', master.config.dirman_password, >>>> + replica_ruvs[0]]) >>>> >>>> Because you are using re.findall(), without any match you will receive >>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>> >>> Implemented the assert which checks that the output contains enough >>> replica RUVs >>> >>>> >>>> 3) >>>> assert(replica.hostname in result1.stdout_text) >>>> >>>> I think that this is error prone. What if there is just error 'could >>>> not >>>> connect to replica ', or something similar. >>>> instead of >>>> listing/cleaning/whatever operation was executed. I think that it >>>> should >>>> be more specific regexp than just finding a replica name substring >>>> (Yes >>>> In IPA we dont always print error so stderr) >>>> >>>> I'm not sure, but probably there might be cases when non critical error >>>> happen and exist status is still 0 >>> >>> Agree. Implemented a regex-based search >>> >>>> >>>> 4) >>>> >>>> + replica.run_command(['poweroff']) >>>> + time.sleep(3) >>>> >>>> There should not be poweroff, probably sleep could be removed too. >>> >>> Gone >>> >>>> >>>> >>>> * Automated clean-ruv subcommand test* >>>> >>>> 1) PEP8, 2 new lines expected >>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>> blank lines, found 0 >>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too long >>>> (85 > 79 characters) >>> >>> Fixed >>> >>>> >>>> >>>> 2) >>>> I dont like doing assert just with count of occurences of substring in >>>> STDOUT, would be possible to improve this somehow? >>> >>> Maybe, but frankly, I don't see how. In this case we are making sure >>> that both simple and CA-specific RUVs of a replica are displayed. The >>> format of the output is strict: >>> Replica Update Vectors: >>> replica1_hostname:389: RUV_id >>> replica2_hostname:389: RUV_id >>> Certificate Server Replica Update Vectors: >>> replica1_hostname:389: RUV_id >>> replica2_hostname:389: RUV_id >>> If we do not see 2 occurrences of the replica hostname than definitely >>> something went wrong >>> >>>> >>>> 3) >>>> I'm not sure if clean-ruv is instant operations or there is some magic >>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>> should be there, but this needs investigation. >>>> >>>> + assert(replica.hostname in result2.stdout_text), ( >>>> + "The wrong RUV was deleted") >>>> + result3 = master.run_command(['ipa-replica-manage', >>>> 'list-ruv', >>>> + '-p', >>>> master.config.dirman_password]) >>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>> + "CA RUV of the replica is still displayed") >>>> >>> >>> Based on my discussion with Stanislav Laznicka, I understood that by >>> default clean-ruv does not return the shell until the operation is >>> finished. You can force dropping into the shell by pressing CTRL+C, in >>> which case the background job will still be running, but this is not >>> the default behavior >>> >> Test failed: >> result4 = master.run_command(['ipa-replica-manage', 'list-ruv', >> '-p', >> master.config.dirman_password]) >>> assert(replica.hostname not in result4.stdout_text), ( >> "replica's RUV is still displayed") >> E AssertionError: replica's RUV is still displayed >> E assert 'replica3.ipa.test' not in 'Replica Update >> V...ipa.test:389: 8\n' >> E 'replica3.ipa.test' is contained here: >> E Replica Update Vectors: >> E \tmaster.ipa.test:389: 4 >> E \treplica3.ipa.test:389: 3 >> E \treplica2.ipa.test:389: 7 >> E Certificate Server Replica Update Vectors: >> E \tmaster.ipa.test:389: 6 >> E \treplica2.ipa.test:389: 8 >> >> >> [root at master ~]# ipa topologysegment-find >> Suffix name: domain >> ------------------ >> 2 segments matched >> ------------------ >> Segment name: master.ipa.test-to-replica2.ipa.test >> Left node: master.ipa.test >> Right node: replica2.ipa.test >> Connectivity: both >> >> Segment name: master.ipa.test-to-replica3.ipa.test >> Left node: master.ipa.test >> Right node: replica3.ipa.test >> Connectivity: both >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> [root at master ~]# ipa-replica-manage list-ruv >> Directory Manager password: >> >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> replica3.ipa.test:389: 3 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> [root at master ~]# >> >> Then I tried manually to clean RUV 3, and it behaves somehow odd >> >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' >> '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> Background task created to clean replication data. This may take a while. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >> [root at master ~]# ipa-replica-manage list-ruv >> Directory Manager password: >> >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> replica3.ipa.test:389: 3 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' >> '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> CLEANALLRUV task for replica id 3 already exists. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> >> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >> No CLEANALLRUV tasks running >> >> No abort CLEANALLRUV tasks running >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' >> '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> Background task created to clean replication data. This may take a while. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >> CLEANALLRUV tasks >> RID 3: Successfully cleaned rid(3). >> >> No abort CLEANALLRUV tasks running >> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> >> >> I'm not sure if this behavior is right, Ludwig may know. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From freeipa-github-notification at redhat.com Wed Oct 5 10:41:19 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 05 Oct 2016 12:41:19 +0200 Subject: [Freeipa-devel] [freeipa PR#137][+ack] Test: disabled wrong client domain tests for domlevel 0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/137 Title: #137: Test: disabled wrong client domain tests for domlevel 0 Label: +ack From freeipa-github-notification at redhat.com Wed Oct 5 12:24:29 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 05 Oct 2016 14:24:29 +0200 Subject: [Freeipa-devel] [freeipa PR#136][synchronized] [WIP] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Author: mbasti-rh Title: #136: [WIP] Fix KRA install tests Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/136/head:pr136 git checkout pr136 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-136.patch Type: text/x-diff Size: 12510 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 5 12:24:48 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 05 Oct 2016 14:24:48 +0200 Subject: [Freeipa-devel] [freeipa PR#136][edited] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Author: mbasti-rh Title: #136: Fix KRA install tests Action: edited Changed field: title Original value: """ [WIP] Fix KRA install tests """ From freeipa-github-notification at redhat.com Wed Oct 5 14:20:30 2016 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Wed, 05 Oct 2016 16:20:30 +0200 Subject: [Freeipa-devel] [freeipa PR#138][opened] Fix ipa-cacert-manage man page Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Author: flo-renaud Title: #138: Fix ipa-cacert-manage man page Action: opened PR body: """ When the admin runs ipa-cacert-manage install, he should also run ipa-certupdate on master/replicas/clients in order to update the certificates databases. The man page should mention this requirement, and also clarify that "install" command does not replace IPA CA but rather installs an additional trusted CA. https://fedorahosted.org/freeipa/ticket/6381 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/138/head:pr138 git checkout pr138 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-138.patch Type: text/x-diff Size: 1426 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 5 14:23:38 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 05 Oct 2016 16:23:38 +0200 Subject: [Freeipa-devel] [freeipa PR#125][+ack] Add iSecStore.span In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/125 Title: #125: Add iSecStore.span Label: +ack From freeipa-github-notification at redhat.com Wed Oct 5 15:59:18 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 05 Oct 2016 17:59:18 +0200 Subject: [Freeipa-devel] [freeipa PR#138][+ack] Fix ipa-cacert-manage man page In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Title: #138: Fix ipa-cacert-manage man page Label: +ack From freeipa-github-notification at redhat.com Wed Oct 5 16:04:21 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 05 Oct 2016 18:04:21 +0200 Subject: [Freeipa-devel] [freeipa PR#139][opened] WebUI: Vault Management Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Author: pvomacka Title: #139: WebUI: Vault Management Action: opened PR body: """ Add vault management into WebUI, there are some constraints: - There is no crypto library so Symmetric and Assymetric vaults are not supported in WebUI. Also retrieving or archiving data is not supported. - There aren't any container support right now Supported is: - Browsing vaults - Adding Standard vaults (users, service, shared) - Removing vaults - Adding and removing owners - Adding and removing members """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/139/head:pr139 git checkout pr139 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-139.patch Type: text/x-diff Size: 48532 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 5 16:08:30 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 05 Oct 2016 18:08:30 +0200 Subject: [Freeipa-devel] [freeipa PR#25][comment] Added install check before executing ipa-* command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/25 Title: #25: Added install check before executing ipa-* command pspacek commented: """ Let's wait for https://github.com/freeipa/freeipa/pull/113 . We will see if it improves things or not. """ See the full comment at https://github.com/freeipa/freeipa/pull/25#issuecomment-251720756 From pvoborni at redhat.com Wed Oct 5 16:40:52 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 5 Oct 2016 18:40:52 +0200 Subject: [Freeipa-devel] 4.4.2 release notes draft Message-ID: <39c1f6f7-5c8a-8235-6dba-d779998afac9@redhat.com> Hi, we planned to release 4.4.2 Today. I'd postpone it to tomorrow morning so you have time to read the RN page. Almost completely auto-generated release notes page: http://www.freeipa.org/page/Releases/4.4.2 Please help to to highlight important bug fixes. Notes: - the only manual part is "Known Issues section" - the script for generating RN will be shared -- Petr Vobornik From dkupka at redhat.com Thu Oct 6 05:10:03 2016 From: dkupka at redhat.com (David Kupka) Date: Thu, 6 Oct 2016 07:10:03 +0200 Subject: [Freeipa-devel] [PATCH 0065] Fix ugly quit during external CA installation In-Reply-To: References: Message-ID: <70f40d81-0b9d-feed-ff88-2018685e5799@redhat.com> On 23/08/16 13:58, Standa Laznicka wrote: > https://fedorahosted.org/freeipa/ticket/6230 > > > Thanks for the patch. This fixes the ugly error message and also the return code, ACK. Pushed to: master: 889f0863b80a0c13a14aa69cd8563b5adde984b2 ipa-4-4: 03a0f5a105f5625e6a4d373abb1f4d8b8044a026 -- David Kupka From freeipa-github-notification at redhat.com Thu Oct 6 06:57:30 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Thu, 06 Oct 2016 08:57:30 +0200 Subject: [Freeipa-devel] [freeipa PR#140][opened] Tests: Remove invalid certplugin tests Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Author: mirielka Title: #140: Tests: Remove invalid certplugin tests Action: opened PR body: """ A bunch of certplugin tests were testing number of revoked certificates with various revocation reasons. Since existence of revoked certificates often depends on other parts of IdM than IPA, it is not really valid to check their presence unless creation of revoked certificate is intentionally tested. https://fedorahosted.org/freeipa/ticket/6349 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/140/head:pr140 git checkout pr140 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-140.patch Type: text/x-diff Size: 3886 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 07:21:35 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Thu, 06 Oct 2016 09:21:35 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Remove invalid certplugin tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Remove invalid certplugin tests pvomacka commented: """ I think that it is not good idea to remove tests, because we are lowering coverage. Therefore NACK. Could we rather rewrite these tests? For example issue certain certificates, revoke them and then test whether there are revoked certs with correct revocation reason. I think that our Tracker could help with it. """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-251886076 From freeipa-github-notification at redhat.com Thu Oct 6 07:32:12 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Thu, 06 Oct 2016 09:32:12 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Remove invalid certplugin tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Remove invalid certplugin tests mirielka commented: """ Hi, I discussed this with Rob who authored the tests and he said that these tests were there just as a kind of checking that no extra revoked certificates get in. Tests are cca 4 years old, revoked certificates do get in e.g. due to changes in Dogtag (they can be created by other tests and can't be deleted) and cert tests fail. Creating new tests as you described (create cert, revoke it and check it's in the database with correct info) could be separate task, since these tests didn't do such think, they just checked what's already in regardless of how it got there. """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-251887928 From freeipa-github-notification at redhat.com Thu Oct 6 07:50:34 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Thu, 06 Oct 2016 09:50:34 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Remove invalid certplugin tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Remove invalid certplugin tests pvomacka commented: """ Yes, that's true and I understand that these tests depend on previous actions. What I actually wanted to say is that I think that we should rather rewrite these tests right now instead of just removing them. """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-251891416 From jcholast at redhat.com Thu Oct 6 08:02:55 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 6 Oct 2016 10:02:55 +0200 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <20160923032906.GY11489@dhcp-40-8.bne.redhat.com> References: <20160808070652.GJ11092@dhcp-40-8.bne.redhat.com> <885c4c72-6e8a-4220-b25e-f577612368d2@redhat.com> <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> <20160816140939.GV23927@dhcp-40-8.bne.redhat.com> <20160819111156.GQ3877@dhcp-40-8.bne.redhat.com> <20160905160506.GF11489@dhcp-40-8.bne.redhat.com> <20160923032906.GY11489@dhcp-40-8.bne.redhat.com> Message-ID: <2b962bda-df01-1a77-3f4d-8ee598155ae8@redhat.com> On 23.9.2016 05:29, Fraser Tweedale wrote: > Bump for review. > > Rebased patches attached (there was a trivial conflict in imports). > > Thanks, > Fraser > > On Tue, Sep 06, 2016 at 02:05:06AM +1000, Fraser Tweedale wrote: >> On Fri, Aug 26, 2016 at 10:28:58AM +0200, Jan Cholasta wrote: >>> On 19.8.2016 13:11, Fraser Tweedale wrote: >>>> Bump for review. >>>> >>>> On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: >>>>> On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: >>>>>> On 16.8.2016 07:24, Fraser Tweedale wrote: >>>>>>> On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: >>>>>>>> On 9.8.2016 16:47, Fraser Tweedale wrote: >>>>>>>>> On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: >>>>>>>>>> On 8.8.2016 09:06, Fraser Tweedale wrote: >>>>>>>>>>> On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 8.8.2016 06:34, Fraser Tweedale wrote: >>>>>>>>>>>>> Please review the attached patch with adds --certificate-out and >>>>>>>>>>>>> --certificate-chain-out options to `ca-show' command. >>>>>>>>>>>>> >>>>>>>>>>>>> Note that --certificate-chain-out currently writes a bogus file due >>>>>>>>>>>>> to a bug in Dogtag that will be fixed in this week's build. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/6178 >>>>>>>>>>>> >>>>>>>>>>>> 1) The client-side *-out options should be defined on the client side, not >>>>>>>>>>>> on the server side. >>>>>>>>>>>> >>>>>>>>>>> Will option defined on client side be propagated to, and observable >>>>>>>>>>> in the ipaserver plugin? The ipaserver plugin needs to observe that >>>>>>>>>>> *-out has been requested and executes additional command(s) on that >>>>>>>>>>> basis. >>>>>>>>>> >>>>>>>>>> Is there a reason not to *always* return the certs? >>>>>>>>>> >>>>>>>>> We hit Dogtag to retrieve them. >>>>>>>> >>>>>>>> I don't think that's an issue in a -show command. >>>>>>>> >>>>>>> cert_show is invoked by other commands (cert_find*, cert_show, >>>>>>> cert_request, cert_status, ca_del) but these all hit Dogtag anyway >>>>>>> so I suppose that's fine. I'll return the cert *and* the chain in >>>>>>> separate attributes, unconditionally. >>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) I don't think there should be additional information included in summary >>>>>>>>>>>> (and it definitely should not be multi-line). I would rather inform the user >>>>>>>>>>>> via an error message when unable to write the files. >>>>>>>>>>>> >>>>>>>>>>> I was just following the pattern of other commands that write certs, >>>>>>>>>>> profile config, etc. Apart from consistency with other commands I >>>>>>>>>>> agree that there is no need to have it. So I will remove it. >>>>>>>>>>> >>>>>>>>>>>> If you think there is an actual value in informing the user about >>>>>>>>>>>> successfully writing the files, please use ipalib.messages for the job. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3) IMO a better format for the certificate chain than PKCS#7 would be >>>>>>>>>>>> concatenated PEM, as that's the most commonly used format in IPA (in >>>>>>>>>>>> installers, there are no cert chains in API commands ATM). >>>>>>>>>>>> >>>>>>>>>>> Sure, but the main use case isn't IPA. Other apps require PKCS #7 >>>>>>>>>>> or concatenated PEMs, but sometimes they must be concatenated >>>>>>>>>>> forward, and othertimes backwards. There is no one size fits all. >>>>>>>>>> >>>>>>>>>> True, which is exactly why I think we should at least be self-consistent and >>>>>>>>>> use concatenated PEM (and multi-value DER over the wire). >>>>>>>>>> >>>>>>>>> Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept >>>>>>>>> header). >>>>>>>>> >>>>>>>>> If we want list-of-PEMs between server and client we have to convert >>>>>>>>> on the server. Do we have a good way of doing this without exec'ing >>>>>>>>> `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' >>>>>>>>> to do the conversion on the server? python-nss does not have PKCS7 >>>>>>>>> functions and I am not keen on adding a pyasn1 PKCS7 parser just for >>>>>>>>> the sake of pushing bits as list-of-PEMs. >>>>>>>> >>>>>>>> I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. >>>>>>>> For example, if we added a call to retrieve external CA chain using certs >>>>>>>> from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to >>>>>>>> PKCS#7 if it was our cert chain format of choice. >>>>>>>> >>>>>>>> What we can avoid though is executing "openssl pkcs7" to do the conversion - >>>>>>>> we can use an approach similar to our DNSSEC code and use python-cffi to >>>>>>>> call libcrypto's PKCS#7 conversion routines instead. >>>>>>>> >>>>>>> I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to >>>>>>> exec `openssl' to do the job :) >>>>>>> >>>>>>> I will transmit DER-encoded PKCS #7 object on the wire; we cannot >>>>>>> used multi-valued DER attribute because order is important. Client >>>>>>> will convert to PEMs. >>>>>> >>>>>> Well, my point was not to send PKCS#7 over the wire, so that clients >>>>>> (including 3rd party clients) do not have to convert from PKCS#7 themselves. >>>>>> >>>>>> In fact we can use multi-valued DER - whatever you send over the wire from >>>>>> the server will be received in the exact same order by the client. Even if >>>>>> it wasn't, you can easily restore the order by matching issuer and subject >>>>>> names of the certificates. >>>>>> >>>>>>> >>>>>>> Should have new patch on list this afternoon. >>>>>>> >>>>>>> Thanks, >>>>>>> Fraser >>>>>>> >>>>>>>>> >>>>>>>>> FWIW, man pages and code suggest that PKCS #7 is accepted in >>>>>>>>> installer, etc. >>>>>>>> >>>>>>>> True, but that's a relatively new feature (since 4.1) and the installer >>>>>>>> internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) >>>>>>>> >>>>>>>>> >>>>>>>>>>> We can add an option to control the format later, but for now, >>>>>>>>>>> Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst >>>>>>>>>>> case is an admin has to invoke `openssl pkcs7' and concat the certs >>>>>>>>>>> themselves. >>>>>>>>>> >>>>>>>>>> AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, >>>>>>>>>> so I'm afraid the worst case would happen virtually always. >>>>>>>>>> >>>>>>>>> If you're OK with invoking OpenSSL on the client to convert PKCS #7 >>>>>>>>> to list-of-PEMs (similar to what is done in >>>>>>>>> ipapython.certdb.NSSDatabase) then we can have the client perform >>>>>>>>> the conversion. >>>>>>>> >>>>>>>> See above. >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 4) Over the wire, the certs should be DER-formatted, as that's the most >>>>>>>>>>>> common wire format in other API commands. >>>>>>>>>>>> >>>>>>>>>>> OK. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5) What is the benefit in having the CA cert and the rest of the chain >>>>>>>>>>>> separate? For end-entity certs it makes sense to separate the cert from the >>>>>>>>>>>> CA chain, but for CA certs, you usually want the full chain, no? >>>>>>>>>>>> >>>>>>>>>>> If you want to anchor trust directly at a subca (e.g. restrict VPN >>>>>>>>>>> login to certs issued by VPN sub-CA) then you often just want the >>>>>>>>>>> cert. The chain option does subsume it, at cost of more work for >>>>>>>>>>> administrators with this use case. I think it makes sense to keep >>>>>>>>>>> both options. >>>>>>>>>> >>>>>>>>>> Does it? From what you described above, you either want just the sub-CA >>>>>>>>>> cert, or the full chain including the sub-CA cert, in which case it might >>>>>>>>>> make more sense to have a single --out option and a --chain flag. >>>>>>>>>> >>>>>>>>> How about --certificate-out which defaults to single cert, but does >>>>>>>>> chain (as list-of-PEMs) when --chain flag given. >>>>>>>>> >>>>>>>>> Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more >>>>>>>>> `--out' options. >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>> Updated patch 0097-2 attached, and new patch 0099 which must be >>>>> applied first. >>>>> >>>>> I have implemented the suggested changes, except for cffi (I execute >>>>> `openssl pkcs7' instead). >>> >>> I don't like it, but OK. Another alternative would be to use pyasn1. >>> >> I don't like it either, but neither did I like the idea of >> reimplementing the wheel with pyasn1. Now is not the time for >> busywork :) >> >>>>> >>>>> There are two new output attributes on the wire, 'certificate' >>>>> (single-value DER X.509), and 'certificate_chain' (ordered >>>>> multi-value DER X.509). They are always returned. The first cert >>>>> in the chain is always the same as 'certificate'; obviously this is >>>>> redunant but I have left it this way because I think usage is >>>>> clearer. >>> >>> I don't have a strong feeling about this one way or the other, but the same >>> scheme should be used for cert-show in the future. Does it make sense to do >>> it this way for cert-show? >>> >>> I'm not sure about always returning the chain in cert-show. Now that we have >>> a --chain flag rather than two out options, maybe we should go back to >>> returning the chain only if --chain is specified. What do you think? >>> >> I think we should go for consistency and always include both over >> the wire. My point exactly - ca-show output should be equivalent to cert-show on the CA certificate, as far as the certificate and chain are concerned. > If we want to hide cert or chain or both at the `ipa' CLI >> depending on options, I also don't feel strongly either way. For >> now they're both displayed. I think I would prefer if the certificate was always returned by the server, but the chain only if --chain (or --all) is specified. Additionally, ca-add should also get the new options and do all of this. >> >>> >>> Patch 0099: >>> >>> 1) Please fix this: >>> >>> $ git show -U0 | pep8 --diff >>> ./ipalib/x509.py:59:80: E501 line too long (93 > 79 characters) >>> >> Done. >> >>> >>> Patch 0097: >>> >>> 1) `certificate` and `certificate_chain` are actually attributes of the ca >>> object, so they should be defined in ca.takes_params rather than >>> ca_show.has_output_params. >>> >> Done. Out of interest, now that they are part of ca_takes_params is >> there a way to hide them by default in CLI output, and only show >> them when `--all' is given? >> >>> >>> 2) Please fix these: >>> >>> $ git show -U0 | pep8 --diff >>> ./ipaclient/plugins/ca.py:21:9: E124 closing bracket does not match visual >>> indentation >>> ./ipaclient/plugins/ca.py:23:13: E128 continuation line under-indented for >>> visual indent >>> ./ipaclient/plugins/ca.py:24:13: E128 continuation line under-indented for >>> visual indent >>> ./ipaclient/plugins/ca.py:25:13: E128 continuation line under-indented for >>> visual indent >>> ./ipaclient/plugins/ca.py:26:9: E124 closing bracket does not match visual >>> indentation >>> ./ipaclient/plugins/ca.py:38:13: E731 do not assign a lambda expression, use >>> a def >>> >> Done. Updated patches attached. >> >> Thanks, >> Fraser > >> From 046b3dd078c4ccc3732a0106786bae4c01d30a89 Mon Sep 17 00:00:00 2001 >> From: Fraser Tweedale >> Date: Tue, 16 Aug 2016 13:16:58 +1000 >> Subject: [PATCH] Add function for extracting PEM certs from PKCS #7 >> >> Add a single function for extracting X.509 certs in PEM format from >> a PKCS #7 object. Refactor sites that execute ``openssl pkcs7`` to >> use the new function. >> >> Part of: https://fedorahosted.org/freeipa/ticket/6178 >> --- >> ipalib/x509.py | 23 +++++++++++++++++- >> ipapython/certdb.py | 14 ++++------- >> ipaserver/install/cainstance.py | 52 +++++++++++++++-------------------------- >> 3 files changed, 45 insertions(+), 44 deletions(-) >> >> diff --git a/ipalib/x509.py b/ipalib/x509.py >> index e986a97a58aafd3aeab08765a397edbf67c7841a..0461553a73e3862c85f1ffcfe4432cabf4fdf7a1 100644 >> --- a/ipalib/x509.py >> +++ b/ipalib/x509.py >> @@ -51,11 +51,14 @@ from ipalib import util >> from ipalib import errors >> from ipaplatform.paths import paths >> from ipapython.dn import DN >> +from ipapython import ipautil >> >> PEM = 0 >> DER = 1 >> >> -PEM_REGEX = re.compile(r'(?<=-----BEGIN CERTIFICATE-----).*?(?=-----END CERTIFICATE-----)', re.DOTALL) >> +PEM_REGEX = re.compile( >> + r'-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----', >> + re.DOTALL) >> >> EKU_SERVER_AUTH = '1.3.6.1.5.5.7.3.1' >> EKU_CLIENT_AUTH = '1.3.6.1.5.5.7.3.2' >> @@ -148,6 +151,24 @@ def load_certificate_list(data, dbdir=None): >> certs = [load_certificate(cert, PEM, dbdir) for cert in certs] >> return certs >> >> + >> +def pkcs7_to_pems(data, datatype=PEM): >> + """ >> + Extract certificates from a PKCS #7 object. >> + >> + Return a ``list`` of X.509 PEM strings. >> + >> + May throw ``ipautil.CalledProcessError`` on invalid data. >> + >> + """ >> + cmd = [ >> + paths.OPENSSL, "pkcs7", "-print_certs", >> + "-inform", "PEM" if datatype == PEM else "DER", >> + ] >> + result = ipautil.run(cmd, stdin=data, capture_output=True) >> + return PEM_REGEX.findall(result.output) >> + >> + >> def load_certificate_list_from_file(filename, dbdir=None): >> """ >> Load a certificate list from a PEM file. >> diff --git a/ipapython/certdb.py b/ipapython/certdb.py >> index e19f712d82f160ebc5de9c5b8d6627cb941c2cef..fd18023794a2daace60efd97aff54180b8409bbd 100644 >> --- a/ipapython/certdb.py >> +++ b/ipapython/certdb.py >> @@ -270,13 +270,11 @@ class NSSDatabase(object): >> continue >> >> if label in ('PKCS7', 'PKCS #7 SIGNED DATA', 'CERTIFICATE'): >> - args = [ >> - paths.OPENSSL, 'pkcs7', >> - '-print_certs', >> - ] >> try: >> - result = ipautil.run( >> - args, stdin=body, capture_output=True) >> + certs = x509.pkcs7_to_pems(body) >> + extracted_certs += '\n'.join(certs) + '\n' >> + loaded = True >> + continue >> except ipautil.CalledProcessError as e: >> if label == 'CERTIFICATE': >> root_logger.warning( >> @@ -287,10 +285,6 @@ class NSSDatabase(object): >> "Skipping PKCS#7 in %s at line %s: %s", >> filename, line, e) >> continue >> - else: >> - extracted_certs += result.output + '\n' >> - loaded = True >> - continue Moving this to the try block is a completely unnecessary change. >> >> if label in ('PRIVATE KEY', 'ENCRYPTED PRIVATE KEY', >> 'RSA PRIVATE KEY', 'DSA PRIVATE KEY', >> diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py >> index c4b8e9ae326fb7ebda9e927cd4d0b5bad9743db4..f57c724b0273a275f8146f0d6055e2ee2e51192c 100644 >> --- a/ipaserver/install/cainstance.py >> +++ b/ipaserver/install/cainstance.py >> @@ -844,44 +844,30 @@ class CAInstance(DogtagInstance): >> # makes openssl throw up. >> data = base64.b64decode(chain) >> >> - result = ipautil.run( >> - [paths.OPENSSL, >> - "pkcs7", >> - "-inform", >> - "DER", >> - "-print_certs", >> - ], stdin=data, capture_output=True) >> - certlist = result.output >> + certlist = x509.pkcs7_to_pems(data, x509.DER) >> >> # Ok, now we have all the certificates in certs, walk through it >> # and pull out each certificate and add it to our database >> >> - st = 1 >> - en = 0 >> - subid = 0 >> ca_dn = DN(('CN','Certificate Authority'), self.subject_base) >> - while st > 0: >> - st = certlist.find('-----BEGIN', en) >> - en = certlist.find('-----END', en+1) >> - if st > 0: >> - try: >> - (chain_fd, chain_name) = tempfile.mkstemp() >> - os.write(chain_fd, certlist[st:en+25]) >> - os.close(chain_fd) >> - (_rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) >> - if subject_dn == ca_dn: >> - nick = get_ca_nickname(self.realm) >> - trust_flags = 'CT,C,C' >> - else: >> - nick = str(subject_dn) >> - trust_flags = ',,' >> - self.__run_certutil( >> - ['-A', '-t', trust_flags, '-n', nick, '-a', >> - '-i', chain_name] >> - ) >> - finally: >> - os.remove(chain_name) >> - subid += 1 >> + for cert in certlist: >> + try: >> + (chain_fd, chain_name) = tempfile.mkstemp() >> + os.write(chain_fd, cert) >> + os.close(chain_fd) >> + (_rdn, subject_dn) = certs.get_cert_nickname(cert) >> + if subject_dn == ca_dn: >> + nick = get_ca_nickname(self.realm) >> + trust_flags = 'CT,C,C' >> + else: >> + nick = str(subject_dn) >> + trust_flags = ',,' >> + self.__run_certutil( >> + ['-A', '-t', trust_flags, '-n', nick, '-a', >> + '-i', chain_name] >> + ) >> + finally: >> + os.remove(chain_name) >> >> def __request_ra_certificate(self): >> # Create a noise file for generating our private key >> -- >> 2.5.5 >> > >> From fba36bd2b86c2aee1d77e05aa563ced4633ab182 Mon Sep 17 00:00:00 2001 >> From: Fraser Tweedale >> Date: Mon, 8 Aug 2016 14:27:20 +1000 >> Subject: [PATCH] Add options to write lightweight CA cert or chain to file >> >> Administrators need a way to retrieve the certificate or certificate >> chain of an IPA-managed lightweight CA. Add params to the `ca' >> object for carrying the CA certificate and chain (as multiple DER >> values), and add the `--certificate-out' option and `--chain' flag >> as client-side options for writing one or the other to a file. >> >> Fixes: https://fedorahosted.org/freeipa/ticket/6178 >> --- >> ipaclient/plugins/ca.py | 50 +++++++++++++++++++++++++++++++++++++++++++++ >> ipaserver/plugins/ca.py | 31 ++++++++++++++++++++++++---- >> ipaserver/plugins/dogtag.py | 12 +++++++++++ >> 3 files changed, 89 insertions(+), 4 deletions(-) >> create mode 100644 ipaclient/plugins/ca.py >> >> diff --git a/ipaclient/plugins/ca.py b/ipaclient/plugins/ca.py >> new file mode 100644 >> index 0000000000000000000000000000000000000000..f7e55dec196495f820ebf745eb49e8ddce6b3ee7 >> --- /dev/null >> +++ b/ipaclient/plugins/ca.py >> @@ -0,0 +1,50 @@ >> +# >> +# Copyright (C) 2016 FreeIPA Contributors see COPYING for license >> +# >> + >> +import base64 >> +from ipaclient.frontend import MethodOverride >> +from ipalib import util, x509, Flag, Str >> +from ipalib.plugable import Registry >> +from ipalib.text import _ >> + >> +register = Registry() >> + >> + >> + at register(override=True, no_fail=True) >> +class ca_show(MethodOverride): >> + >> + takes_options = ( >> + Str( >> + 'certificate_out?', >> + doc=_('Write certificate to file'), >> + include='cli', >> + ), >> + Flag( >> + 'chain', >> + default=False, >> + doc=_('Write certificate chain instead of single certificate'), >> + include='cli', >> + ), >> + ) >> + >> + def forward(self, *keys, **options): >> + filename = None >> + if 'certificate_out' in options: >> + filename = options.pop('certificate_out') >> + util.check_writable_file(filename) >> + chain = options.pop('chain', False) >> + >> + result = super(ca_show, self).forward(*keys, **options) >> + if filename: >> + def to_pem(x): >> + return x509.make_pem(base64.b64encode(x)) >> + if chain: >> + ders = result['result']['certificate_chain'] >> + data = '\n'.join(map(to_pem, ders)) Generator expressions are generally preferred over map(): data = '\n'.join(to_pem(der) for der in ders) >> + else: >> + data = to_pem(result['result']['certificate']) >> + with open(filename, 'wb') as f: >> + f.write(data) >> + >> + return result >> diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py >> index 966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..0684ddaed0ebfcab8910c1ea356550b504af15e2 100644 >> --- a/ipaserver/plugins/ca.py >> +++ b/ipaserver/plugins/ca.py >> @@ -2,14 +2,14 @@ >> # Copyright (C) 2016 FreeIPA Contributors see COPYING for license >> # >> >> -from ipalib import api, errors, DNParam, Str >> +from ipalib import api, errors, Bytes, DNParam, Str >> from ipalib.constants import IPA_CA_CN >> from ipalib.plugable import Registry >> from ipaserver.plugins.baseldap import ( >> LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, >> LDAPUpdate, LDAPRetrieve) >> from ipaserver.plugins.cert import ca_enabled_check >> -from ipalib import _, ngettext >> +from ipalib import _, ngettext, x509 >> >> >> __doc__ = _(""" >> @@ -79,6 +79,18 @@ class ca(LDAPObject): >> doc=_('Issuer Distinguished Name'), >> flags=['no_create', 'no_update'], >> ), >> + Bytes( >> + 'certificate', >> + label=_("Certificate"), >> + doc=_("X.509 certificate"), >> + flags={'no_create', 'no_update', 'no_search', 'no_display'}, Note that the no_display flag currently does nothing. >> + ), >> + Bytes( >> + 'certificate_chain*', >> + label=_("Certificate chain"), >> + doc=_("PKCS #7 certificate chain"), Looks like you forgot to update the doc string. >> + flags={'no_create', 'no_update', 'no_search', 'no_display'}, >> + ), >> ) >> >> permission_filter_objectclasses = ['ipaca'] >> @@ -140,9 +152,20 @@ class ca_find(LDAPSearch): >> class ca_show(LDAPRetrieve): >> __doc__ = _("Display the properties of a CA.") >> >> - def execute(self, *args, **kwargs): >> + def execute(self, *keys, **options): >> ca_enabled_check() >> - return super(ca_show, self).execute(*args, **kwargs) >> + result = super(ca_show, self).execute(*keys, **options) >> + >> + ca_id = result['result']['ipacaid'][0] >> + with self.api.Backend.ra_lightweight_ca as ca_api: >> + result['result']['certificate'] = ca_api.read_ca_cert(ca_id) >> + >> + pkcs7_der = ca_api.read_ca_chain(ca_id) >> + pems = x509.pkcs7_to_pems(pkcs7_der, x509.DER) >> + ders = (x509.normalize_certificate(pem) for pem in pems) >> + result['result']['certificate_chain'] = list(ders) I would think list comprehension is the obvious choice over generator expression when generating a list: ders = [x509.normalize_certificate(pem) for pem in pems] result['result']['certificate_chain'] = ders >> + >> + return result >> >> >> @register() >> diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py >> index aef1e888eb1b6c273c1fd12cbf4912407f8f8132..1fd3106e0ae723eb30dbe32c61e637790f6085d2 100644 >> --- a/ipaserver/plugins/dogtag.py >> +++ b/ipaserver/plugins/dogtag.py >> @@ -2205,6 +2205,18 @@ class ra_lightweight_ca(RestClient): >> except: >> raise errors.RemoteRetrieveError(reason=_("Response from CA was not valid JSON")) >> >> + def read_ca_cert(self, ca_id): >> + status, resp_headers, resp_body = self._ssldo( >> + 'GET', '{}/cert'.format(ca_id), >> + headers={'Accept': 'application/pkix-cert'}) >> + return resp_body >> + >> + def read_ca_chain(self, ca_id): >> + status, resp_headers, resp_body = self._ssldo( >> + 'GET', '{}/chain'.format(ca_id), >> + headers={'Accept': 'application/pkcs7-mime'}) >> + return resp_body >> + >> def disable_ca(self, ca_id): >> self._ssldo( >> 'POST', ca_id + '/disable', >> -- >> 2.5.5 >> -- Jan Cholasta From freeipa-github-notification at redhat.com Thu Oct 6 08:05:16 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Thu, 06 Oct 2016 10:05:16 +0200 Subject: [Freeipa-devel] [freeipa PR#139][synchronized] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Author: pvomacka Title: #139: WebUI: Vault Management Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/139/head:pr139 git checkout pr139 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-139.patch Type: text/x-diff Size: 48596 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 08:12:12 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 06 Oct 2016 10:12:12 +0200 Subject: [Freeipa-devel] [freeipa PR#113][comment] ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/113 Title: #113: ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri stlaz commented: """ NACK, please see the review comment. """ See the full comment at https://github.com/freeipa/freeipa/pull/113#issuecomment-251895399 From freeipa-github-notification at redhat.com Thu Oct 6 08:18:54 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 06 Oct 2016 10:18:54 +0200 Subject: [Freeipa-devel] [freeipa PR#135][comment] Pylint: remove unused variables In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Title: #135: Pylint: remove unused variables stlaz commented: """ A refactoring ticket needs opening for the issues with find_entries mentioned here. Tests seem to pass, so ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/135#issuecomment-251896732 From freeipa-github-notification at redhat.com Thu Oct 6 08:19:00 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 06 Oct 2016 10:19:00 +0200 Subject: [Freeipa-devel] [freeipa PR#135][+ack] Pylint: remove unused variables In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Title: #135: Pylint: remove unused variables Label: +ack From freeipa-github-notification at redhat.com Thu Oct 6 08:26:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:26:14 +0200 Subject: [Freeipa-devel] [freeipa PR#138][comment] Fix ipa-cacert-manage man page In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Title: #138: Fix ipa-cacert-manage man page mbasti-rh commented: """ Is this written in IdM guide, if not IMO it would be nice to open doc bug in BZ and add this info there as well """ See the full comment at https://github.com/freeipa/freeipa/pull/138#issuecomment-251898208 From freeipa-github-notification at redhat.com Thu Oct 6 08:35:56 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:35:56 +0200 Subject: [Freeipa-devel] [freeipa PR#128][+pushed] Properly handle LDAP socket closures in ipa-otpd In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/128 Title: #128: Properly handle LDAP socket closures in ipa-otpd Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 6 08:35:57 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:35:57 +0200 Subject: [Freeipa-devel] [freeipa PR#128][comment] Properly handle LDAP socket closures in ipa-otpd In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/128 Title: #128: Properly handle LDAP socket closures in ipa-otpd mbasti-rh commented: """ Fixed upstream ipa-4-4: https://fedorahosted.org/freeipa/changeset/304300fd870fb990b513815380ba2474703e29ab master: https://fedorahosted.org/freeipa/changeset/0756ce7d53133793b82674757e125524eede4721 """ See the full comment at https://github.com/freeipa/freeipa/pull/128#issuecomment-251900298 From freeipa-github-notification at redhat.com Thu Oct 6 08:35:58 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:35:58 +0200 Subject: [Freeipa-devel] [freeipa PR#128][closed] Properly handle LDAP socket closures in ipa-otpd In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/128 Author: npmccallum Title: #128: Properly handle LDAP socket closures in ipa-otpd Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/128/head:pr128 git checkout pr128 From freeipa-github-notification at redhat.com Thu Oct 6 08:39:42 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:39:42 +0200 Subject: [Freeipa-devel] [freeipa PR#125][+pushed] Add iSecStore.span In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/125 Title: #125: Add iSecStore.span Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 6 08:39:44 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:39:44 +0200 Subject: [Freeipa-devel] [freeipa PR#125][comment] Add iSecStore.span In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/125 Title: #125: Add iSecStore.span mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/ac94d32c4fd543e33211c0331330c80c619e0058 """ See the full comment at https://github.com/freeipa/freeipa/pull/125#issuecomment-251901106 From freeipa-github-notification at redhat.com Thu Oct 6 08:39:46 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:39:46 +0200 Subject: [Freeipa-devel] [freeipa PR#125][closed] Add iSecStore.span In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/125 Author: tiran Title: #125: Add iSecStore.span Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/125/head:pr125 git checkout pr125 From freeipa-github-notification at redhat.com Thu Oct 6 08:44:08 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:44:08 +0200 Subject: [Freeipa-devel] [freeipa PR#135][+pushed] Pylint: remove unused variables In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Title: #135: Pylint: remove unused variables Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 6 08:44:09 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:44:09 +0200 Subject: [Freeipa-devel] [freeipa PR#135][comment] Pylint: remove unused variables In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Title: #135: Pylint: remove unused variables mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d9375881460d63cdd696bb0705da0ac205db9870 https://fedorahosted.org/freeipa/changeset/135047d03c1780d682998369aaa531585b39a069 """ See the full comment at https://github.com/freeipa/freeipa/pull/135#issuecomment-251902017 From freeipa-github-notification at redhat.com Thu Oct 6 08:44:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:44:11 +0200 Subject: [Freeipa-devel] [freeipa PR#135][closed] Pylint: remove unused variables In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/135 Author: mbasti-rh Title: #135: Pylint: remove unused variables Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/135/head:pr135 git checkout pr135 From freeipa-github-notification at redhat.com Thu Oct 6 08:47:29 2016 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Thu, 06 Oct 2016 10:47:29 +0200 Subject: [Freeipa-devel] [freeipa PR#138][comment] Fix ipa-cacert-manage man page In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Title: #138: Fix ipa-cacert-manage man page flo-renaud commented: """ Hi, thanks for your comment. Yes, the IDM guide is currently being updated to describe this requirement. See [lastSuccessfulBuild](http://jenkinscat.gsslab.pnq.redhat.com:8080/view/RHEL7/job/doc-Red_Hat_Enterprise_Linux-7-Linux_Domain_Identity_Authentication_and_Policy_Guide%20(html-single)/lastSuccessfulBuild/artifact/tmp/en-US/html-single/index.html#manual-cert-install). """ See the full comment at https://github.com/freeipa/freeipa/pull/138#issuecomment-251902783 From freeipa-github-notification at redhat.com Thu Oct 6 08:54:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 10:54:11 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Draft for a new setup.py (WIP) mbasti-rh commented: """ This WIP works for me, I like that we get rid of setup.py.in files. I'm looking forward to final version Please fix PEP8 reported error and my inline comments """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-251904240 From freeipa-github-notification at redhat.com Thu Oct 6 09:03:07 2016 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Thu, 06 Oct 2016 11:03:07 +0200 Subject: [Freeipa-devel] [freeipa PR#138][comment] Fix ipa-cacert-manage man page In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Title: #138: Fix ipa-cacert-manage man page flo-renaud commented: """ Hi, thanks for your comment. Yes, the IDM guide is currently being updated to describe this requirement. See [lastSuccessfulBuild](http://jenkinscat.gsslab.pnq.redhat.com:8080/view/RHEL7/job/doc-Red_Hat_Enterprise_Linux-7-Linux_Domain_Identity_Authentication_and_Policy_Guide%20(html-single)/lastSuccessfulBuild/artifact/tmp/en-US/html-single/index.html#manual-cert-install). """ See the full comment at https://github.com/freeipa/freeipa/pull/138#issuecomment-251902783 From freeipa-github-notification at redhat.com Thu Oct 6 09:22:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 11:22:01 +0200 Subject: [Freeipa-devel] [freeipa PR#115][+ack] Don't show traceback when ipa config file is not an absolute path In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/115 Title: #115: Don't show traceback when ipa config file is not an absolute path Label: +ack From freeipa-github-notification at redhat.com Thu Oct 6 09:26:45 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 11:26:45 +0200 Subject: [Freeipa-devel] [freeipa PR#108][+ack] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete Label: +ack From freeipa-github-notification at redhat.com Thu Oct 6 09:51:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 11:51:59 +0200 Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support mbasti-rh commented: """ NACK, please see inline comments """ See the full comment at https://github.com/freeipa/freeipa/pull/134#issuecomment-251916849 From sbose at redhat.com Thu Oct 6 10:49:30 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Oct 2016 12:49:30 +0200 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates Message-ID: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> Hi, I've started to write a SSSD design page about enhancing the current mapping of certificates to users and how to select/match a suitable certificate if multiple certificates are on a Smartcard. My currently thoughts and idea and be found at https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates and for your convenience below as well. Comments and suggestions are welcome. Please let me know about concerns, alternatives and missing use-cases/user-stories. bye, Sumit = Matching and Mapping Certificates = Related ticket(s): * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping === Problem statement === ==== Mapping ==== Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. ==== Matching ==== Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. === Use cases === ==== Mapping ==== In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: * Certificates/Smartcards are issued externally * LDAP schema extension is not possible or not allowed ==== Matching ==== A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. === Overview of the solution === To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. === Implementation details === ==== Matching ==== The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are * regular-expression * regular-expression * regular-expression * extended-key-usage-list * key-usage-list and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate. '''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?''' While and are (imo) already quite flexible I can see some potential extensions for the other components. and in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless). The component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with ==== Mapping ==== Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case. If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|". A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g. * * Currently I see no usage for , and in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add based mappings. '''Question, do we need search-and-replace at all (or at this stage)? Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of might be tricky as discussed below. Nevertheless the following might be possible: * /regexp/replacement/ * /regexp/replacement/ '''where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like {{{ /^CN=\([^,]*\).*$/\1/ }}} '''would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. '''The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expressions.html#g-regex-replace g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. ''' ===== Some notes about DNs ===== The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the * X.500 order: DC=com,DC=example,CN=users,CN=Certuser or in the * LDAP order: CN=Certuser,CN=Users,DC=example,DC=com As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111). This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP) Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user at example.com', certtool as 'EMAIL=user at example.com' and certutil as 'E=user at example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]: * CN commonName (2.5.4.3) * L localityName (2.5.4.7) * ST stateOrProvinceName (2.5.4.8) * O organizationName (2.5.4.10) * OU organizationalUnitName (2.5.4.11) * C countryName (2.5.4.6) * STREET streetAddress (2.5.4.9) * DC domainComponent (0.9.2342.19200300.100.1.25) * UID userId (0.9.2342.19200300.100.1.1) ==== About restricting or enforcing the mapping an matching any further ==== The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing. Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together. In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in. But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from. So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in. ==== Storing matching and mapping configuration ==== On the IPA server a new objectclass can be created to store an matching-mapping rule pair. Both attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping. Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule. ===== Examples ===== * '''certificate_rules = {msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with * '''certificate_rules = {1.3.6.1.4.1.311.20.2.2}''': see above * '''certificate_rules = {*my-company**@my-company.com$}{}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user. === Configuration changes === Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for. === How To Test === This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus. === How To Debug === Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for. === Authors === Give credit to authors of the design in this section. From freeipa-github-notification at redhat.com Thu Oct 6 10:57:17 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 12:57:17 +0200 Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support mbasti-rh commented: """ I was able to add an invalid URI record ``` [root at vm-058-017 ~]# ipa dnsrecord-add test.zone. --uri-rec='0 0 trolo"lo' Record name: test2 Record name: test2 URI record: 0 0 "trolo"lo" [root at vm-058-017 ~]# dig +short test2.test.zone. URI [root at vm-058-017 ~]# journalctl output failed to parse RR entry: resource record DN 'idnsname=test2,idnsname=test.zone.,cn=dns,dc=blabla' data '0 0 "trolo"lo"': extra input text ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/134#issuecomment-251930458 From freeipa-github-notification at redhat.com Thu Oct 6 11:04:02 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Thu, 06 Oct 2016 13:04:02 +0200 Subject: [Freeipa-devel] [freeipa PR#123][+ack] Tests: Remove silent deleting and creating entries by tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/123 Title: #123: Tests: Remove silent deleting and creating entries by tracker Label: +ack From freeipa-github-notification at redhat.com Thu Oct 6 11:04:14 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Thu, 06 Oct 2016 13:04:14 +0200 Subject: [Freeipa-devel] [freeipa PR#123][comment] Tests: Remove silent deleting and creating entries by tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/123 Title: #123: Tests: Remove silent deleting and creating entries by tracker apophys commented: """ Looks good, thanks. """ See the full comment at https://github.com/freeipa/freeipa/pull/123#issuecomment-251931803 From freeipa-github-notification at redhat.com Thu Oct 6 11:10:44 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Thu, 06 Oct 2016 13:10:44 +0200 Subject: [Freeipa-devel] [freeipa PR#141][opened] Tests: Fix failing test_ipalib/test_parameters Message-ID: URL: https://github.com/freeipa/freeipa/pull/141 Author: mirielka Title: #141: Tests: Fix failing test_ipalib/test_parameters Action: opened PR body: """ Parameters test fails because of KeyError caused by improper manipulation with kwargs in Param.__init__ method. During initialization, if kwargs['required'] or kwargs['multivalue'] is None, it is delete from dictionary and hence the missing key. Small change of the condition prevents this from happening. Partially fixes https://fedorahosted.org/freeipa/ticket/6292 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/141/head:pr141 git checkout pr141 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-141.patch Type: text/x-diff Size: 1156 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 11:16:13 2016 From: freeipa-github-notification at redhat.com (alichbox) Date: Thu, 06 Oct 2016 13:16:13 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Remove invalid certplugin tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Remove invalid certplugin tests alichbox commented: """ Ok, I would vote for the new tests and when we have them merged we can safely delete this part of code that is not relevant anymore. The reason we would leave the current (not relevant tests) here is to not loose the information that we need to cover that part. So my proposal: 1) leave these tests here as they are; 2) write new test suite; 3) delete the old tests; Does it make sense? """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-251933994 From freeipa-github-notification at redhat.com Thu Oct 6 11:19:32 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Thu, 06 Oct 2016 13:19:32 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Remove invalid certplugin tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Remove invalid certplugin tests mirielka commented: """ Ok, I will do it like Ales proposed and will sync this PR when new tests are ready. """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-251934592 From freeipa-github-notification at redhat.com Thu Oct 6 12:04:12 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 06 Oct 2016 14:04:12 +0200 Subject: [Freeipa-devel] [freeipa PR#134][synchronized] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-134.patch Type: text/x-diff Size: 31157 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 12:13:55 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 14:13:55 +0200 Subject: [Freeipa-devel] [freeipa PR#133][comment] Tests: print what was expected from exceptions and callables in xmlrpc_tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/133 Title: #133: Tests: print what was expected from exceptions and callables in xmlrpc_tests mbasti-rh commented: """ Please set proper patch author, otherwise LGTM """ See the full comment at https://github.com/freeipa/freeipa/pull/133#issuecomment-251944193 From freeipa-github-notification at redhat.com Thu Oct 6 12:23:10 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 06 Oct 2016 14:23:10 +0200 Subject: [Freeipa-devel] [freeipa PR#142][opened] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Author: dkupka Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Action: opened PR body: """ Missing attributes in instance created by pickle.load cause AttributeError in second part of ipa-server-install --external-ca. https://fedorahosted.org/freeipa/ticket/6385 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/142/head:pr142 git checkout pr142 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-142.patch Type: text/x-diff Size: 1588 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 12:27:40 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 06 Oct 2016 14:27:40 +0200 Subject: [Freeipa-devel] [freeipa PR#134][synchronized] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-134.patch Type: text/x-diff Size: 31796 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 12:37:47 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 06 Oct 2016 14:37:47 +0200 Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support pspacek commented: """ I was playing with an idea of automatic escaping but it cannot be done with current record format: There is no way to distinguish alredy escaped text from a text which needs escaping. This totally breaks web UI edit workflow because it reads text from LDAP, fills text field with it and then double-escapes it during save. For this reason I've given up attempts to automatically escape things, which is no different from e.g. TXT records. Call it consistency if you want ;-) """ See the full comment at https://github.com/freeipa/freeipa/pull/134#issuecomment-251949022 From freeipa-github-notification at redhat.com Thu Oct 6 12:39:03 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 06 Oct 2016 14:39:03 +0200 Subject: [Freeipa-devel] [freeipa PR#134][synchronized] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-134.patch Type: text/x-diff Size: 31663 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 12:40:35 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 14:40:35 +0200 Subject: [Freeipa-devel] [freeipa PR#142][comment] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling mbasti-rh commented: """ IMO here (__init__ of CheckedIPAddress) is missing self._net = addr._net it may cause issues ``` if isinstance(addr, CheckedIPAddress): self.prefixlen = addr.prefixlen return ``` and self._net should be handled in parent class """ See the full comment at https://github.com/freeipa/freeipa/pull/142#issuecomment-251949631 From pvoborni at redhat.com Thu Oct 6 12:43:05 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 6 Oct 2016 14:43:05 +0200 Subject: [Freeipa-devel] 4.4.2 release notes draft In-Reply-To: <39c1f6f7-5c8a-8235-6dba-d779998afac9@redhat.com> References: <39c1f6f7-5c8a-8235-6dba-d779998afac9@redhat.com> Message-ID: <598c288d-31a7-8e43-9a55-b1edffd3b902@redhat.com> On 10/05/2016 06:40 PM, Petr Vobornik wrote: > Hi, > > we planned to release 4.4.2 Today. I'd postpone it to tomorrow morning > so you have time to read the RN page. > > Almost completely auto-generated release notes page: > http://www.freeipa.org/page/Releases/4.4.2 > > Please help to to highlight important bug fixes. > > Notes: > - the only manual part is "Known Issues section" > - the script for generating RN will be shared > The release will be postponed because of regression introduced in 4.4.2: - https://fedorahosted.org/freeipa/ticket/6385 -- Petr Vobornik From freeipa-github-notification at redhat.com Thu Oct 6 12:49:13 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 06 Oct 2016 14:49:13 +0200 Subject: [Freeipa-devel] [freeipa PR#134][synchronized] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-134.patch Type: text/x-diff Size: 38185 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 13:31:56 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Thu, 06 Oct 2016 15:31:56 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Remove invalid certplugin tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Remove invalid certplugin tests pvomacka commented: """ Hi alichbox, I agree with steps you are proposing, it does make sense. """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-251962169 From freeipa-github-notification at redhat.com Thu Oct 6 13:35:00 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 06 Oct 2016 15:35:00 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 52396 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 13:38:56 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 06 Oct 2016 15:38:56 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Draft for a new setup.py (WIP) tiran commented: """ @mbasti-rh I have removed more hacks and made each setup.py even simpler. """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-251963879 From freeipa-github-notification at redhat.com Thu Oct 6 14:24:21 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 16:24:21 +0200 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management mbasti-rh commented: """ I'm not sure if this is done on purpose, but Vault section is shown there even I have no KRA installed in topology, and I'm getting error ``` An error has occurred (IPA Error 3000: InvocationError) KRA service is not enabled ``` It is not nice, IMO some placeholder pointing to ipa-kra-install could be better """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-251978110 From rcritten at redhat.com Thu Oct 6 14:33:48 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 6 Oct 2016 10:33:48 -0400 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <57F660CC.5030801@redhat.com> Sumit Bose wrote: > Hi, > > I've started to write a SSSD design page about enhancing the current > mapping of certificates to users and how to select/match a suitable > certificate if multiple certificates are on a Smartcard. > > My currently thoughts and idea and be found at > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates > and for your convenience below as well. > > Comments and suggestions are welcome. Please let me know about concerns, > alternatives and missing use-cases/user-stories. > > bye, > Sumit > > = Matching and Mapping Certificates = > > Related ticket(s): > * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping > > === Problem statement === > ==== Mapping ==== > Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. > > ==== Matching ==== > Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. > > === Use cases === > ==== Mapping ==== > In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: > * Certificates/Smartcards are issued externally > * LDAP schema extension is not possible or not allowed > > ==== Matching ==== > A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. > > === Overview of the solution === > To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. > > > === Implementation details === > ==== Matching ==== > The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are > > * regular-expression > * regular-expression > * regular-expression > * extended-key-usage-list > * key-usage-list > > and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate. > > '''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?''' > > While and are (imo) already quite flexible I can see some potential extensions for the other components. > > and in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless). > > The component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with > > ==== Mapping ==== > Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case. > > If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|". > > A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g. > * > * > > Currently I see no usage for , and in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add based mappings. > > > '''Question, do we need search-and-replace at all (or at this stage)? Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of might be tricky as discussed below. Nevertheless the following might be possible: > > * /regexp/replacement/ > * /regexp/replacement/ > > '''where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like > {{{ > /^CN=\([^,]*\).*$/\1/ > }}} > '''would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. > > '''The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expressions.html#g-regex-replace g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. > ''' > > ===== Some notes about DNs ===== > The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the > * X.500 order: DC=com,DC=example,CN=users,CN=Certuser > or in the > * LDAP order: CN=Certuser,CN=Users,DC=example,DC=com > > As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111). > > This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP) > > Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user at example.com', certtool as 'EMAIL=user at example.com' and certutil as 'E=user at example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]: > * CN commonName (2.5.4.3) > * L localityName (2.5.4.7) > * ST stateOrProvinceName (2.5.4.8) > * O organizationName (2.5.4.10) > * OU organizationalUnitName (2.5.4.11) > * C countryName (2.5.4.6) > * STREET streetAddress (2.5.4.9) > * DC domainComponent (0.9.2342.19200300.100.1.25) > * UID userId (0.9.2342.19200300.100.1.1) > > ==== About restricting or enforcing the mapping an matching any further ==== > The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing. > > Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together. > > In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in. > > But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from. > > So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in. > > ==== Storing matching and mapping configuration ==== > On the IPA server a new objectclass can be created to store an matching-mapping rule pair. Both attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping. > > Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule. > > ===== Examples ===== > * '''certificate_rules = {msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with > * '''certificate_rules = {1.3.6.1.4.1.311.20.2.2}''': see above > * '''certificate_rules = {*my-company**@my-company.com$}{}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user. > > > === Configuration changes === > Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for. > > === How To Test === > This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus. > > === How To Debug === > Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for. > > === Authors === > Give credit to authors of the design in this section. > Wow, this is really great. I think I'd pre-plan to support different configuration per issuer subject, with one named default. It shouldn't be a lot more work and will future-proof things for you, particularly in how the rules are stored in LDAP. I worry a bit about matching without comparing the certificate for the case where you don't examine issuer. You may want to have an option to require that the presented cert match the one stored in LDAP (off by default). I realize that you specifically mention this can be problematic, but it can also be quite useful. It can be used, for example, to disable a login by removing the certificate from the user's entry. It also ensures that some carefully crafted certificate doesn't allow a bad actor to map to a user account. rob From freeipa-github-notification at redhat.com Thu Oct 6 14:47:23 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 06 Oct 2016 16:47:23 +0200 Subject: [Freeipa-devel] [freeipa PR#143][opened] Issue6386 nss dir Message-ID: URL: https://github.com/freeipa/freeipa/pull/143 Author: tiran Title: #143: Issue6386 nss dir Action: opened PR body: """ See https://fedorahosted.org/freeipa/ticket/6386 * use api.env.nss_dir in all ipaclient plugins * set api.env.nss_dir to confdir/nssdb """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/143/head:pr143 git checkout pr143 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-143.patch Type: text/x-diff Size: 4585 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 6 15:25:26 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 06 Oct 2016 17:25:26 +0200 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management pvoborni commented: """ For other optional UIs like CA/Trusts or DNS, Web UI checks on UI start if the component is installed by batch command with: ```JavaScript {method: "env", params: [[], {}]} {method: "dns_is_enabled", params: [[], {}]} {method: "trustconfig_show", params: [[], {}]} {method: "domainlevel_get", params: [[], {}]} {method: "ca_is_enabled", params: [[], {}]} ``` For KRA, it can add kra_is_enabled command. Traditionally, UI is hidden if component is not installed. """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-251997063 From sbose at redhat.com Thu Oct 6 15:57:13 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Oct 2016 17:57:13 +0200 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <57F660CC.5030801@redhat.com> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <57F660CC.5030801@redhat.com> Message-ID: <20161006155713.GC1843@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Oct 06, 2016 at 10:33:48AM -0400, Rob Crittenden wrote: > Sumit Bose wrote: > > Hi, > > > > > > Wow, this is really great. Hi Rob, thank you for the feedback. > > I think I'd pre-plan to support different configuration per issuer subject, > with one named default. It shouldn't be a lot more work and will > future-proof things for you, particularly in how the rules are stored in > LDAP. > > I worry a bit about matching without comparing the certificate for the case > where you don't examine issuer. > Do I understand it correctly that you are looking for rules which will always and only match for certificate from a given issuer? E.g. if all matching rules will have the set like CN=ca,DC=abd,DC=comclientAuth CN=ca,DC=def,DC=commsScLogin certificates from the abc issue must have clientAuth set to be valid for authentication and certificates from issuer def must have msScLogin set. But you are right, if one rule does not have issuer set like CN=ca,DC=abd,DC=comclientAuth msScLogin then a certificate from issuer abc which does not have clientAuth set but msScLogin would be accepted as well. Do you think it would help to make a required field but allow that the lazy admin can just enter a '*' to match any issuer? > You may want to have an option to require that the presented cert match the > one stored in LDAP (off by default). I realize that you specifically mention > this can be problematic, but it can also be quite useful. It can be used, > for example, to disable a login by removing the certificate from the user's > entry. It also ensures that some carefully crafted certificate doesn't allow > a bad actor to map to a user account. This happens when no mapping rule is given. Then SSSD will fall back to search/map the user with the whole certificate. And if the certificate is removed from the LDAP entry of the user Smartcard authentication will fail as soon as the user entry in the cache of SSSD is expired. bye, Sumit > > rob From freeipa-github-notification at redhat.com Thu Oct 6 16:29:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 18:29:59 +0200 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management mbasti-rh commented: """ 1) I created shared vault, but I cannot see it in 'Shared Vaults', it is show only in 'My Vaults' i.e. it was created ad user vault according CLI 2) 'My Vaults' I expected that it will show all vaults created by me, but it is not true, it shows only my user vaults. Can we set name to more explicit, like 'My User Vaults' or is it too much and only I'm dumb? 3) I broke it, I cannot add vault, adder dialog just show and instantly disappears Steps to reproduce: a. click on add vault b. click on vault user, mark empty line (dont click) c. press ESC (dialog should disappear) d. click on add Vault again, it should not work e. dialog suddenly shows when you click on My Vaults No errors in browser console. What could cause this? 4) Can you please add tests for this? 5) Nitpick If you add vault from Service vault, then predefined value should be service vault in adder dialog. Same for shared vault 6) Missing 'type' column in my vaults 7) For symmetric vault, there is 'salt' shown in CLI, and I can change this in CLI. IMO this should be supported in webUI too 8) For asymetric vault, public key is show in CLI, and user can also change this public key, IMO this should work in webUI too. 9) I would like to see big fat warning in adder dialog that content of 'standard' vaults can be seen by users with higher privileges (admins). This is the reason why we set symmetric vault as default in CLI. But because in webUI the standard vault is the only one vault that can be added, we should inform users to use rather CLI and create symmetric vault * IMO we should add this warning into CLI too 10) Vaultconfig-show shows transport certificate, should we shown this in webUI as well? """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-252016356 From freeipa-github-notification at redhat.com Thu Oct 6 16:37:48 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 18:37:48 +0200 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management mbasti-rh commented: """ Yeah, and I forgot to write: 11) There should be an information in webUI, that secrets can be added/retrieved to vault only by using vault-archive and vault-retrieve from CLI """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-252018655 From freeipa-github-notification at redhat.com Thu Oct 6 16:42:51 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 18:42:51 +0200 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management mbasti-rh commented: """ Please disregard comment 1), it works (sorry :( my fault) """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-252020032 From freeipa-github-notification at redhat.com Thu Oct 6 17:17:27 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:17:27 +0200 Subject: [Freeipa-devel] [freeipa PR#123][+pushed] Tests: Remove silent deleting and creating entries by tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/123 Title: #123: Tests: Remove silent deleting and creating entries by tracker Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 6 17:17:29 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:17:29 +0200 Subject: [Freeipa-devel] [freeipa PR#123][comment] Tests: Remove silent deleting and creating entries by tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/123 Title: #123: Tests: Remove silent deleting and creating entries by tracker mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/74e52e86867372365d1d63561f7d1ff961b89ee0 """ See the full comment at https://github.com/freeipa/freeipa/pull/123#issuecomment-252029305 From freeipa-github-notification at redhat.com Thu Oct 6 17:17:30 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:17:30 +0200 Subject: [Freeipa-devel] [freeipa PR#123][closed] Tests: Remove silent deleting and creating entries by tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/123 Author: mirielka Title: #123: Tests: Remove silent deleting and creating entries by tracker Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/123/head:pr123 git checkout pr123 From freeipa-github-notification at redhat.com Thu Oct 6 17:22:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:22:01 +0200 Subject: [Freeipa-devel] [freeipa PR#115][+pushed] Don't show traceback when ipa config file is not an absolute path In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/115 Title: #115: Don't show traceback when ipa config file is not an absolute path Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 6 17:22:03 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:22:03 +0200 Subject: [Freeipa-devel] [freeipa PR#115][comment] Don't show traceback when ipa config file is not an absolute path In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/115 Title: #115: Don't show traceback when ipa config file is not an absolute path mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d7a2dfddbc2dc9ae4cea7d65e56d61a6a4d2b928 https://fedorahosted.org/freeipa/changeset/0dea726466b5971cf74b9e8b7e33af0618e5842c """ See the full comment at https://github.com/freeipa/freeipa/pull/115#issuecomment-252030530 From freeipa-github-notification at redhat.com Thu Oct 6 17:22:04 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:22:04 +0200 Subject: [Freeipa-devel] [freeipa PR#115][closed] Don't show traceback when ipa config file is not an absolute path In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/115 Author: tomaskrizek Title: #115: Don't show traceback when ipa config file is not an absolute path Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/115/head:pr115 git checkout pr115 From freeipa-github-notification at redhat.com Thu Oct 6 17:25:21 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:25:21 +0200 Subject: [Freeipa-devel] [freeipa PR#108][+pushed] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 6 17:25:23 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:25:23 +0200 Subject: [Freeipa-devel] [freeipa PR#108][comment] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/6b3f4984296f3caff8f29490eae3ed1dca64b8c3 https://fedorahosted.org/freeipa/changeset/2b8163ab5dfcf28a9eba319ef685046ae9d8b5e8 ipa-4-4: https://fedorahosted.org/freeipa/changeset/358e50b2e194d3ae3d0e8c22c774a24ab84d8be1 https://fedorahosted.org/freeipa/changeset/810c38efce6a3911b39e29b7aac010e467ef25a7 """ See the full comment at https://github.com/freeipa/freeipa/pull/108#issuecomment-252031461 From freeipa-github-notification at redhat.com Thu Oct 6 17:25:25 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 06 Oct 2016 19:25:25 +0200 Subject: [Freeipa-devel] [freeipa PR#108][closed] Bump pki min version and add commentary about sub-CA revocation on delete In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/108 Author: frasertweedale Title: #108: Bump pki min version and add commentary about sub-CA revocation on delete Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/108/head:pr108 git checkout pr108 From rcritten at redhat.com Thu Oct 6 17:48:02 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 6 Oct 2016 13:48:02 -0400 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161006155713.GC1843@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <57F660CC.5030801@redhat.com> <20161006155713.GC1843@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <57F68E52.7080300@redhat.com> Sumit Bose wrote: > On Thu, Oct 06, 2016 at 10:33:48AM -0400, Rob Crittenden wrote: >> Sumit Bose wrote: >>> Hi, >>> >>> >> >> Wow, this is really great. > > Hi Rob, > > thank you for the feedback. > >> >> I think I'd pre-plan to support different configuration per issuer subject, >> with one named default. It shouldn't be a lot more work and will >> future-proof things for you, particularly in how the rules are stored in >> LDAP. >> >> I worry a bit about matching without comparing the certificate for the case >> where you don't examine issuer. >> > > Do I understand it correctly that you are looking for rules which will > always and only match for certificate from a given issuer? E.g. if all > matching rules will have the set like > > CN=ca,DC=abd,DC=comclientAuth > CN=ca,DC=def,DC=commsScLogin > > certificates from the abc issue must have clientAuth set to be valid for > authentication and certificates from issuer def must have msScLogin set. > But you are right, if one rule does not have issuer set like > > CN=ca,DC=abd,DC=comclientAuth > msScLogin > > then a certificate from issuer abc which does not have clientAuth set > but msScLogin would be accepted as well. > > Do you think it would help to make a required field but allow > that the lazy admin can just enter a '*' to match any issuer? Yes, that is basically what I was proposing, and mostly to ensure that the data is stored in such away that adding rules per issuer would be easy/possible in the future. It probably hits 80/20 by supporting only a single set of rules for the 1.0 release. >> You may want to have an option to require that the presented cert match the >> one stored in LDAP (off by default). I realize that you specifically mention >> this can be problematic, but it can also be quite useful. It can be used, >> for example, to disable a login by removing the certificate from the user's >> entry. It also ensures that some carefully crafted certificate doesn't allow >> a bad actor to map to a user account. > > This happens when no mapping rule is given. Then SSSD will fall > back to search/map the user with the whole certificate. And if the > certificate is removed from the LDAP entry of the user Smartcard > authentication will fail as soon as the user entry in the cache of SSSD > is expired. I wonder if some might want both at the same time. Match using rules and then also confirm the certificate matches, if it is available in the entry, with a require/optional setting to decide what to do in case the cert isn't in LDAP. rob From ftweedal at redhat.com Thu Oct 6 23:53:04 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 7 Oct 2016 09:53:04 +1000 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20161006235304.GH20504@dhcp-40-8.bne.redhat.com> On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > Question, do we need search-and-replace at all (or at this > stage)? Most of the interesting values from the SAN should be > directly map-able to LDAP attributes. And processing the string > representation of might be tricky as discussed below. > Nevertheless the following might be possible: > > * /regexp/replacement/ > * /regexp/replacement/ > > where "/regexp/replacement/" stands for optional sed-like > substitution rules. E.g. a rule like > > /^CN=\([^,]*\).*$/\1/ > > would take the subject string > 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and > generate a LDAP search filter component > '(samAccountName=Certuser)' which can be included in a LDAP search > filter which includes additional components like e.g. an > objectClass. > A counter-proposal w.r.t. DN mapping: Where OID is either an actual OID or the corresponding string i.e. "CN", "O", etc. This would extract the "most specific" (leftmost in the LDAP sense, rightmost in the X.500 sense) attribute value of the specified type from the Subject DN. IMO this would cover most DN mapping use cases whilst avoiding regex or confusion about RDN order. Therefore your original example of: /^CN=\([^,]*\).*$/\1/ can be accomplished with: In the spirit of "make the simple things simple, and the hard things possible" it is probably necessary to retain the regex variant to handle more complex DN mapping use cases, e.g. where there are multiple occurrences of a single attribute type, a particular fixed RDN must be matched, etc. w.r.t. SAN mapping, I concur that search/replace is probably not needed. Cheers, Fraser From jcholast at redhat.com Fri Oct 7 06:31:07 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 7 Oct 2016 08:31:07 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: <0a43fba5-a300-27e6-2ef3-c4f8d907cda4@redhat.com> References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> <0a43fba5-a300-27e6-2ef3-c4f8d907cda4@redhat.com> Message-ID: <0eb715f5-5001-a3b2-743d-18fcd38e1a7e@redhat.com> On 17.8.2016 13:47, Stanislav Laznicka wrote: > On 08/11/2016 02:59 PM, Stanislav Laznicka wrote: >> On 08/11/2016 07:49 AM, Jan Cholasta wrote: >>> On 2.8.2016 13:47, Stanislav Laznicka wrote: >>>> On 07/19/2016 09:20 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 14.7.2016 14:36, Stanislav Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >>>>>> >>>>>> With not so much experience with the framework, it raises question >>>>>> in my >>>>>> head whether ipaldap.get_entries is used properly throughout the >>>>>> system >>>>>> - does it always assume that it gets ALL the requested entries or >>>>>> just a >>>>>> few of those as configured by the 'ipaSearchRecordsLimit' >>>>>> attribute of >>>>>> ipaConfig.etc which it actually gets? >>>>> >>>>> That depends. If you call get_entries() on the ldap2 plugin (which is >>>>> usually the case in the framework), then ipaSearchRecordsLimit is >>>>> used. If you call it on some arbitrary LDAPClient instance, the >>>>> hardcoded default (= unlimited) is used. >>>>> >>>>>> >>>>>> One spot that I know the get_entries method was definitely not used >>>>>> properly before this patch is in the >>>>>> baseldap.LDAPObject.get_memberindirect() method: >>>>>> >>>>>> 692 result = self.backend.get_entries( >>>>>> 693 self.api.env.basedn, >>>>>> 694 filter=filter, >>>>>> 695 attrs_list=['member'], >>>>>> 696 size_limit=-1, # paged search will get >>>>>> everything >>>>>> anyway >>>>>> 697 paged_search=True) >>>>>> >>>>>> which to me seems kind of important if the environment size_limit >>>>>> is not >>>>>> set properly :) The patch does not fix the non-propagation of the >>>>>> paged_search, though. >>>>> >>>>> Why do you think size_limit is not used properly here? >>>> AFAIU it is desired that the search is unlimited. However, due to the >>>> fact that neither size_limit nor paged_search are passed from >>>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from >>>> LDAPClient), only the number of records specified by >>>> ipaSearchRecordsLimit is returned. That could eventually cause problems >>>> should ipaSearchRecordsLimit be set to a low value as in the ticket. >>> >>> I see. This is *not* intentional, the **kwargs of get_entries() >>> should be passed to find_entries(). This definitely needs to be fixed. >>> >>>>> >>>>> Anyway, this ticket is not really easily fixable without more profound >>>>> changes. Often, multiple LDAP searches are done during command >>>>> execution. What do you do with the size limit then? Do you pass the >>>>> same size limit to all the searches? Do you subtract the result size >>>>> from the size limit after each search? Do you do something else with >>>>> it? ... The answer is that it depends on the purpose of each >>>>> individual LDAP search (like in get_memberindirect() above, we have to >>>>> do unlimited search, otherwise the resulting entry would be >>>>> incomplete), and fixing this accross the whole framework is a >>>>> non-trivial task. >>>>> >>>> I do realize that the proposed fix for the permission plugin is not >>>> perfect, it would probably be better to subtract the number of >>>> currently >>>> loaded records from the sizelimit, although in the end the number of >>>> returned values will not be higher than the given size_limit. However, >>>> it seems reasonable that if get_entries is passed a size limit, it >>>> should apply it over current ipaSearchRecordsLimit rather than ignoring >>>> it. Then, any use of get_entries could be fixed accordingly if someone >>>> sees fit. >>>> >>> >>> Right. Anyway, this is a different issue than above, so please put >>> this into a separate commit. >>> >> Please see the attached patches, then. >> > Self-NACK, with Honza's help I found there was a mistake in the code. I > also found an off-by-one bug which I hope I could stick to the other two > patches (attaching only the modified and new patches). Works for me, but this bit in patch 0064 looks suspicious to me: + if max_entries > 0 and len(entries) == max_entries: Shouldn't it rather be: + if max_entries > 0 and len(entries) >= max_entries: ? -- Jan Cholasta From abokovoy at redhat.com Fri Oct 7 06:35:00 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Oct 2016 09:35:00 +0300 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161006235304.GH20504@dhcp-40-8.bne.redhat.com> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161006235304.GH20504@dhcp-40-8.bne.redhat.com> Message-ID: <20161007063500.ldg4szrhbz3i4b5i@redhat.com> On pe, 07 loka 2016, Fraser Tweedale wrote: >On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > >> Question, do we need search-and-replace at all (or at this >> stage)? Most of the interesting values from the SAN should be >> directly map-able to LDAP attributes. And processing the string >> representation of might be tricky as discussed below. >> Nevertheless the following might be possible: >> >> * /regexp/replacement/ >> * /regexp/replacement/ >> >> where "/regexp/replacement/" stands for optional sed-like >> substitution rules. E.g. a rule like >> >> /^CN=\([^,]*\).*$/\1/ >> >> would take the subject string >> 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and >> generate a LDAP search filter component >> '(samAccountName=Certuser)' which can be included in a LDAP search >> filter which includes additional components like e.g. an >> objectClass. >> >A counter-proposal w.r.t. DN mapping: > > > >Where OID is either an actual OID or the corresponding string i.e. >"CN", "O", etc. This would extract the "most specific" (leftmost in >the LDAP sense, rightmost in the X.500 sense) attribute value of the >specified type from the Subject DN. > >IMO this would cover most DN mapping use cases whilst avoiding regex >or confusion about RDN order. Therefore your original example of: > > /^CN=\([^,]*\).*$/\1/ > >can be accomplished with: > > > >In the spirit of "make the simple things simple, and the hard things >possible" it is probably necessary to retain the regex variant to >handle more complex DN mapping use cases, e.g. where there are >multiple occurrences of a single attribute type, a particular fixed >RDN must be matched, etc. > >w.r.t. SAN mapping, I concur that search/replace is probably not >needed. How all these syntax extensions are going to handle multi-valued RDN? -- / Alexander Bokovoy From ofayans at redhat.com Fri Oct 7 07:15:22 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 7 Oct 2016 09:15:22 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <87cb02c1-9d08-9f1e-25cd-731dd6e21155@redhat.com> Message-ID: <596f944c-b655-2440-0b01-613553a9375d@redhat.com> Ping for review On 10/05/2016 12:02 PM, Oleg Fayans wrote: > Hi Ludwig, > > Could you please take a look at it when you have time? > > On 09/13/2016 10:10 AM, Oleg Fayans wrote: >> Hi Ludwig, >> >> The ipa-replica-manage clean-ruv sometimes does not quite work. >> >> For example: I have a master and 2 replicas. Initial output of >> 'ipa-replica-manage list-ruv' looks like this: >> >> >> Replica Update Vectors: >> f24replica2.pesen.net:389: 7 >> f24master.pesen.net:389: 4 >> f24replica1.pesen.net:389: 3 >> Certificate Server Replica Update Vectors: >> f24master.pesen.net:389: 6 >> f24replica1.pesen.net:389: 5 >> f24replica2.pesen.net:389: 8 >> >> >> When I do 'ipa-replica-manage clean-ruv 5' and then list-ruv, it shows >> the expected result: >> >> Replica Update Vectors: >> f24replica2.pesen.net:389: 7 >> f24master.pesen.net:389: 4 >> f24replica1.pesen.net:389: 3 >> Certificate Server Replica Update Vectors: >> f24master.pesen.net:389: 6 >> f24replica2.pesen.net:389: 8 >> >> But when I then do 'ipa-replica-manage clean-ruv 3', the command >> executes successfully, but list-ruv still shows 5 RUVs instead of four. >> >> After all nodes are restarted still 5 RUV's are displaayed, but if I >> clean the RUV N 3 manually again, it works and leaves (expected) 4 RUVs. >> >> Do you have an idea, what it might be and how to debug this? >> >> >> On 08/05/2016 06:36 PM, Martin Basti wrote: >>> >>> >>> On 03.08.2016 14:45, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review! Both patches were updated. >>>> >>>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thanks for the review! >>>>>> >>>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>>> before >>>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>>> feature. >>>>>>>> >>>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>>> One more test was added to the patch-0048 >>>>>>>>> >>>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>>> from >>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> IIUC, this will turn off the machine completely, how is cleanup done >>>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>>> cleanup, so >>>>>>> you will not be able to run more tests on the same topology without >>>>>>> manual cleanup and manual start. >>>>>>> >>>>>>> + replica = self.replicas[0] >>>>>>> + replica.run_command(['poweroff']) >>>>>>> >>>>>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>>>>> >>>>>> Agreed! Fixed. >>>>>> >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> *Automated ipa-replica-manage del tests* >>>>> >>>>> 1) >>>>> + replica.run_command(['ipactl', 'stop']) >>>>> + time.sleep(3) >>>>> >>>>> Why do you need sleep here? >>>> >>>> Removed, it was left from the old "poweroff" approach >>>> >>>>> >>>>> >>>>> 2) >>>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >>>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>>> + '-p', master.config.dirman_password, >>>>> + replica_ruvs[0]]) >>>>> >>>>> Because you are using re.findall(), without any match you will receive >>>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>>> >>>> Implemented the assert which checks that the output contains enough >>>> replica RUVs >>>> >>>>> >>>>> 3) >>>>> assert(replica.hostname in result1.stdout_text) >>>>> >>>>> I think that this is error prone. What if there is just error 'could >>>>> not >>>>> connect to replica ', or something similar. >>>>> instead of >>>>> listing/cleaning/whatever operation was executed. I think that it >>>>> should >>>>> be more specific regexp than just finding a replica name substring >>>>> (Yes >>>>> In IPA we dont always print error so stderr) >>>>> >>>>> I'm not sure, but probably there might be cases when non critical >>>>> error >>>>> happen and exist status is still 0 >>>> >>>> Agree. Implemented a regex-based search >>>> >>>>> >>>>> 4) >>>>> >>>>> + replica.run_command(['poweroff']) >>>>> + time.sleep(3) >>>>> >>>>> There should not be poweroff, probably sleep could be removed too. >>>> >>>> Gone >>>> >>>>> >>>>> >>>>> * Automated clean-ruv subcommand test* >>>>> >>>>> 1) PEP8, 2 new lines expected >>>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>>> blank lines, found 0 >>>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>>> long >>>>> (85 > 79 characters) >>>> >>>> Fixed >>>> >>>>> >>>>> >>>>> 2) >>>>> I dont like doing assert just with count of occurences of substring in >>>>> STDOUT, would be possible to improve this somehow? >>>> >>>> Maybe, but frankly, I don't see how. In this case we are making sure >>>> that both simple and CA-specific RUVs of a replica are displayed. The >>>> format of the output is strict: >>>> Replica Update Vectors: >>>> replica1_hostname:389: RUV_id >>>> replica2_hostname:389: RUV_id >>>> Certificate Server Replica Update Vectors: >>>> replica1_hostname:389: RUV_id >>>> replica2_hostname:389: RUV_id >>>> If we do not see 2 occurrences of the replica hostname than definitely >>>> something went wrong >>>> >>>>> >>>>> 3) >>>>> I'm not sure if clean-ruv is instant operations or there is some magic >>>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>>> should be there, but this needs investigation. >>>>> >>>>> + assert(replica.hostname in result2.stdout_text), ( >>>>> + "The wrong RUV was deleted") >>>>> + result3 = master.run_command(['ipa-replica-manage', >>>>> 'list-ruv', >>>>> + '-p', >>>>> master.config.dirman_password]) >>>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>>> + "CA RUV of the replica is still displayed") >>>>> >>>> >>>> Based on my discussion with Stanislav Laznicka, I understood that by >>>> default clean-ruv does not return the shell until the operation is >>>> finished. You can force dropping into the shell by pressing CTRL+C, in >>>> which case the background job will still be running, but this is not >>>> the default behavior >>>> >>> Test failed: >>> result4 = master.run_command(['ipa-replica-manage', 'list-ruv', >>> '-p', >>> master.config.dirman_password]) >>>> assert(replica.hostname not in result4.stdout_text), ( >>> "replica's RUV is still displayed") >>> E AssertionError: replica's RUV is still displayed >>> E assert 'replica3.ipa.test' not in 'Replica Update >>> V...ipa.test:389: 8\n' >>> E 'replica3.ipa.test' is contained here: >>> E Replica Update Vectors: >>> E \tmaster.ipa.test:389: 4 >>> E \treplica3.ipa.test:389: 3 >>> E \treplica2.ipa.test:389: 7 >>> E Certificate Server Replica Update Vectors: >>> E \tmaster.ipa.test:389: 6 >>> E \treplica2.ipa.test:389: 8 >>> >>> >>> [root at master ~]# ipa topologysegment-find >>> Suffix name: domain >>> ------------------ >>> 2 segments matched >>> ------------------ >>> Segment name: master.ipa.test-to-replica2.ipa.test >>> Left node: master.ipa.test >>> Right node: replica2.ipa.test >>> Connectivity: both >>> >>> Segment name: master.ipa.test-to-replica3.ipa.test >>> Left node: master.ipa.test >>> Right node: replica3.ipa.test >>> Connectivity: both >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >>> [root at master ~]# ipa-replica-manage list-ruv >>> Directory Manager password: >>> >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> replica3.ipa.test:389: 3 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> [root at master ~]# >>> >>> Then I tried manually to clean RUV 3, and it behaves somehow odd >>> >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' >>> '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> Background task created to clean replication data. This may take a >>> while. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >>> [root at master ~]# ipa-replica-manage list-ruv >>> Directory Manager password: >>> >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> replica3.ipa.test:389: 3 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' >>> '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> CLEANALLRUV task for replica id 3 already exists. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> >>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>> No CLEANALLRUV tasks running >>> >>> No abort CLEANALLRUV tasks running >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' >>> '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> Background task created to clean replication data. This may take a >>> while. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>> CLEANALLRUV tasks >>> RID 3: Successfully cleaned rid(3). >>> >>> No abort CLEANALLRUV tasks running >>> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> >>> >>> I'm not sure if this behavior is right, Ludwig may know. >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From lkrispen at redhat.com Fri Oct 7 07:29:30 2016 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 07 Oct 2016 09:29:30 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <87cb02c1-9d08-9f1e-25cd-731dd6e21155@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <87cb02c1-9d08-9f1e-25cd-731dd6e21155@redhat.com> Message-ID: <57F74EDA.60404@redhat.com> On 09/13/2016 10:10 AM, Oleg Fayans wrote: > Hi Ludwig, > > The ipa-replica-manage clean-ruv sometimes does not quite work. > > For example: I have a master and 2 replicas. Initial output of > 'ipa-replica-manage list-ruv' looks like this: > > > Replica Update Vectors: > f24replica2.pesen.net:389: 7 > f24master.pesen.net:389: 4 > f24replica1.pesen.net:389: 3 > Certificate Server Replica Update Vectors: > f24master.pesen.net:389: 6 > f24replica1.pesen.net:389: 5 > f24replica2.pesen.net:389: 8 > > > When I do 'ipa-replica-manage clean-ruv 5' and then list-ruv, it shows > the expected result: > > Replica Update Vectors: > f24replica2.pesen.net:389: 7 > f24master.pesen.net:389: 4 > f24replica1.pesen.net:389: 3 > Certificate Server Replica Update Vectors: > f24master.pesen.net:389: 6 > f24replica2.pesen.net:389: 8 > > But when I then do 'ipa-replica-manage clean-ruv 3', the command > executes successfully, but list-ruv still shows 5 RUVs instead of four. > > After all nodes are restarted still 5 RUV's are displaayed, but if I > clean the RUV N 3 manually again, it works and leaves (expected) 4 RUVs. > > Do you have an idea, what it might be and how to debug this? did you remove the replica before cleaning the ruv, you cannot just run cleanruv for an active replica, it always will come back. > > > On 08/05/2016 06:36 PM, Martin Basti wrote: >> >> >> On 03.08.2016 14:45, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Thanks for the review! Both patches were updated. >>> >>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>> >>>> >>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Thanks for the review! >>>>> >>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>> before >>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>> feature. >>>>>>> >>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>> One more test was added to the patch-0048 >>>>>>>> >>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>> from >>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> IIUC, this will turn off the machine completely, how is cleanup done >>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>> cleanup, so >>>>>> you will not be able to run more tests on the same topology without >>>>>> manual cleanup and manual start. >>>>>> >>>>>> + replica = self.replicas[0] >>>>>> + replica.run_command(['poweroff']) >>>>>> >>>>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>>>> >>>>> Agreed! Fixed. >>>>> >>>>>> >>>>>> Martin^2 >>>>>> >>>>> >>>>> >>>>> >>>> *Automated ipa-replica-manage del tests* >>>> >>>> 1) >>>> + replica.run_command(['ipactl', 'stop']) >>>> + time.sleep(3) >>>> >>>> Why do you need sleep here? >>> >>> Removed, it was left from the old "poweroff" approach >>> >>>> >>>> >>>> 2) >>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>> + '-p', master.config.dirman_password, >>>> + replica_ruvs[0]]) >>>> >>>> Because you are using re.findall(), without any match you will receive >>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>> >>> Implemented the assert which checks that the output contains enough >>> replica RUVs >>> >>>> >>>> 3) >>>> assert(replica.hostname in result1.stdout_text) >>>> >>>> I think that this is error prone. What if there is just error >>>> 'could not >>>> connect to replica ', or something similar. >>>> instead of >>>> listing/cleaning/whatever operation was executed. I think that it >>>> should >>>> be more specific regexp than just finding a replica name substring >>>> (Yes >>>> In IPA we dont always print error so stderr) >>>> >>>> I'm not sure, but probably there might be cases when non critical >>>> error >>>> happen and exist status is still 0 >>> >>> Agree. Implemented a regex-based search >>> >>>> >>>> 4) >>>> >>>> + replica.run_command(['poweroff']) >>>> + time.sleep(3) >>>> >>>> There should not be poweroff, probably sleep could be removed too. >>> >>> Gone >>> >>>> >>>> >>>> * Automated clean-ruv subcommand test* >>>> >>>> 1) PEP8, 2 new lines expected >>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>> blank lines, found 0 >>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>> long >>>> (85 > 79 characters) >>> >>> Fixed >>> >>>> >>>> >>>> 2) >>>> I dont like doing assert just with count of occurences of substring in >>>> STDOUT, would be possible to improve this somehow? >>> >>> Maybe, but frankly, I don't see how. In this case we are making sure >>> that both simple and CA-specific RUVs of a replica are displayed. The >>> format of the output is strict: >>> Replica Update Vectors: >>> replica1_hostname:389: RUV_id >>> replica2_hostname:389: RUV_id >>> Certificate Server Replica Update Vectors: >>> replica1_hostname:389: RUV_id >>> replica2_hostname:389: RUV_id >>> If we do not see 2 occurrences of the replica hostname than definitely >>> something went wrong >>> >>>> >>>> 3) >>>> I'm not sure if clean-ruv is instant operations or there is some magic >>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>> should be there, but this needs investigation. >>>> >>>> + assert(replica.hostname in result2.stdout_text), ( >>>> + "The wrong RUV was deleted") >>>> + result3 = master.run_command(['ipa-replica-manage', >>>> 'list-ruv', >>>> + '-p', >>>> master.config.dirman_password]) >>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>> + "CA RUV of the replica is still displayed") >>>> >>> >>> Based on my discussion with Stanislav Laznicka, I understood that by >>> default clean-ruv does not return the shell until the operation is >>> finished. You can force dropping into the shell by pressing CTRL+C, in >>> which case the background job will still be running, but this is not >>> the default behavior >>> >> Test failed: >> result4 = master.run_command(['ipa-replica-manage', 'list-ruv', >> '-p', >> master.config.dirman_password]) >>> assert(replica.hostname not in result4.stdout_text), ( >> "replica's RUV is still displayed") >> E AssertionError: replica's RUV is still displayed >> E assert 'replica3.ipa.test' not in 'Replica Update >> V...ipa.test:389: 8\n' >> E 'replica3.ipa.test' is contained here: >> E Replica Update Vectors: >> E \tmaster.ipa.test:389: 4 >> E \treplica3.ipa.test:389: 3 >> E \treplica2.ipa.test:389: 7 >> E Certificate Server Replica Update Vectors: >> E \tmaster.ipa.test:389: 6 >> E \treplica2.ipa.test:389: 8 >> >> >> [root at master ~]# ipa topologysegment-find >> Suffix name: domain >> ------------------ >> 2 segments matched >> ------------------ >> Segment name: master.ipa.test-to-replica2.ipa.test >> Left node: master.ipa.test >> Right node: replica2.ipa.test >> Connectivity: both >> >> Segment name: master.ipa.test-to-replica3.ipa.test >> Left node: master.ipa.test >> Right node: replica3.ipa.test >> Connectivity: both >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> [root at master ~]# ipa-replica-manage list-ruv >> Directory Manager password: >> >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> replica3.ipa.test:389: 3 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> [root at master ~]# >> >> Then I tried manually to clean RUV 3, and it behaves somehow odd >> >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >> 'Secret123' '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> Background task created to clean replication data. This may take a >> while. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >> [root at master ~]# ipa-replica-manage list-ruv >> Directory Manager password: >> >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> replica3.ipa.test:389: 3 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >> 'Secret123' '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> CLEANALLRUV task for replica id 3 already exists. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> >> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >> No CLEANALLRUV tasks running >> >> No abort CLEANALLRUV tasks running >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >> 'Secret123' '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> Background task created to clean replication data. This may take a >> while. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >> CLEANALLRUV tasks >> RID 3: Successfully cleaned rid(3). >> >> No abort CLEANALLRUV tasks running >> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> >> >> I'm not sure if this behavior is right, Ludwig may know. > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander From freeipa-github-notification at redhat.com Fri Oct 7 07:35:47 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Fri, 07 Oct 2016 09:35:47 +0200 Subject: [Freeipa-devel] [freeipa PR#133][synchronized] Tests: print what was expected from exceptions and callables in xmlrpc_tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/133 Author: pspacek Title: #133: Tests: print what was expected from exceptions and callables in xmlrpc_tests Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/133/head:pr133 git checkout pr133 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-133.patch Type: text/x-diff Size: 3625 bytes Desc: not available URL: From ofayans at redhat.com Fri Oct 7 07:55:32 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 7 Oct 2016 09:55:32 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <57F74EDA.60404@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <87cb02c1-9d08-9f1e-25cd-731dd6e21155@redhat.com> <57F74EDA.60404@redhat.com> Message-ID: <84e0a329-c5f8-aa0a-8ab5-6dac75edf6c0@redhat.com> Hi Ludwig, Thanks for the clarification! But then why does CSRUV allows to be deleted on a working replica? Shouldn't we keep this behavior somehow consistent? On 10/07/2016 09:29 AM, Ludwig Krispenz wrote: > > On 09/13/2016 10:10 AM, Oleg Fayans wrote: >> Hi Ludwig, >> >> The ipa-replica-manage clean-ruv sometimes does not quite work. >> >> For example: I have a master and 2 replicas. Initial output of >> 'ipa-replica-manage list-ruv' looks like this: >> >> >> Replica Update Vectors: >> f24replica2.pesen.net:389: 7 >> f24master.pesen.net:389: 4 >> f24replica1.pesen.net:389: 3 >> Certificate Server Replica Update Vectors: >> f24master.pesen.net:389: 6 >> f24replica1.pesen.net:389: 5 >> f24replica2.pesen.net:389: 8 >> >> >> When I do 'ipa-replica-manage clean-ruv 5' and then list-ruv, it shows >> the expected result: >> >> Replica Update Vectors: >> f24replica2.pesen.net:389: 7 >> f24master.pesen.net:389: 4 >> f24replica1.pesen.net:389: 3 >> Certificate Server Replica Update Vectors: >> f24master.pesen.net:389: 6 >> f24replica2.pesen.net:389: 8 >> >> But when I then do 'ipa-replica-manage clean-ruv 3', the command >> executes successfully, but list-ruv still shows 5 RUVs instead of four. >> >> After all nodes are restarted still 5 RUV's are displaayed, but if I >> clean the RUV N 3 manually again, it works and leaves (expected) 4 RUVs. >> >> Do you have an idea, what it might be and how to debug this? > did you remove the replica before cleaning the ruv, you cannot just run > cleanruv for an active replica, it always will come back. > >> >> >> On 08/05/2016 06:36 PM, Martin Basti wrote: >>> >>> >>> On 03.08.2016 14:45, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review! Both patches were updated. >>>> >>>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thanks for the review! >>>>>> >>>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>>> before >>>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>>> feature. >>>>>>>> >>>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>>> One more test was added to the patch-0048 >>>>>>>>> >>>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>>> from >>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> IIUC, this will turn off the machine completely, how is cleanup done >>>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>>> cleanup, so >>>>>>> you will not be able to run more tests on the same topology without >>>>>>> manual cleanup and manual start. >>>>>>> >>>>>>> + replica = self.replicas[0] >>>>>>> + replica.run_command(['poweroff']) >>>>>>> >>>>>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>>>>> >>>>>> Agreed! Fixed. >>>>>> >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> *Automated ipa-replica-manage del tests* >>>>> >>>>> 1) >>>>> + replica.run_command(['ipactl', 'stop']) >>>>> + time.sleep(3) >>>>> >>>>> Why do you need sleep here? >>>> >>>> Removed, it was left from the old "poweroff" approach >>>> >>>>> >>>>> >>>>> 2) >>>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >>>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>>> + '-p', master.config.dirman_password, >>>>> + replica_ruvs[0]]) >>>>> >>>>> Because you are using re.findall(), without any match you will receive >>>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>>> >>>> Implemented the assert which checks that the output contains enough >>>> replica RUVs >>>> >>>>> >>>>> 3) >>>>> assert(replica.hostname in result1.stdout_text) >>>>> >>>>> I think that this is error prone. What if there is just error >>>>> 'could not >>>>> connect to replica ', or something similar. >>>>> instead of >>>>> listing/cleaning/whatever operation was executed. I think that it >>>>> should >>>>> be more specific regexp than just finding a replica name substring >>>>> (Yes >>>>> In IPA we dont always print error so stderr) >>>>> >>>>> I'm not sure, but probably there might be cases when non critical >>>>> error >>>>> happen and exist status is still 0 >>>> >>>> Agree. Implemented a regex-based search >>>> >>>>> >>>>> 4) >>>>> >>>>> + replica.run_command(['poweroff']) >>>>> + time.sleep(3) >>>>> >>>>> There should not be poweroff, probably sleep could be removed too. >>>> >>>> Gone >>>> >>>>> >>>>> >>>>> * Automated clean-ruv subcommand test* >>>>> >>>>> 1) PEP8, 2 new lines expected >>>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>>> blank lines, found 0 >>>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>>> long >>>>> (85 > 79 characters) >>>> >>>> Fixed >>>> >>>>> >>>>> >>>>> 2) >>>>> I dont like doing assert just with count of occurences of substring in >>>>> STDOUT, would be possible to improve this somehow? >>>> >>>> Maybe, but frankly, I don't see how. In this case we are making sure >>>> that both simple and CA-specific RUVs of a replica are displayed. The >>>> format of the output is strict: >>>> Replica Update Vectors: >>>> replica1_hostname:389: RUV_id >>>> replica2_hostname:389: RUV_id >>>> Certificate Server Replica Update Vectors: >>>> replica1_hostname:389: RUV_id >>>> replica2_hostname:389: RUV_id >>>> If we do not see 2 occurrences of the replica hostname than definitely >>>> something went wrong >>>> >>>>> >>>>> 3) >>>>> I'm not sure if clean-ruv is instant operations or there is some magic >>>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>>> should be there, but this needs investigation. >>>>> >>>>> + assert(replica.hostname in result2.stdout_text), ( >>>>> + "The wrong RUV was deleted") >>>>> + result3 = master.run_command(['ipa-replica-manage', >>>>> 'list-ruv', >>>>> + '-p', >>>>> master.config.dirman_password]) >>>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>>> + "CA RUV of the replica is still displayed") >>>>> >>>> >>>> Based on my discussion with Stanislav Laznicka, I understood that by >>>> default clean-ruv does not return the shell until the operation is >>>> finished. You can force dropping into the shell by pressing CTRL+C, in >>>> which case the background job will still be running, but this is not >>>> the default behavior >>>> >>> Test failed: >>> result4 = master.run_command(['ipa-replica-manage', 'list-ruv', >>> '-p', >>> master.config.dirman_password]) >>>> assert(replica.hostname not in result4.stdout_text), ( >>> "replica's RUV is still displayed") >>> E AssertionError: replica's RUV is still displayed >>> E assert 'replica3.ipa.test' not in 'Replica Update >>> V...ipa.test:389: 8\n' >>> E 'replica3.ipa.test' is contained here: >>> E Replica Update Vectors: >>> E \tmaster.ipa.test:389: 4 >>> E \treplica3.ipa.test:389: 3 >>> E \treplica2.ipa.test:389: 7 >>> E Certificate Server Replica Update Vectors: >>> E \tmaster.ipa.test:389: 6 >>> E \treplica2.ipa.test:389: 8 >>> >>> >>> [root at master ~]# ipa topologysegment-find >>> Suffix name: domain >>> ------------------ >>> 2 segments matched >>> ------------------ >>> Segment name: master.ipa.test-to-replica2.ipa.test >>> Left node: master.ipa.test >>> Right node: replica2.ipa.test >>> Connectivity: both >>> >>> Segment name: master.ipa.test-to-replica3.ipa.test >>> Left node: master.ipa.test >>> Right node: replica3.ipa.test >>> Connectivity: both >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >>> [root at master ~]# ipa-replica-manage list-ruv >>> Directory Manager password: >>> >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> replica3.ipa.test:389: 3 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> [root at master ~]# >>> >>> Then I tried manually to clean RUV 3, and it behaves somehow odd >>> >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>> 'Secret123' '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> Background task created to clean replication data. This may take a >>> while. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >>> [root at master ~]# ipa-replica-manage list-ruv >>> Directory Manager password: >>> >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> replica3.ipa.test:389: 3 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>> 'Secret123' '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> CLEANALLRUV task for replica id 3 already exists. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> >>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>> No CLEANALLRUV tasks running >>> >>> No abort CLEANALLRUV tasks running >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>> 'Secret123' '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> Background task created to clean replication data. This may take a >>> while. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>> CLEANALLRUV tasks >>> RID 3: Successfully cleaned rid(3). >>> >>> No abort CLEANALLRUV tasks running >>> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> >>> >>> I'm not sure if this behavior is right, Ludwig may know. >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From pspacek at redhat.com Fri Oct 7 09:56:26 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 7 Oct 2016 11:56:26 +0200 Subject: [Freeipa-devel] Build system refactoring - design document Message-ID: Dear FreeIPA developers and packagers, you can find first version of the Build system refactoring design document on: http://www.freeipa.org/page/V4/Build_system_refactoring If you do not care about implementation details, please be so kind and quickly scan through chapter http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management I'm not an FreeIPA packager so I might miss some important thing which needs to be configurable. Also, I would appreciate ideas how to handle build versioning: http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning My main questions are: * What is triggering IPA upgrade? * Would it be sufficient to bump release in RPM? (I mean - theoretically. Could the code be modified to detect this?) Here I'm trying to avoid unnecessary rebuilds caused by changes to IPA_VENDOR_VERSION during each build. Timo, what can I do to help you with packaging for Ubuntu/Debian? Dream big, even wild ideas are welcome! -- Petr^2 Spacek From pspacek at redhat.com Fri Oct 7 10:00:12 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 7 Oct 2016 12:00:12 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: References: Message-ID: <2e0efcbb-2994-f80e-c270-be830f6ae8e9@redhat.com> On 7.10.2016 11:56, Petr Spacek wrote: > Dear FreeIPA developers and packagers, > > you can find first version of the Build system refactoring design document on: > http://www.freeipa.org/page/V4/Build_system_refactoring > > If you do not care about implementation details, please be so kind and quickly > scan through chapter > http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management > > I'm not an FreeIPA packager so I might miss some important thing which needs > to be configurable. > > > Also, I would appreciate ideas how to handle build versioning: > http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning > > My main questions are: > * What is triggering IPA upgrade? > * Would it be sufficient to bump release in RPM? (I mean - theoretically. > Could the code be modified to detect this?) > > Here I'm trying to avoid unnecessary rebuilds caused by changes to > IPA_VENDOR_VERSION during each build. > > > Timo, what can I do to help you with packaging for Ubuntu/Debian? > > Dream big, even wild ideas are welcome! Also, if you are packager or tester, please describe your requirements/use-cases/user stories/whatever so I can design the system to suit your needs. I've tried to capture developer's needs to http://www.freeipa.org/page/V4/Build_system_refactoring#User_stories Please let me know if you are okay with that or if it needs corrections. Thank you for your time! -- Petr^2 Spacek From slaznick at redhat.com Fri Oct 7 10:23:34 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Fri, 7 Oct 2016 12:23:34 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: <0eb715f5-5001-a3b2-743d-18fcd38e1a7e@redhat.com> References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> <0a43fba5-a300-27e6-2ef3-c4f8d907cda4@redhat.com> <0eb715f5-5001-a3b2-743d-18fcd38e1a7e@redhat.com> Message-ID: <4c4890fc-8f13-267c-bd65-2d4475ae644a@redhat.com> On 10/07/2016 08:31 AM, Jan Cholasta wrote: > On 17.8.2016 13:47, Stanislav Laznicka wrote: >> On 08/11/2016 02:59 PM, Stanislav Laznicka wrote: >>> On 08/11/2016 07:49 AM, Jan Cholasta wrote: >>>> On 2.8.2016 13:47, Stanislav Laznicka wrote: >>>>> On 07/19/2016 09:20 AM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 14.7.2016 14:36, Stanislav Laznicka wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >>>>>>> >>>>>>> With not so much experience with the framework, it raises question >>>>>>> in my >>>>>>> head whether ipaldap.get_entries is used properly throughout the >>>>>>> system >>>>>>> - does it always assume that it gets ALL the requested entries or >>>>>>> just a >>>>>>> few of those as configured by the 'ipaSearchRecordsLimit' >>>>>>> attribute of >>>>>>> ipaConfig.etc which it actually gets? >>>>>> >>>>>> That depends. If you call get_entries() on the ldap2 plugin >>>>>> (which is >>>>>> usually the case in the framework), then ipaSearchRecordsLimit is >>>>>> used. If you call it on some arbitrary LDAPClient instance, the >>>>>> hardcoded default (= unlimited) is used. >>>>>> >>>>>>> >>>>>>> One spot that I know the get_entries method was definitely not used >>>>>>> properly before this patch is in the >>>>>>> baseldap.LDAPObject.get_memberindirect() method: >>>>>>> >>>>>>> 692 result = self.backend.get_entries( >>>>>>> 693 self.api.env.basedn, >>>>>>> 694 filter=filter, >>>>>>> 695 attrs_list=['member'], >>>>>>> 696 size_limit=-1, # paged search will get >>>>>>> everything >>>>>>> anyway >>>>>>> 697 paged_search=True) >>>>>>> >>>>>>> which to me seems kind of important if the environment size_limit >>>>>>> is not >>>>>>> set properly :) The patch does not fix the non-propagation of the >>>>>>> paged_search, though. >>>>>> >>>>>> Why do you think size_limit is not used properly here? >>>>> AFAIU it is desired that the search is unlimited. However, due to the >>>>> fact that neither size_limit nor paged_search are passed from >>>>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from >>>>> LDAPClient), only the number of records specified by >>>>> ipaSearchRecordsLimit is returned. That could eventually cause >>>>> problems >>>>> should ipaSearchRecordsLimit be set to a low value as in the ticket. >>>> >>>> I see. This is *not* intentional, the **kwargs of get_entries() >>>> should be passed to find_entries(). This definitely needs to be fixed. >>>> >>>>>> >>>>>> Anyway, this ticket is not really easily fixable without more >>>>>> profound >>>>>> changes. Often, multiple LDAP searches are done during command >>>>>> execution. What do you do with the size limit then? Do you pass the >>>>>> same size limit to all the searches? Do you subtract the result size >>>>>> from the size limit after each search? Do you do something else with >>>>>> it? ... The answer is that it depends on the purpose of each >>>>>> individual LDAP search (like in get_memberindirect() above, we >>>>>> have to >>>>>> do unlimited search, otherwise the resulting entry would be >>>>>> incomplete), and fixing this accross the whole framework is a >>>>>> non-trivial task. >>>>>> >>>>> I do realize that the proposed fix for the permission plugin is not >>>>> perfect, it would probably be better to subtract the number of >>>>> currently >>>>> loaded records from the sizelimit, although in the end the number of >>>>> returned values will not be higher than the given size_limit. >>>>> However, >>>>> it seems reasonable that if get_entries is passed a size limit, it >>>>> should apply it over current ipaSearchRecordsLimit rather than >>>>> ignoring >>>>> it. Then, any use of get_entries could be fixed accordingly if >>>>> someone >>>>> sees fit. >>>>> >>>> >>>> Right. Anyway, this is a different issue than above, so please put >>>> this into a separate commit. >>>> >>> Please see the attached patches, then. >>> >> Self-NACK, with Honza's help I found there was a mistake in the code. I >> also found an off-by-one bug which I hope I could stick to the other two >> patches (attaching only the modified and new patches). > > Works for me, but this bit in patch 0064 looks suspicious to me: > > + if max_entries > 0 and len(entries) == > max_entries: > > Shouldn't it rather be: > > + if max_entries > 0 and len(entries) >= > max_entries: > > ? > The length of entries list should not exceed max_entries if size_limit is properly implemented. Therefore the list you get from execute() should not have more then max_entries entries. You shouldn't also be able to append a legacy entry to entries list if this check is the first thing you do. That being said, >= could be used but then some popping of entries from entries list would be necessary. But it's perhaps safer to do, although if there's a bug, it won't be that obvious :) From mbasti at redhat.com Fri Oct 7 10:59:37 2016 From: mbasti at redhat.com (Martin Basti) Date: Fri, 7 Oct 2016 12:59:37 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: References: Message-ID: <7d43f8a9-a474-3b27-8b7b-c2ae4b7a058e@redhat.com> On 07.10.2016 11:56, Petr Spacek wrote: > Dear FreeIPA developers and packagers, > > you can find first version of the Build system refactoring design document on: > http://www.freeipa.org/page/V4/Build_system_refactoring > > If you do not care about implementation details, please be so kind and quickly > scan through chapter > http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management > > I'm not an FreeIPA packager so I might miss some important thing which needs > to be configurable. > > > Also, I would appreciate ideas how to handle build versioning: > http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning > > My main questions are: > * What is triggering IPA upgrade? > * Would it be sufficient to bump release in RPM? (I mean - theoretically. > Could the code be modified to detect this?) > > Here I'm trying to avoid unnecessary rebuilds caused by changes to > IPA_VENDOR_VERSION during each build. > > > Timo, what can I do to help you with packaging for Ubuntu/Debian? > > Dream big, even wild ideas are welcome! > Thank you for nice design, 1) I'd like to have make clean as well (we have it there now, but I don't think that it works well) 2) Pylint: currently we have (almost) python2/3 compatible code so what is the reason to have python2 and python3 separated checks? Pylint is doing that at once From pspacek at redhat.com Fri Oct 7 11:31:03 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 7 Oct 2016 13:31:03 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: <7d43f8a9-a474-3b27-8b7b-c2ae4b7a058e@redhat.com> References: <7d43f8a9-a474-3b27-8b7b-c2ae4b7a058e@redhat.com> Message-ID: On 7.10.2016 12:59, Martin Basti wrote: > > > On 07.10.2016 11:56, Petr Spacek wrote: >> Dear FreeIPA developers and packagers, >> >> you can find first version of the Build system refactoring design document on: >> http://www.freeipa.org/page/V4/Build_system_refactoring >> >> If you do not care about implementation details, please be so kind and quickly >> scan through chapter >> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management >> >> I'm not an FreeIPA packager so I might miss some important thing which needs >> to be configurable. >> >> >> Also, I would appreciate ideas how to handle build versioning: >> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning >> >> My main questions are: >> * What is triggering IPA upgrade? >> * Would it be sufficient to bump release in RPM? (I mean - theoretically. >> Could the code be modified to detect this?) >> >> Here I'm trying to avoid unnecessary rebuilds caused by changes to >> IPA_VENDOR_VERSION during each build. >> >> >> Timo, what can I do to help you with packaging for Ubuntu/Debian? >> >> Dream big, even wild ideas are welcome! >> > > Thank you for nice design, > > 1) > I'd like to have make clean as well (we have it there now, but I don't think > that it works well) I've added clean to the list. In general, we should get all targets listed in https://www.gnu.org/software/automake/manual/html_node/Standard-Targets.html "for free" (if we do it right). > 2) > Pylint: > > currently we have (almost) python2/3 compatible code so what is the reason to > have python2 and python3 separated checks? Pylint is doing that at once I'm fine with just one pylint. Design updated: http://www.freeipa.org/page/V4/Build_system_refactoring#Configuration Thank you for clarification! -- Petr^2 Spacek From freeipa-github-notification at redhat.com Fri Oct 7 12:46:49 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Fri, 07 Oct 2016 14:46:49 +0200 Subject: [Freeipa-devel] [freeipa PR#142][synchronized] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Author: dkupka Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/142/head:pr142 git checkout pr142 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-142.patch Type: text/x-diff Size: 2556 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 7 13:14:16 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 07 Oct 2016 15:14:16 +0200 Subject: [Freeipa-devel] [freeipa PR#144][opened] Pylint: remove unused values - the last part Message-ID: URL: https://github.com/freeipa/freeipa/pull/144 Author: mbasti-rh Title: #144: Pylint: remove unused values - the last part Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/144/head:pr144 git checkout pr144 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-144.patch Type: text/x-diff Size: 45491 bytes Desc: not available URL: From tjaalton at ubuntu.com Fri Oct 7 13:42:51 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 7 Oct 2016 16:42:51 +0300 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: References: Message-ID: On 07.10.2016 12:56, Petr Spacek wrote: > Dear FreeIPA developers and packagers, > > you can find first version of the Build system refactoring design document on: > http://www.freeipa.org/page/V4/Build_system_refactoring > > If you do not care about implementation details, please be so kind and quickly > scan through chapter > http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management > > I'm not an FreeIPA packager so I might miss some important thing which needs > to be configurable. > > > Also, I would appreciate ideas how to handle build versioning: > http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning > > My main questions are: > * What is triggering IPA upgrade? > * Would it be sufficient to bump release in RPM? (I mean - theoretically. > Could the code be modified to detect this?) > > Here I'm trying to avoid unnecessary rebuilds caused by changes to > IPA_VENDOR_VERSION during each build. > > > Timo, what can I do to help you with packaging for Ubuntu/Debian? If you mean build system -wise, there isn't anything that I need, at least if you migrate to autotools which sounds great. This is the debian/rules of the current package, so if you'll have a proper 'make clean' (as suggested already) and a one-pass build then that's pretty much what I'd "need". https://anonscm.debian.org/cgit/pkg-freeipa/freeipa.git/tree/debian/rules -- t From freeipa-github-notification at redhat.com Fri Oct 7 14:39:22 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 07 Oct 2016 16:39:22 +0200 Subject: [Freeipa-devel] [freeipa PR#142][+ack] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Label: +ack From freeipa-github-notification at redhat.com Fri Oct 7 14:40:04 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 07 Oct 2016 16:40:04 +0200 Subject: [Freeipa-devel] [freeipa PR#142][comment] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling mbasti-rh commented: """ Works for me, I'm not pushing this yet if somebody wants to double check pickle implementation """ See the full comment at https://github.com/freeipa/freeipa/pull/142#issuecomment-252270287 From freeipa-github-notification at redhat.com Fri Oct 7 14:42:34 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 07 Oct 2016 16:42:34 +0200 Subject: [Freeipa-devel] [freeipa PR#145][opened] [WIP] Refactoring: LDAP Connection Management Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Author: tomaskrizek Title: #145: [WIP] Refactoring: LDAP Connection Management Action: opened PR body: """ PREVIEW, please don't merge yet Design doc: http://www.freeipa.org/page/V4/LDAP_Connection_Management_Refactoring Many changes in current PR are only temporary for easier refactoring, but feedback is welcome. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/145/head:pr145 git checkout pr145 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-145.patch Type: text/x-diff Size: 122537 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 7 14:52:54 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 07 Oct 2016 16:52:54 +0200 Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support mbasti-rh commented: """ I'm so sorry, I didn't noticed earlier, but you forgot to bump API in VERSION Otherwise LGTM and works for me """ See the full comment at https://github.com/freeipa/freeipa/pull/134#issuecomment-252273635 From mbabinsk at redhat.com Fri Oct 7 15:11:35 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 7 Oct 2016 17:11:35 +0200 Subject: [Freeipa-devel] announcing ipa-docker-test-runner Message-ID: <34b66df0-da8a-b90f-0ed0-ddbed9b5d717@redhat.com> Hi fellow FreeIPA developers, Did you ever wanted to have a means to build FreeIPA rpms locally without pulling in all the build requires or firing up VMs just to do such a simple task? Did you ever wish to fire up a quick script which will build RPMs and install FreeIPA server for you to play and test out some new feature you are working on? Did you ever wish to run all out-of-tree tests from your local git repo with a single command? I have put together a dumb frontend automating building FreeIPA and automating tests in a Docker container The git repo is here along with a README explaining the usage: https://github.com/martbab/ipa-docker-test-runner The tool is far from perfect but it should be usable for the most common use cases. If you have any issue with it or would like to propose an enhancement, please open an issue or PR. -- Martin^3 Babinsky From ftweedal at redhat.com Mon Oct 10 00:41:14 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 10 Oct 2016 10:41:14 +1000 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161007063500.ldg4szrhbz3i4b5i@redhat.com> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161006235304.GH20504@dhcp-40-8.bne.redhat.com> <20161007063500.ldg4szrhbz3i4b5i@redhat.com> Message-ID: <20161010004114.GO20504@dhcp-40-8.bne.redhat.com> On Fri, Oct 07, 2016 at 09:35:00AM +0300, Alexander Bokovoy wrote: > On pe, 07 loka 2016, Fraser Tweedale wrote: > > On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > > > > > Question, do we need search-and-replace at all (or at this > > > stage)? Most of the interesting values from the SAN should be > > > directly map-able to LDAP attributes. And processing the string > > > representation of might be tricky as discussed below. > > > Nevertheless the following might be possible: > > > > > > * /regexp/replacement/ > > > * /regexp/replacement/ > > > > > > where "/regexp/replacement/" stands for optional sed-like > > > substitution rules. E.g. a rule like > > > > > > /^CN=\([^,]*\).*$/\1/ > > > > > > would take the subject string > > > 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and > > > generate a LDAP search filter component > > > '(samAccountName=Certuser)' which can be included in a LDAP search > > > filter which includes additional components like e.g. an > > > objectClass. > > > > > A counter-proposal w.r.t. DN mapping: > > > > > > > > Where OID is either an actual OID or the corresponding string i.e. > > "CN", "O", etc. This would extract the "most specific" (leftmost in > > the LDAP sense, rightmost in the X.500 sense) attribute value of the > > specified type from the Subject DN. > > > > IMO this would cover most DN mapping use cases whilst avoiding regex > > or confusion about RDN order. Therefore your original example of: > > > > /^CN=\([^,]*\).*$/\1/ > > > > can be accomplished with: > > > > > > > > In the spirit of "make the simple things simple, and the hard things > > possible" it is probably necessary to retain the regex variant to > > handle more complex DN mapping use cases, e.g. where there are > > multiple occurrences of a single attribute type, a particular fixed > > RDN must be matched, etc. > > > > w.r.t. SAN mapping, I concur that search/replace is probably not > > needed. > How all these syntax extensions are going to handle multi-valued RDN? > In the variant I proposed, it is handled fine because it selects the "most specific" occurrence of that attribute type. An attribute type cannot appear twice in the same RDN so this is unambiguous. For the regex variant, because `RDN ::= SET OF AVA' we would have to ensure that the stringified DN uses a deterministic order for attribute types (probably lexicographic order on corresponding LDAP attribute name) within a multi-valued RDN and clearly document this. It will be up to admins to define the correct regex based on naming of the certificates they use. Cheers, Fraser From rajat.linux at gmail.com Mon Oct 10 03:23:32 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Mon, 10 Oct 2016 05:23:32 +0200 Subject: [Freeipa-devel] kinit: Cannot contact any KDC for realm... from Freeipa clinet (Active Directory trust setup) Message-ID: Hi, I am trying to setup the freeipa Active Directory trust setup and i am following the http://www.freeipa.org/page/Active_Directory_trust_setup documentation. I am able to login on freeipa Server with AD users. But when i am trying to login with some other IPA client machine I am not able to to login with AD user. Required firewall port is opened between freeipa server to AD server and freeipa server to freeipa clinets There is no firewall port is opened between from freeipa client to AD server. ================================================================= against addomain from ipaserver :- ipa01 ~]# KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM [24633] 1476069033.462976: Resolving unique ccache of type KEYRING [24633] 1476069033.463027: Getting initial credentials for rajat.g at AD.ADDOMAIN.COM [24633] 1476069033.465229: Sending request (183 bytes) to AD.ADDOMAIN.COM [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com [24633] 1476069033.474439: Sending initial UDP request to dgram 192.168.20.100:88 [24633] 1476069033.487765: Received answer (212 bytes) from dgram 192.168.20.100:88 [24633] 1476069033.488098: Response was not from master KDC [24633] 1476069033.488136: Received error from KDC: -1765328359/Additional pre-authentication required [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2 [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt "AD.ADDOMAIN.COMRajat.Gupta", params "" [24633] 1476069033.488215: PKINIT client has no configured identity; giving up [24633] 1476069033.488233: PKINIT client has no configured identity; giving up [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned: 22/Invalid argument [24633] 1476069033.488250: PKINIT client has no configured identity; giving up [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned: 22/Invalid argument Password for rajat.g at AD.ADDOMAIN.COM: this is working fine. ================================================================= ================================================================= against addomain from ipaclinet :- *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM [4133] 1476067599.43421: Getting initial credentials for rajat.g at AD.ADDOMAIN.COM [4133] 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM * *[4133] 1476067599.49544: Resolving hostname * *ad1.ad.addomain.com .* *[4133] 1476067599.53762: Sending initial UDP request to dgram 192.168.20.100* NOT WORKING ================================================================= ================================================================= against ipdomain from ipaclinet # KRB5_TRACE=/dev/stdout kinit admin at IPA.IPASERVER.LOCAL [4914] 1476068067.763574: Getting initial credentials for admin at IPA.IPASERVER.LOCAL [4914] 1476068067.763889: Sending request (177 bytes) to IPA.IPASERVER.LOCAL [4914] 1476068067.764033: Initiating TCP connection to stream 10.246.104.14:88 [4914] 1476068067.765089: Sending TCP request to stream 192.168.100.100:88 [4914] 1476068067.767593: Received answer (356 bytes) from stream 192.168.100.100:88 [4914] 1476068067.767603: Terminating TCP connection to stream 192.168.100.100:88 [4914] 1476068067.767661: Response was from master KDC [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional pre-authentication required [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133 [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt "k},(k&+qA)Mosf6z", params "" [4914] 1476068067.767747: Received cookie: MIT Password for admin at IPA.IPASERVER.LOCAL: this is working fine. ================================================================= it looks for password-based authentication requests, the IPA clients connect directly to the AD servers using Kerberos. then there is port firewall opening required between ipaclinet and AD Server as well. Is it required ? OR I am doing something wrong. /Rajat -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Oct 10 05:53:42 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Oct 2016 07:53:42 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: <4c4890fc-8f13-267c-bd65-2d4475ae644a@redhat.com> References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> <0a43fba5-a300-27e6-2ef3-c4f8d907cda4@redhat.com> <0eb715f5-5001-a3b2-743d-18fcd38e1a7e@redhat.com> <4c4890fc-8f13-267c-bd65-2d4475ae644a@redhat.com> Message-ID: <0914dd3d-899a-6cd5-9800-b9dbed818437@redhat.com> On 7.10.2016 12:23, Standa Laznicka wrote: > On 10/07/2016 08:31 AM, Jan Cholasta wrote: >> On 17.8.2016 13:47, Stanislav Laznicka wrote: >>> On 08/11/2016 02:59 PM, Stanislav Laznicka wrote: >>>> On 08/11/2016 07:49 AM, Jan Cholasta wrote: >>>>> On 2.8.2016 13:47, Stanislav Laznicka wrote: >>>>>> On 07/19/2016 09:20 AM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 14.7.2016 14:36, Stanislav Laznicka wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >>>>>>>> >>>>>>>> With not so much experience with the framework, it raises question >>>>>>>> in my >>>>>>>> head whether ipaldap.get_entries is used properly throughout the >>>>>>>> system >>>>>>>> - does it always assume that it gets ALL the requested entries or >>>>>>>> just a >>>>>>>> few of those as configured by the 'ipaSearchRecordsLimit' >>>>>>>> attribute of >>>>>>>> ipaConfig.etc which it actually gets? >>>>>>> >>>>>>> That depends. If you call get_entries() on the ldap2 plugin >>>>>>> (which is >>>>>>> usually the case in the framework), then ipaSearchRecordsLimit is >>>>>>> used. If you call it on some arbitrary LDAPClient instance, the >>>>>>> hardcoded default (= unlimited) is used. >>>>>>> >>>>>>>> >>>>>>>> One spot that I know the get_entries method was definitely not used >>>>>>>> properly before this patch is in the >>>>>>>> baseldap.LDAPObject.get_memberindirect() method: >>>>>>>> >>>>>>>> 692 result = self.backend.get_entries( >>>>>>>> 693 self.api.env.basedn, >>>>>>>> 694 filter=filter, >>>>>>>> 695 attrs_list=['member'], >>>>>>>> 696 size_limit=-1, # paged search will get >>>>>>>> everything >>>>>>>> anyway >>>>>>>> 697 paged_search=True) >>>>>>>> >>>>>>>> which to me seems kind of important if the environment size_limit >>>>>>>> is not >>>>>>>> set properly :) The patch does not fix the non-propagation of the >>>>>>>> paged_search, though. >>>>>>> >>>>>>> Why do you think size_limit is not used properly here? >>>>>> AFAIU it is desired that the search is unlimited. However, due to the >>>>>> fact that neither size_limit nor paged_search are passed from >>>>>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from >>>>>> LDAPClient), only the number of records specified by >>>>>> ipaSearchRecordsLimit is returned. That could eventually cause >>>>>> problems >>>>>> should ipaSearchRecordsLimit be set to a low value as in the ticket. >>>>> >>>>> I see. This is *not* intentional, the **kwargs of get_entries() >>>>> should be passed to find_entries(). This definitely needs to be fixed. >>>>> >>>>>>> >>>>>>> Anyway, this ticket is not really easily fixable without more >>>>>>> profound >>>>>>> changes. Often, multiple LDAP searches are done during command >>>>>>> execution. What do you do with the size limit then? Do you pass the >>>>>>> same size limit to all the searches? Do you subtract the result size >>>>>>> from the size limit after each search? Do you do something else with >>>>>>> it? ... The answer is that it depends on the purpose of each >>>>>>> individual LDAP search (like in get_memberindirect() above, we >>>>>>> have to >>>>>>> do unlimited search, otherwise the resulting entry would be >>>>>>> incomplete), and fixing this accross the whole framework is a >>>>>>> non-trivial task. >>>>>>> >>>>>> I do realize that the proposed fix for the permission plugin is not >>>>>> perfect, it would probably be better to subtract the number of >>>>>> currently >>>>>> loaded records from the sizelimit, although in the end the number of >>>>>> returned values will not be higher than the given size_limit. >>>>>> However, >>>>>> it seems reasonable that if get_entries is passed a size limit, it >>>>>> should apply it over current ipaSearchRecordsLimit rather than >>>>>> ignoring >>>>>> it. Then, any use of get_entries could be fixed accordingly if >>>>>> someone >>>>>> sees fit. >>>>>> >>>>> >>>>> Right. Anyway, this is a different issue than above, so please put >>>>> this into a separate commit. >>>>> >>>> Please see the attached patches, then. >>>> >>> Self-NACK, with Honza's help I found there was a mistake in the code. I >>> also found an off-by-one bug which I hope I could stick to the other two >>> patches (attaching only the modified and new patches). >> >> Works for me, but this bit in patch 0064 looks suspicious to me: >> >> + if max_entries > 0 and len(entries) == >> max_entries: >> >> Shouldn't it rather be: >> >> + if max_entries > 0 and len(entries) >= >> max_entries: >> >> ? >> > The length of entries list should not exceed max_entries if size_limit > is properly implemented. Therefore the list you get from execute() > should not have more then max_entries entries. You shouldn't also be > able to append a legacy entry to entries list if this check is the first > thing you do. That's a lot of shoulds :-) I would expect at least an assert statement to make sure everything is right. > > That being said, >= could be used but then some popping of entries from > entries list would be necessary. But it's perhaps safer to do, although > if there's a bug, it won't be that obvious :) OK, nevermind then, just add the assert please, to make bugs *very* obvious. -- Jan Cholasta From jcholast at redhat.com Mon Oct 10 05:57:13 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Oct 2016 07:57:13 +0200 Subject: [Freeipa-devel] [PATCH 0497] Py3: fix unicode/str error in LDAP*ReverseMember In-Reply-To: <8da13b03-de28-baef-f3e8-5e41924b5ae1@redhat.com> References: <2c21c82e-6cc5-ebb4-46ff-be6b60785158@redhat.com> <0c68edcc-5c16-04a5-5bad-a92a69cbeec9@redhat.com> <8775911c-e412-7908-507d-7ea6b230a093@redhat.com> <8da13b03-de28-baef-f3e8-5e41924b5ae1@redhat.com> Message-ID: On 7.6.2016 10:35, Martin Basti wrote: > > > On 07.06.2016 10:35, Jan Cholasta wrote: >> On 7.6.2016 10:29, Martin Basti wrote: >>> >>> >>> On 07.06.2016 09:08, Jan Cholasta wrote: >>>> On 6.6.2016 14:33, Martin Basti wrote: >>>>> https://fedorahosted.org/freeipa/ticket/5923 >>>>> >>>>> Patch attached. >>>> >>>> Could we drop the error message parsing and do something sane instead? >>>> >>> >>> Not now, we can do it later and push this patch just as workaround >> >> What's the point of that? >> > Point is that it will work as before, and I don't have to time to fix it > nicely now. Bump. Do you now have time to fix it nicely, or should we move the ticket to 4.5 or later? -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Oct 10 06:03:00 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Mon, 10 Oct 2016 08:03:00 +0200 Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support pspacek commented: """ I thought that messing with API numbers in VERSION is not be necessary anymore after we introduced thin client. @jcholast ? """ See the full comment at https://github.com/freeipa/freeipa/pull/134#issuecomment-252542215 From freeipa-github-notification at redhat.com Mon Oct 10 06:32:19 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 10 Oct 2016 08:32:19 +0200 Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Title: #10: Client-side CSR autogeneration jcholast commented: """ @LiptonB, I have added some inline comments. Also, have you seen [my latest reply in the design thread](https://www.redhat.com/archives/freeipa-devel/2016-September/msg00082.html)? """ See the full comment at https://github.com/freeipa/freeipa/pull/10#issuecomment-252544625 From slaznick at redhat.com Mon Oct 10 06:47:50 2016 From: slaznick at redhat.com (Standa Laznicka) Date: Mon, 10 Oct 2016 08:47:50 +0200 Subject: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore its size_limit argument In-Reply-To: <0914dd3d-899a-6cd5-9800-b9dbed818437@redhat.com> References: <7a64f453-df5a-0691-746c-1b04c7171f8a@redhat.com> <47ac8912-1caf-bdd8-bb32-fdb29dffffb8@redhat.com> <3b23492e-17e7-13e1-1099-16cfb0963c98@redhat.com> <0a43fba5-a300-27e6-2ef3-c4f8d907cda4@redhat.com> <0eb715f5-5001-a3b2-743d-18fcd38e1a7e@redhat.com> <4c4890fc-8f13-267c-bd65-2d4475ae644a@redhat.com> <0914dd3d-899a-6cd5-9800-b9dbed818437@redhat.com> Message-ID: On 10/10/2016 07:53 AM, Jan Cholasta wrote: > On 7.10.2016 12:23, Standa Laznicka wrote: >> On 10/07/2016 08:31 AM, Jan Cholasta wrote: >>> On 17.8.2016 13:47, Stanislav Laznicka wrote: >>>> On 08/11/2016 02:59 PM, Stanislav Laznicka wrote: >>>>> On 08/11/2016 07:49 AM, Jan Cholasta wrote: >>>>>> On 2.8.2016 13:47, Stanislav Laznicka wrote: >>>>>>> On 07/19/2016 09:20 AM, Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 14.7.2016 14:36, Stanislav Laznicka wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >>>>>>>>> >>>>>>>>> With not so much experience with the framework, it raises >>>>>>>>> question >>>>>>>>> in my >>>>>>>>> head whether ipaldap.get_entries is used properly throughout the >>>>>>>>> system >>>>>>>>> - does it always assume that it gets ALL the requested entries or >>>>>>>>> just a >>>>>>>>> few of those as configured by the 'ipaSearchRecordsLimit' >>>>>>>>> attribute of >>>>>>>>> ipaConfig.etc which it actually gets? >>>>>>>> >>>>>>>> That depends. If you call get_entries() on the ldap2 plugin >>>>>>>> (which is >>>>>>>> usually the case in the framework), then ipaSearchRecordsLimit is >>>>>>>> used. If you call it on some arbitrary LDAPClient instance, the >>>>>>>> hardcoded default (= unlimited) is used. >>>>>>>> >>>>>>>>> >>>>>>>>> One spot that I know the get_entries method was definitely not >>>>>>>>> used >>>>>>>>> properly before this patch is in the >>>>>>>>> baseldap.LDAPObject.get_memberindirect() method: >>>>>>>>> >>>>>>>>> 692 result = self.backend.get_entries( >>>>>>>>> 693 self.api.env.basedn, >>>>>>>>> 694 filter=filter, >>>>>>>>> 695 attrs_list=['member'], >>>>>>>>> 696 size_limit=-1, # paged search will get >>>>>>>>> everything >>>>>>>>> anyway >>>>>>>>> 697 paged_search=True) >>>>>>>>> >>>>>>>>> which to me seems kind of important if the environment size_limit >>>>>>>>> is not >>>>>>>>> set properly :) The patch does not fix the non-propagation of the >>>>>>>>> paged_search, though. >>>>>>>> >>>>>>>> Why do you think size_limit is not used properly here? >>>>>>> AFAIU it is desired that the search is unlimited. However, due >>>>>>> to the >>>>>>> fact that neither size_limit nor paged_search are passed from >>>>>>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from >>>>>>> LDAPClient), only the number of records specified by >>>>>>> ipaSearchRecordsLimit is returned. That could eventually cause >>>>>>> problems >>>>>>> should ipaSearchRecordsLimit be set to a low value as in the >>>>>>> ticket. >>>>>> >>>>>> I see. This is *not* intentional, the **kwargs of get_entries() >>>>>> should be passed to find_entries(). This definitely needs to be >>>>>> fixed. >>>>>> >>>>>>>> >>>>>>>> Anyway, this ticket is not really easily fixable without more >>>>>>>> profound >>>>>>>> changes. Often, multiple LDAP searches are done during command >>>>>>>> execution. What do you do with the size limit then? Do you pass >>>>>>>> the >>>>>>>> same size limit to all the searches? Do you subtract the result >>>>>>>> size >>>>>>>> from the size limit after each search? Do you do something else >>>>>>>> with >>>>>>>> it? ... The answer is that it depends on the purpose of each >>>>>>>> individual LDAP search (like in get_memberindirect() above, we >>>>>>>> have to >>>>>>>> do unlimited search, otherwise the resulting entry would be >>>>>>>> incomplete), and fixing this accross the whole framework is a >>>>>>>> non-trivial task. >>>>>>>> >>>>>>> I do realize that the proposed fix for the permission plugin is not >>>>>>> perfect, it would probably be better to subtract the number of >>>>>>> currently >>>>>>> loaded records from the sizelimit, although in the end the >>>>>>> number of >>>>>>> returned values will not be higher than the given size_limit. >>>>>>> However, >>>>>>> it seems reasonable that if get_entries is passed a size limit, it >>>>>>> should apply it over current ipaSearchRecordsLimit rather than >>>>>>> ignoring >>>>>>> it. Then, any use of get_entries could be fixed accordingly if >>>>>>> someone >>>>>>> sees fit. >>>>>>> >>>>>> >>>>>> Right. Anyway, this is a different issue than above, so please put >>>>>> this into a separate commit. >>>>>> >>>>> Please see the attached patches, then. >>>>> >>>> Self-NACK, with Honza's help I found there was a mistake in the >>>> code. I >>>> also found an off-by-one bug which I hope I could stick to the >>>> other two >>>> patches (attaching only the modified and new patches). >>> >>> Works for me, but this bit in patch 0064 looks suspicious to me: >>> >>> + if max_entries > 0 and len(entries) == >>> max_entries: >>> >>> Shouldn't it rather be: >>> >>> + if max_entries > 0 and len(entries) >= >>> max_entries: >>> >>> ? >>> >> The length of entries list should not exceed max_entries if size_limit >> is properly implemented. Therefore the list you get from execute() >> should not have more then max_entries entries. You shouldn't also be >> able to append a legacy entry to entries list if this check is the first >> thing you do. > > That's a lot of shoulds :-) I would expect at least an assert > statement to make sure everything is right. > >> >> That being said, >= could be used but then some popping of entries from >> entries list would be necessary. But it's perhaps safer to do, although >> if there's a bug, it won't be that obvious :) > > OK, nevermind then, just add the assert please, to make bugs *very* > obvious. > An assert seems like a very good idea, attached is an asserting patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-slaznick-0064-2-permission-find-fix-a-sizelimit-off-by-one-bug.patch Type: text/x-patch Size: 2641 bytes Desc: not available URL: From pspacek at redhat.com Mon Oct 10 06:56:59 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 10 Oct 2016 08:56:59 +0200 Subject: [Freeipa-devel] kinit: Cannot contact any KDC for realm... from Freeipa clinet (Active Directory trust setup) In-Reply-To: References: Message-ID: <74136c2e-87aa-e18a-b16e-d2839ea126e4@redhat.com> On 10.10.2016 05:23, rajat gupta wrote: > Hi, > > I am trying to setup the freeipa Active Directory trust setup and i am > following > the http://www.freeipa.org/page/Active_Directory_trust_setup documentation. > > I am able to login on freeipa Server with AD users. > > But when i am trying to login with some other IPA client machine I am not > able to to login with AD user. > > Required firewall port is opened between freeipa server to AD server and > freeipa server to freeipa clinets > > There is no firewall port is opened between from freeipa client to AD > server. > > ================================================================= > against addomain from ipaserver :- > > ipa01 ~]# KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING > [24633] 1476069033.463027: Getting initial credentials for > rajat.g at AD.ADDOMAIN.COM > [24633] 1476069033.465229: Sending request (183 bytes) to AD.ADDOMAIN.COM > [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com > [24633] 1476069033.474439: Sending initial UDP request to dgram > 192.168.20.100:88 > [24633] 1476069033.487765: Received answer (212 bytes) from dgram > 192.168.20.100:88 > [24633] 1476069033.488098: Response was not from master KDC > [24633] 1476069033.488136: Received error from KDC: -1765328359/Additional > pre-authentication required > [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2 > [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt > "AD.ADDOMAIN.COMRajat.Gupta", params "" > [24633] 1476069033.488215: PKINIT client has no configured identity; giving > up > [24633] 1476069033.488233: PKINIT client has no configured identity; giving > up > [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned: > 22/Invalid argument > [24633] 1476069033.488250: PKINIT client has no configured identity; giving > up > [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned: > 22/Invalid argument > Password for rajat.g at AD.ADDOMAIN.COM: > > this is working fine. > ================================================================= > > > ================================================================= > against addomain from ipaclinet :- > > *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > [4133] 1476067599.43421: Getting initial > credentials for rajat.g at AD.ADDOMAIN.COM [4133] > 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM > * > *[4133] 1476067599.49544: Resolving hostname * > *ad1.ad.addomain.com .* > *[4133] 1476067599.53762: Sending initial UDP request to dgram > 192.168.20.100* > > NOT WORKING > ================================================================= > > ================================================================= > against ipdomain from ipaclinet > > # KRB5_TRACE=/dev/stdout kinit admin at IPA.IPASERVER.LOCAL > [4914] 1476068067.763574: Getting initial credentials for > admin at IPA.IPASERVER.LOCAL > [4914] 1476068067.763889: Sending request (177 bytes) to IPA.IPASERVER.LOCAL > [4914] 1476068067.764033: Initiating TCP connection to stream > 10.246.104.14:88 > [4914] 1476068067.765089: Sending TCP request to stream 192.168.100.100:88 > [4914] 1476068067.767593: Received answer (356 bytes) from stream > 192.168.100.100:88 > [4914] 1476068067.767603: Terminating TCP connection to stream > 192.168.100.100:88 > [4914] 1476068067.767661: Response was from master KDC > [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional > pre-authentication required > [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133 > [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt > "k},(k&+qA)Mosf6z", params "" > [4914] 1476068067.767747: Received cookie: MIT > Password for admin at IPA.IPASERVER.LOCAL: > > this is working fine. > ================================================================= > > > it looks for password-based authentication requests, the IPA clients > connect directly to the AD servers using Kerberos. > > then there is port firewall opening required between ipaclinet and AD > Server as well. Is it required ? OR I am doing something wrong. Yes, IPA clients need to talk to AD servers as well. Please see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#trust-req-ports -- Petr^2 Spacek From freeipa-github-notification at redhat.com Mon Oct 10 07:21:40 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Mon, 10 Oct 2016 09:21:40 +0200 Subject: [Freeipa-devel] [freeipa PR#146][opened] WebUI: fix API Browser menu label Message-ID: URL: https://github.com/freeipa/freeipa/pull/146 Author: pvomacka Title: #146: WebUI: fix API Browser menu label Action: opened PR body: """ The label of API Browser is now in translatable strings and it has uppercase B at the beginnig of second word. https://fedorahosted.org/freeipa/ticket/6384 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/146/head:pr146 git checkout pr146 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-146.patch Type: text/x-diff Size: 2069 bytes Desc: not available URL: From rajat.linux at gmail.com Mon Oct 10 07:39:34 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Mon, 10 Oct 2016 09:39:34 +0200 Subject: [Freeipa-devel] Freeipa-devel Digest, Vol 113, Issue 35 In-Reply-To: References: Message-ID: Hi, https://access.redhat.com/documentation/en-US/Red_Hat_ Enterprise_Linux/7/html/Windows_Integration_Guide/ trust-requirements.html#trust-req-ports these port are required for trust. Is port 88 required to open from ipa client to AD? On Mon, Oct 10, 2016 at 9:21 AM, wrote: > Send Freeipa-devel mailing list submissions to > freeipa-devel at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-devel > or, via email, send a message with subject or body 'help' to > freeipa-devel-request at redhat.com > > You can reach the person managing the list at > freeipa-devel-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-devel digest..." > > > Today's Topics: > > 1. Re: [PATCH 0497] Py3: fix unicode/str error in > LDAP*ReverseMember (Jan Cholasta) > 2. [freeipa PR#134][comment] DNS URI support (pspacek) > 3. [freeipa PR#10][comment] Client-side CSR autogeneration (jcholast) > 4. Re: [PATCH 0058] Make get_entries not ignore its size_limit > argument (Standa Laznicka) > 5. Re: kinit: Cannot contact any KDC for realm... from Freeipa > clinet (Active Directory trust setup) (Petr Spacek) > 6. [freeipa PR#146][opened] WebUI: fix API Browser menu label > (pvomacka) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Oct 2016 07:57:13 +0200 > From: Jan Cholasta > To: Martin Basti , freeipa-devel > > Subject: Re: [Freeipa-devel] [PATCH 0497] Py3: fix unicode/str error > in LDAP*ReverseMember > Message-ID: > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 7.6.2016 10:35, Martin Basti wrote: > > > > > > On 07.06.2016 10:35, Jan Cholasta wrote: > >> On 7.6.2016 10:29, Martin Basti wrote: > >>> > >>> > >>> On 07.06.2016 09:08, Jan Cholasta wrote: > >>>> On 6.6.2016 14:33, Martin Basti wrote: > >>>>> https://fedorahosted.org/freeipa/ticket/5923 > >>>>> > >>>>> Patch attached. > >>>> > >>>> Could we drop the error message parsing and do something sane instead? > >>>> > >>> > >>> Not now, we can do it later and push this patch just as workaround > >> > >> What's the point of that? > >> > > Point is that it will work as before, and I don't have to time to fix it > > nicely now. > > Bump. Do you now have time to fix it nicely, or should we move the > ticket to 4.5 or later? > > -- > Jan Cholasta > > > > ------------------------------ > > Message: 2 > Date: Mon, 10 Oct 2016 08:03:00 +0200 > From: pspacek > To: freeipa-devel at redhat.com > Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support > Message-ID: > ca678c7dbe20 at freeipa-github-notification.redhat.com> > > Content-Type: text/plain; charset="utf-8" > > URL: https://github.com/freeipa/freeipa/pull/134 > Title: #134: DNS URI support > > pspacek commented: > """ > I thought that messing with API numbers in VERSION is not be necessary > anymore after we introduced thin client. @jcholast ? > """ > > See the full comment at https://github.com/freeipa/ > freeipa/pull/134#issuecomment-252542215 > > ------------------------------ > > Message: 3 > Date: Mon, 10 Oct 2016 08:32:19 +0200 > From: jcholast > To: freeipa-devel at redhat.com > Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR > autogeneration > Message-ID: > 8b40194d7acc at freeipa-github-notification.redhat.com> > > Content-Type: text/plain; charset="utf-8" > > URL: https://github.com/freeipa/freeipa/pull/10 > Title: #10: Client-side CSR autogeneration > > jcholast commented: > """ > @LiptonB, I have added some inline comments. > > Also, have you seen [my latest reply in the design thread]( > https://www.redhat.com/archives/freeipa-devel/2016-September/msg00082.html > )? > """ > > See the full comment at https://github.com/freeipa/ > freeipa/pull/10#issuecomment-252544625 > > ------------------------------ > > Message: 4 > Date: Mon, 10 Oct 2016 08:47:50 +0200 > From: Standa Laznicka > To: Jan Cholasta , freeipa-devel > > Subject: Re: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore > its size_limit argument > Message-ID: > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > On 10/10/2016 07:53 AM, Jan Cholasta wrote: > > On 7.10.2016 12:23, Standa Laznicka wrote: > >> On 10/07/2016 08:31 AM, Jan Cholasta wrote: > >>> On 17.8.2016 13:47, Stanislav Laznicka wrote: > >>>> On 08/11/2016 02:59 PM, Stanislav Laznicka wrote: > >>>>> On 08/11/2016 07:49 AM, Jan Cholasta wrote: > >>>>>> On 2.8.2016 13:47, Stanislav Laznicka wrote: > >>>>>>> On 07/19/2016 09:20 AM, Jan Cholasta wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> On 14.7.2016 14:36, Stanislav Laznicka wrote: > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. > >>>>>>>>> > >>>>>>>>> With not so much experience with the framework, it raises > >>>>>>>>> question > >>>>>>>>> in my > >>>>>>>>> head whether ipaldap.get_entries is used properly throughout the > >>>>>>>>> system > >>>>>>>>> - does it always assume that it gets ALL the requested entries or > >>>>>>>>> just a > >>>>>>>>> few of those as configured by the 'ipaSearchRecordsLimit' > >>>>>>>>> attribute of > >>>>>>>>> ipaConfig.etc which it actually gets? > >>>>>>>> > >>>>>>>> That depends. If you call get_entries() on the ldap2 plugin > >>>>>>>> (which is > >>>>>>>> usually the case in the framework), then ipaSearchRecordsLimit is > >>>>>>>> used. If you call it on some arbitrary LDAPClient instance, the > >>>>>>>> hardcoded default (= unlimited) is used. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> One spot that I know the get_entries method was definitely not > >>>>>>>>> used > >>>>>>>>> properly before this patch is in the > >>>>>>>>> baseldap.LDAPObject.get_memberindirect() method: > >>>>>>>>> > >>>>>>>>> 692 result = self.backend.get_entries( > >>>>>>>>> 693 self.api.env.basedn, > >>>>>>>>> 694 filter=filter, > >>>>>>>>> 695 attrs_list=['member'], > >>>>>>>>> 696 size_limit=-1, # paged search will get > >>>>>>>>> everything > >>>>>>>>> anyway > >>>>>>>>> 697 paged_search=True) > >>>>>>>>> > >>>>>>>>> which to me seems kind of important if the environment size_limit > >>>>>>>>> is not > >>>>>>>>> set properly :) The patch does not fix the non-propagation of the > >>>>>>>>> paged_search, though. > >>>>>>>> > >>>>>>>> Why do you think size_limit is not used properly here? > >>>>>>> AFAIU it is desired that the search is unlimited. However, due > >>>>>>> to the > >>>>>>> fact that neither size_limit nor paged_search are passed from > >>>>>>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from > >>>>>>> LDAPClient), only the number of records specified by > >>>>>>> ipaSearchRecordsLimit is returned. That could eventually cause > >>>>>>> problems > >>>>>>> should ipaSearchRecordsLimit be set to a low value as in the > >>>>>>> ticket. > >>>>>> > >>>>>> I see. This is *not* intentional, the **kwargs of get_entries() > >>>>>> should be passed to find_entries(). This definitely needs to be > >>>>>> fixed. > >>>>>> > >>>>>>>> > >>>>>>>> Anyway, this ticket is not really easily fixable without more > >>>>>>>> profound > >>>>>>>> changes. Often, multiple LDAP searches are done during command > >>>>>>>> execution. What do you do with the size limit then? Do you pass > >>>>>>>> the > >>>>>>>> same size limit to all the searches? Do you subtract the result > >>>>>>>> size > >>>>>>>> from the size limit after each search? Do you do something else > >>>>>>>> with > >>>>>>>> it? ... The answer is that it depends on the purpose of each > >>>>>>>> individual LDAP search (like in get_memberindirect() above, we > >>>>>>>> have to > >>>>>>>> do unlimited search, otherwise the resulting entry would be > >>>>>>>> incomplete), and fixing this accross the whole framework is a > >>>>>>>> non-trivial task. > >>>>>>>> > >>>>>>> I do realize that the proposed fix for the permission plugin is not > >>>>>>> perfect, it would probably be better to subtract the number of > >>>>>>> currently > >>>>>>> loaded records from the sizelimit, although in the end the > >>>>>>> number of > >>>>>>> returned values will not be higher than the given size_limit. > >>>>>>> However, > >>>>>>> it seems reasonable that if get_entries is passed a size limit, it > >>>>>>> should apply it over current ipaSearchRecordsLimit rather than > >>>>>>> ignoring > >>>>>>> it. Then, any use of get_entries could be fixed accordingly if > >>>>>>> someone > >>>>>>> sees fit. > >>>>>>> > >>>>>> > >>>>>> Right. Anyway, this is a different issue than above, so please put > >>>>>> this into a separate commit. > >>>>>> > >>>>> Please see the attached patches, then. > >>>>> > >>>> Self-NACK, with Honza's help I found there was a mistake in the > >>>> code. I > >>>> also found an off-by-one bug which I hope I could stick to the > >>>> other two > >>>> patches (attaching only the modified and new patches). > >>> > >>> Works for me, but this bit in patch 0064 looks suspicious to me: > >>> > >>> + if max_entries > 0 and len(entries) == > >>> max_entries: > >>> > >>> Shouldn't it rather be: > >>> > >>> + if max_entries > 0 and len(entries) >= > >>> max_entries: > >>> > >>> ? > >>> > >> The length of entries list should not exceed max_entries if size_limit > >> is properly implemented. Therefore the list you get from execute() > >> should not have more then max_entries entries. You shouldn't also be > >> able to append a legacy entry to entries list if this check is the first > >> thing you do. > > > > That's a lot of shoulds :-) I would expect at least an assert > > statement to make sure everything is right. > > > >> > >> That being said, >= could be used but then some popping of entries from > >> entries list would be necessary. But it's perhaps safer to do, although > >> if there's a bug, it won't be that obvious :) > > > > OK, nevermind then, just add the assert please, to make bugs *very* > > obvious. > > > An assert seems like a very good idea, attached is an asserting patch. > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: freeipa-slaznick-0064-2-permission-find-fix-a- > sizelimit-off-by-one-bug.patch > Type: text/x-patch > Size: 2640 bytes > Desc: not available > URL: attachments/20161010/eddd5901/attachment.bin> > > ------------------------------ > > Message: 5 > Date: Mon, 10 Oct 2016 08:56:59 +0200 > From: Petr Spacek > To: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] kinit: Cannot contact any KDC for > realm... from Freeipa clinet (Active Directory trust setup) > Message-ID: <74136c2e-87aa-e18a-b16e-d2839ea126e4 at redhat.com> > Content-Type: text/plain; charset=windows-1252 > > On 10.10.2016 05:23, rajat gupta wrote: > > Hi, > > > > I am trying to setup the freeipa Active Directory trust setup and i am > > following > > the http://www.freeipa.org/page/Active_Directory_trust_setup > documentation. > > > > I am able to login on freeipa Server with AD users. > > > > But when i am trying to login with some other IPA client machine I am not > > able to to login with AD user. > > > > Required firewall port is opened between freeipa server to AD server and > > freeipa server to freeipa clinets > > > > There is no firewall port is opened between from freeipa client to AD > > server. > > > > ================================================================= > > against addomain from ipaserver :- > > > > ipa01 ~]# KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING > > [24633] 1476069033.463027: Getting initial credentials for > > rajat.g at AD.ADDOMAIN.COM > > [24633] 1476069033.465229: Sending request (183 bytes) to > AD.ADDOMAIN.COM > > [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com > > [24633] 1476069033.474439: Sending initial UDP request to dgram > > 192.168.20.100:88 > > [24633] 1476069033.487765: Received answer (212 bytes) from dgram > > 192.168.20.100:88 > > [24633] 1476069033.488098: Response was not from master KDC > > [24633] 1476069033.488136: Received error from KDC: > -1765328359/Additional > > pre-authentication required > > [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2 > > [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt > > "AD.ADDOMAIN.COMRajat.Gupta", params "" > > [24633] 1476069033.488215: PKINIT client has no configured identity; > giving > > up > > [24633] 1476069033.488233: PKINIT client has no configured identity; > giving > > up > > [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned: > > 22/Invalid argument > > [24633] 1476069033.488250: PKINIT client has no configured identity; > giving > > up > > [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned: > > 22/Invalid argument > > Password for rajat.g at AD.ADDOMAIN.COM: > > > > this is working fine. > > ================================================================= > > > > > > ================================================================= > > against addomain from ipaclinet :- > > > > *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > > [4133] 1476067599.43421: Getting initial > > credentials for rajat.g at AD.ADDOMAIN.COM [4133] > > 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM > > * > > *[4133] 1476067599.49544: Resolving hostname * > > *ad1.ad.addomain.com .* > > *[4133] 1476067599.53762: Sending initial UDP request to dgram > > 192.168.20.100* > > > > NOT WORKING > > ================================================================= > > > > ================================================================= > > against ipdomain from ipaclinet > > > > # KRB5_TRACE=/dev/stdout kinit admin at IPA.IPASERVER.LOCAL > > [4914] 1476068067.763574: Getting initial credentials for > > admin at IPA.IPASERVER.LOCAL > > [4914] 1476068067.763889: Sending request (177 bytes) to > IPA.IPASERVER.LOCAL > > [4914] 1476068067.764033: Initiating TCP connection to stream > > 10.246.104.14:88 > > [4914] 1476068067.765089: Sending TCP request to stream > 192.168.100.100:88 > > [4914] 1476068067.767593: Received answer (356 bytes) from stream > > 192.168.100.100:88 > > [4914] 1476068067.767603: Terminating TCP connection to stream > > 192.168.100.100:88 > > [4914] 1476068067.767661: Response was from master KDC > > [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional > > pre-authentication required > > [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133 > > [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt > > "k},(k&+qA)Mosf6z", params "" > > [4914] 1476068067.767747: Received cookie: MIT > > Password for admin at IPA.IPASERVER.LOCAL: > > > > this is working fine. > > ================================================================= > > > > > > it looks for password-based authentication requests, the IPA clients > > connect directly to the AD servers using Kerberos. > > > > then there is port firewall opening required between ipaclinet and AD > > Server as well. Is it required ? OR I am doing something wrong. > > Yes, IPA clients need to talk to AD servers as well. Please see > https://access.redhat.com/documentation/en-US/Red_Hat_ > Enterprise_Linux/7/html/Windows_Integration_Guide/ > trust-requirements.html#trust-req-ports > > > -- > Petr^2 Spacek > > > > ------------------------------ > > Message: 6 > Date: Mon, 10 Oct 2016 09:21:40 +0200 > From: pvomacka > To: freeipa-devel at redhat.com > Subject: [Freeipa-devel] [freeipa PR#146][opened] WebUI: fix API > Browser menu label > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > URL: https://github.com/freeipa/freeipa/pull/146 > Author: pvomacka > Title: #146: WebUI: fix API Browser menu label > Action: opened > > PR body: > """ > The label of API Browser is now in translatable strings and it has > uppercase B at the beginnig of second word. > > https://fedorahosted.org/freeipa/ticket/6384 > """ > > To pull the PR as Git branch: > git remote add ghfreeipa https://github.com/freeipa/freeipa > git fetch ghfreeipa pull/146/head:pr146 > git checkout pr146 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: freeipa-pr-146.patch > Type: text/x-diff > Size: 2069 bytes > Desc: not available > URL: attachments/20161010/5dc80c2e/attachment.bin> > > ------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > End of Freeipa-devel Digest, Vol 113, Issue 35 > ********************************************** > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajat.linux at gmail.com Mon Oct 10 07:43:24 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Mon, 10 Oct 2016 09:43:24 +0200 Subject: [Freeipa-devel] kinit: Cannot contact any KDC for realm... from Freeipa clinet (Active Directory trust setup) In-Reply-To: References: Message-ID: https://access.redhat.com/documentation/en-US/Red_Hat_ Enterprise_Linux/7/html/Windows_Integration_Guide/ trust-requirements.html#trust-req-ports these port are required for trust. Is port 88 required to open from ipa client to AD? On Mon, Oct 10, 2016 at 5:23 AM, rajat gupta wrote: > Hi, > > I am trying to setup the freeipa Active Directory trust setup and i am > following > the http://www.freeipa.org/page/Active_Directory_trust_setup > documentation. > > I am able to login on freeipa Server with AD users. > > But when i am trying to login with some other IPA client machine I am not > able to to login with AD user. > > Required firewall port is opened between freeipa server to AD server and > freeipa server to freeipa clinets > > There is no firewall port is opened between from freeipa client to AD > server. > > ================================================================= > against addomain from ipaserver :- > > ipa01 ~]# KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING > [24633] 1476069033.463027: Getting initial credentials for > rajat.g at AD.ADDOMAIN.COM > [24633] 1476069033.465229: Sending request (183 bytes) to AD.ADDOMAIN.COM > [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com > [24633] 1476069033.474439: Sending initial UDP request to dgram > 192.168.20.100:88 > [24633] 1476069033.487765: Received answer (212 bytes) from dgram > 192.168.20.100:88 > [24633] 1476069033.488098: Response was not from master KDC > [24633] 1476069033.488136: Received error from KDC: -1765328359/Additional > pre-authentication required > [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2 > [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt > "AD.ADDOMAIN.COMRajat.Gupta", params "" > [24633] 1476069033.488215: PKINIT client has no configured identity; > giving up > [24633] 1476069033.488233: PKINIT client has no configured identity; > giving up > [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned: > 22/Invalid argument > [24633] 1476069033.488250: PKINIT client has no configured identity; > giving up > [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned: > 22/Invalid argument > Password for rajat.g at AD.ADDOMAIN.COM: > > this is working fine. > ================================================================= > > > ================================================================= > against addomain from ipaclinet :- > > *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > [4133] 1476067599.43421: Getting initial > credentials for rajat.g at AD.ADDOMAIN.COM [4133] > 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM > * > *[4133] 1476067599.49544: Resolving hostname * > *ad1.ad.addomain.com .* > *[4133] 1476067599.53762: Sending initial UDP request to dgram > 192.168.20.100* > > NOT WORKING > ================================================================= > > ================================================================= > against ipdomain from ipaclinet > > # KRB5_TRACE=/dev/stdout kinit admin at IPA.IPASERVER.LOCAL > [4914] 1476068067.763574: Getting initial credentials for > admin at IPA.IPASERVER.LOCAL > [4914] 1476068067.763889: Sending request (177 bytes) to > IPA.IPASERVER.LOCAL > [4914] 1476068067.764033: Initiating TCP connection to stream > 10.246.104.14:88 > [4914] 1476068067.765089: Sending TCP request to stream 192.168.100.100:88 > [4914] 1476068067.767593: Received answer (356 bytes) from stream > 192.168.100.100:88 > [4914] 1476068067.767603: Terminating TCP connection to stream > 192.168.100.100:88 > [4914] 1476068067.767661: Response was from master KDC > [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional > pre-authentication required > [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133 > [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt > "k},(k&+qA)Mosf6z", params "" > [4914] 1476068067.767747: Received cookie: MIT > Password for admin at IPA.IPASERVER.LOCAL: > > this is working fine. > ================================================================= > > > it looks for password-based authentication requests, the IPA clients > connect directly to the AD servers using Kerberos. > > then there is port firewall opening required between ipaclinet and AD > Server as well. Is it required ? OR I am doing something wrong. > > /Rajat > > > > > > > > > -- > > *Rajat Gupta * > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Oct 10 07:55:55 2016 From: sbose at redhat.com (Sumit Bose) Date: Mon, 10 Oct 2016 09:55:55 +0200 Subject: [Freeipa-devel] kinit: Cannot contact any KDC for realm... from Freeipa clinet (Active Directory trust setup) In-Reply-To: References: Message-ID: <20161010075555.GA4864@p.Speedport_W_724V_Typ_A_05011603_00_009> On Mon, Oct 10, 2016 at 09:43:24AM +0200, rajat gupta wrote: > https://access.redhat.com/documentation/en-US/Red_Hat_ > Enterprise_Linux/7/html/Windows_Integration_Guide/ > trust-requirements.html#trust-req-ports > > these port are required for trust. Is port 88 required to open from ipa > client to AD? Yes, in general the clients need to talk directly to the AD DC because you do not want a man-in-the-middle during authentication. For special environments it is possible to setup a KDC proxy, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_a_Kerberos_5_Server.html#KKDCP for details. HTH bye, Sumit > > > On Mon, Oct 10, 2016 at 5:23 AM, rajat gupta wrote: > > > Hi, > > > > I am trying to setup the freeipa Active Directory trust setup and i am > > following > > the http://www.freeipa.org/page/Active_Directory_trust_setup > > documentation. > > > > I am able to login on freeipa Server with AD users. > > > > But when i am trying to login with some other IPA client machine I am not > > able to to login with AD user. > > > > Required firewall port is opened between freeipa server to AD server and > > freeipa server to freeipa clinets > > > > There is no firewall port is opened between from freeipa client to AD > > server. > > > > ================================================================= > > against addomain from ipaserver :- > > > > ipa01 ~]# KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING > > [24633] 1476069033.463027: Getting initial credentials for > > rajat.g at AD.ADDOMAIN.COM > > [24633] 1476069033.465229: Sending request (183 bytes) to AD.ADDOMAIN.COM > > [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com > > [24633] 1476069033.474439: Sending initial UDP request to dgram > > 192.168.20.100:88 > > [24633] 1476069033.487765: Received answer (212 bytes) from dgram > > 192.168.20.100:88 > > [24633] 1476069033.488098: Response was not from master KDC > > [24633] 1476069033.488136: Received error from KDC: -1765328359/Additional > > pre-authentication required > > [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2 > > [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt > > "AD.ADDOMAIN.COMRajat.Gupta", params "" > > [24633] 1476069033.488215: PKINIT client has no configured identity; > > giving up > > [24633] 1476069033.488233: PKINIT client has no configured identity; > > giving up > > [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned: > > 22/Invalid argument > > [24633] 1476069033.488250: PKINIT client has no configured identity; > > giving up > > [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned: > > 22/Invalid argument > > Password for rajat.g at AD.ADDOMAIN.COM: > > > > this is working fine. > > ================================================================= > > > > > > ================================================================= > > against addomain from ipaclinet :- > > > > *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM > > [4133] 1476067599.43421: Getting initial > > credentials for rajat.g at AD.ADDOMAIN.COM [4133] > > 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM > > * > > *[4133] 1476067599.49544: Resolving hostname * > > *ad1.ad.addomain.com .* > > *[4133] 1476067599.53762: Sending initial UDP request to dgram > > 192.168.20.100* > > > > NOT WORKING > > ================================================================= > > > > ================================================================= > > against ipdomain from ipaclinet > > > > # KRB5_TRACE=/dev/stdout kinit admin at IPA.IPASERVER.LOCAL > > [4914] 1476068067.763574: Getting initial credentials for > > admin at IPA.IPASERVER.LOCAL > > [4914] 1476068067.763889: Sending request (177 bytes) to > > IPA.IPASERVER.LOCAL > > [4914] 1476068067.764033: Initiating TCP connection to stream > > 10.246.104.14:88 > > [4914] 1476068067.765089: Sending TCP request to stream 192.168.100.100:88 > > [4914] 1476068067.767593: Received answer (356 bytes) from stream > > 192.168.100.100:88 > > [4914] 1476068067.767603: Terminating TCP connection to stream > > 192.168.100.100:88 > > [4914] 1476068067.767661: Response was from master KDC > > [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional > > pre-authentication required > > [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133 > > [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt > > "k},(k&+qA)Mosf6z", params "" > > [4914] 1476068067.767747: Received cookie: MIT > > Password for admin at IPA.IPASERVER.LOCAL: > > > > this is working fine. > > ================================================================= > > > > > > it looks for password-based authentication requests, the IPA clients > > connect directly to the AD servers using Kerberos. > > > > then there is port firewall opening required between ipaclinet and AD > > Server as well. Is it required ? OR I am doing something wrong. > > > > /Rajat > > > > > > > > > > > > > > > > > > -- > > > > *Rajat Gupta * > > > > > > -- > > *Rajat Gupta * > -- > 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 From abokovoy at redhat.com Mon Oct 10 08:21:44 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 10 Oct 2016 11:21:44 +0300 Subject: [Freeipa-devel] Freeipa-devel Digest, Vol 113, Issue 35 In-Reply-To: References: Message-ID: <20161010082144.wqniunleupo2a3fq@redhat.com> On ma, 10 loka 2016, rajat gupta wrote: >Hi, > >https://access.redhat.com/documentation/en-US/Red_Hat_ >Enterprise_Linux/7/html/Windows_Integration_Guide/ >trust-requirements.html#trust-req-ports > >these port are required for trust. Is port 88 required to open from ipa >client to AD? Yes. Port 88 tcp/udp. Authentication is always done by the authoritative source. In case of AD users, an authoritative source would be AD DCs of the corresponding AD domain. If you login with GSSAPI Kerberos as AD user, then your client software would present a Kerberos ticket to some IPA service that it obtained from IPA KDC by way of presenting a cross-realm TGT which was obtained from own AD DCs. SSSD on IPA side would still do validation of the ticket. If you login with password as AD user, SSSD would obtain initial Kerberos ticket (TGT) by authenticating as AD user with that password. It would try to do 'kinit'-like procedure against its own IPA KDC. IPA KDC will return a client-side referral which points to AD realm of that AD user and Kerberos library on IPA client will perform referral chasing to find out an AD DC. Thus, IPA clients need to know about AD domains and have Kerberos access to them. If you want to support password change from IPA client side for AD users, you also need to allow Kerberos kpasswd protocol support (port 464 tcp/udp). With FreeIPA 4.2 or later we support KDC proxy over HTTPS (MS-KKDCP) protocol. Technically this means you can force all IPA clients to always talk to IPA masters with Kerberos and then IPA masters would rely Kerberos requests to AD DCs. This is useful in DMZ scenarios. However, password change cannot be proxied this way. > >On Mon, Oct 10, 2016 at 9:21 AM, wrote: > >> Send Freeipa-devel mailing list submissions to >> freeipa-devel at redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> or, via email, send a message with subject or body 'help' to >> freeipa-devel-request at redhat.com >> >> You can reach the person managing the list at >> freeipa-devel-owner at redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Freeipa-devel digest..." >> >> >> Today's Topics: >> >> 1. Re: [PATCH 0497] Py3: fix unicode/str error in >> LDAP*ReverseMember (Jan Cholasta) >> 2. [freeipa PR#134][comment] DNS URI support (pspacek) >> 3. [freeipa PR#10][comment] Client-side CSR autogeneration (jcholast) >> 4. Re: [PATCH 0058] Make get_entries not ignore its size_limit >> argument (Standa Laznicka) >> 5. Re: kinit: Cannot contact any KDC for realm... from Freeipa >> clinet (Active Directory trust setup) (Petr Spacek) >> 6. [freeipa PR#146][opened] WebUI: fix API Browser menu label >> (pvomacka) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 10 Oct 2016 07:57:13 +0200 >> From: Jan Cholasta >> To: Martin Basti , freeipa-devel >> >> Subject: Re: [Freeipa-devel] [PATCH 0497] Py3: fix unicode/str error >> in LDAP*ReverseMember >> Message-ID: >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> On 7.6.2016 10:35, Martin Basti wrote: >> > >> > >> > On 07.06.2016 10:35, Jan Cholasta wrote: >> >> On 7.6.2016 10:29, Martin Basti wrote: >> >>> >> >>> >> >>> On 07.06.2016 09:08, Jan Cholasta wrote: >> >>>> On 6.6.2016 14:33, Martin Basti wrote: >> >>>>> https://fedorahosted.org/freeipa/ticket/5923 >> >>>>> >> >>>>> Patch attached. >> >>>> >> >>>> Could we drop the error message parsing and do something sane instead? >> >>>> >> >>> >> >>> Not now, we can do it later and push this patch just as workaround >> >> >> >> What's the point of that? >> >> >> > Point is that it will work as before, and I don't have to time to fix it >> > nicely now. >> >> Bump. Do you now have time to fix it nicely, or should we move the >> ticket to 4.5 or later? >> >> -- >> Jan Cholasta >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 10 Oct 2016 08:03:00 +0200 >> From: pspacek >> To: freeipa-devel at redhat.com >> Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support >> Message-ID: >> > ca678c7dbe20 at freeipa-github-notification.redhat.com> >> >> Content-Type: text/plain; charset="utf-8" >> >> URL: https://github.com/freeipa/freeipa/pull/134 >> Title: #134: DNS URI support >> >> pspacek commented: >> """ >> I thought that messing with API numbers in VERSION is not be necessary >> anymore after we introduced thin client. @jcholast ? >> """ >> >> See the full comment at https://github.com/freeipa/ >> freeipa/pull/134#issuecomment-252542215 >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 10 Oct 2016 08:32:19 +0200 >> From: jcholast >> To: freeipa-devel at redhat.com >> Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR >> autogeneration >> Message-ID: >> > 8b40194d7acc at freeipa-github-notification.redhat.com> >> >> Content-Type: text/plain; charset="utf-8" >> >> URL: https://github.com/freeipa/freeipa/pull/10 >> Title: #10: Client-side CSR autogeneration >> >> jcholast commented: >> """ >> @LiptonB, I have added some inline comments. >> >> Also, have you seen [my latest reply in the design thread]( >> https://www.redhat.com/archives/freeipa-devel/2016-September/msg00082.html >> )? >> """ >> >> See the full comment at https://github.com/freeipa/ >> freeipa/pull/10#issuecomment-252544625 >> >> ------------------------------ >> >> Message: 4 >> Date: Mon, 10 Oct 2016 08:47:50 +0200 >> From: Standa Laznicka >> To: Jan Cholasta , freeipa-devel >> >> Subject: Re: [Freeipa-devel] [PATCH 0058] Make get_entries not ignore >> its size_limit argument >> Message-ID: >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >> >> On 10/10/2016 07:53 AM, Jan Cholasta wrote: >> > On 7.10.2016 12:23, Standa Laznicka wrote: >> >> On 10/07/2016 08:31 AM, Jan Cholasta wrote: >> >>> On 17.8.2016 13:47, Stanislav Laznicka wrote: >> >>>> On 08/11/2016 02:59 PM, Stanislav Laznicka wrote: >> >>>>> On 08/11/2016 07:49 AM, Jan Cholasta wrote: >> >>>>>> On 2.8.2016 13:47, Stanislav Laznicka wrote: >> >>>>>>> On 07/19/2016 09:20 AM, Jan Cholasta wrote: >> >>>>>>>> Hi, >> >>>>>>>> >> >>>>>>>> On 14.7.2016 14:36, Stanislav Laznicka wrote: >> >>>>>>>>> Hello, >> >>>>>>>>> >> >>>>>>>>> This patch fixes https://fedorahosted.org/freeipa/ticket/5640. >> >>>>>>>>> >> >>>>>>>>> With not so much experience with the framework, it raises >> >>>>>>>>> question >> >>>>>>>>> in my >> >>>>>>>>> head whether ipaldap.get_entries is used properly throughout the >> >>>>>>>>> system >> >>>>>>>>> - does it always assume that it gets ALL the requested entries or >> >>>>>>>>> just a >> >>>>>>>>> few of those as configured by the 'ipaSearchRecordsLimit' >> >>>>>>>>> attribute of >> >>>>>>>>> ipaConfig.etc which it actually gets? >> >>>>>>>> >> >>>>>>>> That depends. If you call get_entries() on the ldap2 plugin >> >>>>>>>> (which is >> >>>>>>>> usually the case in the framework), then ipaSearchRecordsLimit is >> >>>>>>>> used. If you call it on some arbitrary LDAPClient instance, the >> >>>>>>>> hardcoded default (= unlimited) is used. >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> One spot that I know the get_entries method was definitely not >> >>>>>>>>> used >> >>>>>>>>> properly before this patch is in the >> >>>>>>>>> baseldap.LDAPObject.get_memberindirect() method: >> >>>>>>>>> >> >>>>>>>>> 692 result = self.backend.get_entries( >> >>>>>>>>> 693 self.api.env.basedn, >> >>>>>>>>> 694 filter=filter, >> >>>>>>>>> 695 attrs_list=['member'], >> >>>>>>>>> 696 size_limit=-1, # paged search will get >> >>>>>>>>> everything >> >>>>>>>>> anyway >> >>>>>>>>> 697 paged_search=True) >> >>>>>>>>> >> >>>>>>>>> which to me seems kind of important if the environment size_limit >> >>>>>>>>> is not >> >>>>>>>>> set properly :) The patch does not fix the non-propagation of the >> >>>>>>>>> paged_search, though. >> >>>>>>>> >> >>>>>>>> Why do you think size_limit is not used properly here? >> >>>>>>> AFAIU it is desired that the search is unlimited. However, due >> >>>>>>> to the >> >>>>>>> fact that neither size_limit nor paged_search are passed from >> >>>>>>> ldap2.get_entries() to ldap2.find_entries() (methods inherited from >> >>>>>>> LDAPClient), only the number of records specified by >> >>>>>>> ipaSearchRecordsLimit is returned. That could eventually cause >> >>>>>>> problems >> >>>>>>> should ipaSearchRecordsLimit be set to a low value as in the >> >>>>>>> ticket. >> >>>>>> >> >>>>>> I see. This is *not* intentional, the **kwargs of get_entries() >> >>>>>> should be passed to find_entries(). This definitely needs to be >> >>>>>> fixed. >> >>>>>> >> >>>>>>>> >> >>>>>>>> Anyway, this ticket is not really easily fixable without more >> >>>>>>>> profound >> >>>>>>>> changes. Often, multiple LDAP searches are done during command >> >>>>>>>> execution. What do you do with the size limit then? Do you pass >> >>>>>>>> the >> >>>>>>>> same size limit to all the searches? Do you subtract the result >> >>>>>>>> size >> >>>>>>>> from the size limit after each search? Do you do something else >> >>>>>>>> with >> >>>>>>>> it? ... The answer is that it depends on the purpose of each >> >>>>>>>> individual LDAP search (like in get_memberindirect() above, we >> >>>>>>>> have to >> >>>>>>>> do unlimited search, otherwise the resulting entry would be >> >>>>>>>> incomplete), and fixing this accross the whole framework is a >> >>>>>>>> non-trivial task. >> >>>>>>>> >> >>>>>>> I do realize that the proposed fix for the permission plugin is not >> >>>>>>> perfect, it would probably be better to subtract the number of >> >>>>>>> currently >> >>>>>>> loaded records from the sizelimit, although in the end the >> >>>>>>> number of >> >>>>>>> returned values will not be higher than the given size_limit. >> >>>>>>> However, >> >>>>>>> it seems reasonable that if get_entries is passed a size limit, it >> >>>>>>> should apply it over current ipaSearchRecordsLimit rather than >> >>>>>>> ignoring >> >>>>>>> it. Then, any use of get_entries could be fixed accordingly if >> >>>>>>> someone >> >>>>>>> sees fit. >> >>>>>>> >> >>>>>> >> >>>>>> Right. Anyway, this is a different issue than above, so please put >> >>>>>> this into a separate commit. >> >>>>>> >> >>>>> Please see the attached patches, then. >> >>>>> >> >>>> Self-NACK, with Honza's help I found there was a mistake in the >> >>>> code. I >> >>>> also found an off-by-one bug which I hope I could stick to the >> >>>> other two >> >>>> patches (attaching only the modified and new patches). >> >>> >> >>> Works for me, but this bit in patch 0064 looks suspicious to me: >> >>> >> >>> + if max_entries > 0 and len(entries) == >> >>> max_entries: >> >>> >> >>> Shouldn't it rather be: >> >>> >> >>> + if max_entries > 0 and len(entries) >= >> >>> max_entries: >> >>> >> >>> ? >> >>> >> >> The length of entries list should not exceed max_entries if size_limit >> >> is properly implemented. Therefore the list you get from execute() >> >> should not have more then max_entries entries. You shouldn't also be >> >> able to append a legacy entry to entries list if this check is the first >> >> thing you do. >> > >> > That's a lot of shoulds :-) I would expect at least an assert >> > statement to make sure everything is right. >> > >> >> >> >> That being said, >= could be used but then some popping of entries from >> >> entries list would be necessary. But it's perhaps safer to do, although >> >> if there's a bug, it won't be that obvious :) >> > >> > OK, nevermind then, just add the assert please, to make bugs *very* >> > obvious. >> > >> An assert seems like a very good idea, attached is an asserting patch. >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: freeipa-slaznick-0064-2-permission-find-fix-a- >> sizelimit-off-by-one-bug.patch >> Type: text/x-patch >> Size: 2640 bytes >> Desc: not available >> URL: > attachments/20161010/eddd5901/attachment.bin> >> >> ------------------------------ >> >> Message: 5 >> Date: Mon, 10 Oct 2016 08:56:59 +0200 >> From: Petr Spacek >> To: freeipa-devel at redhat.com >> Subject: Re: [Freeipa-devel] kinit: Cannot contact any KDC for >> realm... from Freeipa clinet (Active Directory trust setup) >> Message-ID: <74136c2e-87aa-e18a-b16e-d2839ea126e4 at redhat.com> >> Content-Type: text/plain; charset=windows-1252 >> >> On 10.10.2016 05:23, rajat gupta wrote: >> > Hi, >> > >> > I am trying to setup the freeipa Active Directory trust setup and i am >> > following >> > the http://www.freeipa.org/page/Active_Directory_trust_setup >> documentation. >> > >> > I am able to login on freeipa Server with AD users. >> > >> > But when i am trying to login with some other IPA client machine I am not >> > able to to login with AD user. >> > >> > Required firewall port is opened between freeipa server to AD server and >> > freeipa server to freeipa clinets >> > >> > There is no firewall port is opened between from freeipa client to AD >> > server. >> > >> > ================================================================= >> > against addomain from ipaserver :- >> > >> > ipa01 ~]# KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM >> > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING >> > [24633] 1476069033.463027: Getting initial credentials for >> > rajat.g at AD.ADDOMAIN.COM >> > [24633] 1476069033.465229: Sending request (183 bytes) to >> AD.ADDOMAIN.COM >> > [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com >> > [24633] 1476069033.474439: Sending initial UDP request to dgram >> > 192.168.20.100:88 >> > [24633] 1476069033.487765: Received answer (212 bytes) from dgram >> > 192.168.20.100:88 >> > [24633] 1476069033.488098: Response was not from master KDC >> > [24633] 1476069033.488136: Received error from KDC: >> -1765328359/Additional >> > pre-authentication required >> > [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2 >> > [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt >> > "AD.ADDOMAIN.COMRajat.Gupta", params "" >> > [24633] 1476069033.488215: PKINIT client has no configured identity; >> giving >> > up >> > [24633] 1476069033.488233: PKINIT client has no configured identity; >> giving >> > up >> > [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned: >> > 22/Invalid argument >> > [24633] 1476069033.488250: PKINIT client has no configured identity; >> giving >> > up >> > [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned: >> > 22/Invalid argument >> > Password for rajat.g at AD.ADDOMAIN.COM: >> > >> > this is working fine. >> > ================================================================= >> > >> > >> > ================================================================= >> > against addomain from ipaclinet :- >> > >> > *ipaclinet ~] # KRB5_TRACE=/dev/stdout kinit rajat.g at AD.ADDOMAIN.COM >> > [4133] 1476067599.43421: Getting initial >> > credentials for rajat.g at AD.ADDOMAIN.COM [4133] >> > 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM >> > * >> > *[4133] 1476067599.49544: Resolving hostname * >> > *ad1.ad.addomain.com .* >> > *[4133] 1476067599.53762: Sending initial UDP request to dgram >> > 192.168.20.100* >> > >> > NOT WORKING >> > ================================================================= >> > >> > ================================================================= >> > against ipdomain from ipaclinet >> > >> > # KRB5_TRACE=/dev/stdout kinit admin at IPA.IPASERVER.LOCAL >> > [4914] 1476068067.763574: Getting initial credentials for >> > admin at IPA.IPASERVER.LOCAL >> > [4914] 1476068067.763889: Sending request (177 bytes) to >> IPA.IPASERVER.LOCAL >> > [4914] 1476068067.764033: Initiating TCP connection to stream >> > 10.246.104.14:88 >> > [4914] 1476068067.765089: Sending TCP request to stream >> 192.168.100.100:88 >> > [4914] 1476068067.767593: Received answer (356 bytes) from stream >> > 192.168.100.100:88 >> > [4914] 1476068067.767603: Terminating TCP connection to stream >> > 192.168.100.100:88 >> > [4914] 1476068067.767661: Response was from master KDC >> > [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional >> > pre-authentication required >> > [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133 >> > [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt >> > "k},(k&+qA)Mosf6z", params "" >> > [4914] 1476068067.767747: Received cookie: MIT >> > Password for admin at IPA.IPASERVER.LOCAL: >> > >> > this is working fine. >> > ================================================================= >> > >> > >> > it looks for password-based authentication requests, the IPA clients >> > connect directly to the AD servers using Kerberos. >> > >> > then there is port firewall opening required between ipaclinet and AD >> > Server as well. Is it required ? OR I am doing something wrong. >> >> Yes, IPA clients need to talk to AD servers as well. Please see >> https://access.redhat.com/documentation/en-US/Red_Hat_ >> Enterprise_Linux/7/html/Windows_Integration_Guide/ >> trust-requirements.html#trust-req-ports >> >> >> -- >> Petr^2 Spacek >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Mon, 10 Oct 2016 09:21:40 +0200 >> From: pvomacka >> To: freeipa-devel at redhat.com >> Subject: [Freeipa-devel] [freeipa PR#146][opened] WebUI: fix API >> Browser menu label >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> URL: https://github.com/freeipa/freeipa/pull/146 >> Author: pvomacka >> Title: #146: WebUI: fix API Browser menu label >> Action: opened >> >> PR body: >> """ >> The label of API Browser is now in translatable strings and it has >> uppercase B at the beginnig of second word. >> >> https://fedorahosted.org/freeipa/ticket/6384 >> """ >> >> To pull the PR as Git branch: >> git remote add ghfreeipa https://github.com/freeipa/freeipa >> git fetch ghfreeipa pull/146/head:pr146 >> git checkout pr146 >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: freeipa-pr-146.patch >> Type: text/x-diff >> Size: 2069 bytes >> Desc: not available >> URL: > attachments/20161010/5dc80c2e/attachment.bin> >> >> ------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> End of Freeipa-devel Digest, Vol 113, Issue 35 >> ********************************************** >> > > > >-- > >*Rajat Gupta * >-- >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 -- / Alexander Bokovoy From mbasti at redhat.com Mon Oct 10 08:28:51 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 10 Oct 2016 10:28:51 +0200 Subject: [Freeipa-devel] Broken IPA installation caused by new python-dns package Message-ID: <7ec8e751-af67-5850-d051-d1f7fe96025f@redhat.com> https://bodhi.fedoraproject.org/updates/FEDORA-2016-1857421df6 Please set karma accordingly Traceback: ... File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", line 426, in update_dns_records self.update_base_records(), File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", line 377, in update_base_records base_zone = self.get_base_records() File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", line 328, in get_base_records include_kerberos_realm=include_kerberos_realm File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", line 179, in _add_base_dns_records_for_server self.__add_kerberos_txt_rec(zone_obj) File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", line 165, in __add_kerberos_txt_rec rdataset.add(rd, ttl=86400) # FIXME: use TTL from config File "/usr/lib/python2.7/site-packages/dns/rdataset.py", line 129, in add super(Rdataset, self).add(rd) File "/usr/lib/python2.7/site-packages/dns/set.py", line 49, in add if item not in self.items: File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 217, in __eq__ return self._cmp(other) == 0 File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 203, in _cmp our = self.to_digestable(dns.name.root) File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 174, in to_digestable self.to_wire(f, None, origin) File "/usr/lib/python2.7/site-packages/dns/rdtypes/txtbase.py", line 75, in to_wire file.write(s) 2016-10-10T04:44:05Z DEBUG The ipa-replica-install command failed, exception: TypeError: 'unicode' does not have the buffer interface 2016-10-10T04:44:05Z ERROR 'unicode' does not have the buffer interface I'll investigate if IPA using it wrong or there is new error introduced in pyhton-dns From mbasti at redhat.com Mon Oct 10 08:30:55 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 10 Oct 2016 10:30:55 +0200 Subject: [Freeipa-devel] [PATCH 0497] Py3: fix unicode/str error in LDAP*ReverseMember In-Reply-To: References: <2c21c82e-6cc5-ebb4-46ff-be6b60785158@redhat.com> <0c68edcc-5c16-04a5-5bad-a92a69cbeec9@redhat.com> <8775911c-e412-7908-507d-7ea6b230a093@redhat.com> <8da13b03-de28-baef-f3e8-5e41924b5ae1@redhat.com> Message-ID: On 10.10.2016 07:57, Jan Cholasta wrote: > On 7.6.2016 10:35, Martin Basti wrote: >> >> >> On 07.06.2016 10:35, Jan Cholasta wrote: >>> On 7.6.2016 10:29, Martin Basti wrote: >>>> >>>> >>>> On 07.06.2016 09:08, Jan Cholasta wrote: >>>>> On 6.6.2016 14:33, Martin Basti wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/5923 >>>>>> >>>>>> Patch attached. >>>>> >>>>> Could we drop the error message parsing and do something sane >>>>> instead? >>>>> >>>> >>>> Not now, we can do it later and push this patch just as workaround >>> >>> What's the point of that? >>> >> Point is that it will work as before, and I don't have to time to fix it >> nicely now. > > Bump. Do you now have time to fix it nicely, or should we move the > ticket to 4.5 or later? > We should move it to milestone where we will fix/enable py3. From freeipa-github-notification at redhat.com Mon Oct 10 09:52:44 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 10 Oct 2016 11:52:44 +0200 Subject: [Freeipa-devel] [freeipa PR#142][synchronized] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Author: dkupka Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/142/head:pr142 git checkout pr142 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-142.patch Type: text/x-diff Size: 2956 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 10 10:19:05 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 10 Oct 2016 12:19:05 +0200 Subject: [Freeipa-devel] [freeipa PR#142][-ack] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Label: -ack From freeipa-github-notification at redhat.com Mon Oct 10 10:19:13 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 10 Oct 2016 12:19:13 +0200 Subject: [Freeipa-devel] [freeipa PR#142][comment] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling jcholast commented: """ NACK, see inline comments. """ See the full comment at https://github.com/freeipa/freeipa/pull/142#issuecomment-252580195 From freeipa-github-notification at redhat.com Mon Oct 10 11:19:40 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 10 Oct 2016 13:19:40 +0200 Subject: [Freeipa-devel] [freeipa PR#142][synchronized] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Author: dkupka Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/142/head:pr142 git checkout pr142 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-142.patch Type: text/x-diff Size: 2337 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 10 12:04:18 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 10 Oct 2016 14:04:18 +0200 Subject: [Freeipa-devel] [freeipa PR#147][opened] Tests: Unaccessible variable self.attrs in Tracker Message-ID: URL: https://github.com/freeipa/freeipa/pull/147 Author: gkaihorodova Title: #147: Tests: Unaccessible variable self.attrs in Tracker Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6125 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/147/head:pr147 git checkout pr147 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-147.patch Type: text/x-diff Size: 1040 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 10 12:04:51 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 10 Oct 2016 14:04:51 +0200 Subject: [Freeipa-devel] [freeipa PR#147][closed] Tests: Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/147 Author: gkaihorodova Title: #147: Tests: Unaccessible variable self.attrs in Tracker Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/147/head:pr147 git checkout pr147 From freeipa-github-notification at redhat.com Mon Oct 10 12:07:39 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 10 Oct 2016 14:07:39 +0200 Subject: [Freeipa-devel] [freeipa PR#148][opened] Unaccessible variable self.attrs in Tracker Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Author: gkaihorodova Title: #148: Unaccessible variable self.attrs in Tracker Action: opened PR body: """ In tracker, 'self.attrs' variable is created and filled in track_create method. Some objects are not created but still require access to this variable. Created 'self.attrs' variable in init https://fedorahosted.org/freeipa/ticket/6125 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/148/head:pr148 git checkout pr148 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-148.patch Type: text/x-diff Size: 971 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 10 12:10:35 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 10 Oct 2016 14:10:35 +0200 Subject: [Freeipa-devel] [freeipa PR#147][+rejected] Tests: Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/147 Title: #147: Tests: Unaccessible variable self.attrs in Tracker Label: +rejected From freeipa-github-notification at redhat.com Mon Oct 10 12:25:05 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Mon, 10 Oct 2016 14:25:05 +0200 Subject: [Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker apophys commented: """ NACK, comments inline. """ See the full comment at https://github.com/freeipa/freeipa/pull/148#issuecomment-252603864 From freeipa-github-notification at redhat.com Mon Oct 10 15:51:45 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 10 Oct 2016 17:51:45 +0200 Subject: [Freeipa-devel] [freeipa PR#145][comment] [WIP] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Title: #145: [WIP] Refactoring: LDAP Connection Management mbasti-rh commented: """ Please fix PEP8 ``` ./ipapython/ipaldap.py:766:49: E231 missing whitespace after ',' ./ipapython/ipaldap.py:822:9: E265 block comment should start with '# ' ./ipaserver/install/bindinstance.py:231:1: E302 expected 2 blank lines, found 1 ./ipaserver/install/bindinstance.py:231:80: E501 line too long (82 > 79 characters) ./ipaserver/install/krbinstance.py:170:80: E501 line too long (89 > 79 characters) ./ipaserver/install/ldapupdate.py:59:80: E501 line too long (85 > 79 characters) ./ipaserver/install/replication.py:218:80: E501 line too long (82 > 79 characters) ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/145#issuecomment-252662459 From freeipa-github-notification at redhat.com Mon Oct 10 16:09:51 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Mon, 10 Oct 2016 18:09:51 +0200 Subject: [Freeipa-devel] [freeipa PR#10][synchronized] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Author: LiptonB Title: #10: Client-side CSR autogeneration Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/10/head:pr10 git checkout pr10 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-10.patch Type: text/x-diff Size: 204494 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 10 16:47:17 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Mon, 10 Oct 2016 18:47:17 +0200 Subject: [Freeipa-devel] [freeipa PR#10][synchronized] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Author: LiptonB Title: #10: Client-side CSR autogeneration Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/10/head:pr10 git checkout pr10 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-10.patch Type: text/x-diff Size: 205306 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 10 16:48:14 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Mon, 10 Oct 2016 18:48:14 +0200 Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Title: #10: Client-side CSR autogeneration LiptonB commented: """ Thanks, I've updated the code based on your comments (force pushed to fix conflicts with master). And thanks for pointing out that email! I don't know how I missed it, but I will respond shortly. """ See the full comment at https://github.com/freeipa/freeipa/pull/10#issuecomment-252676408 From freeipa-github-notification at redhat.com Mon Oct 10 16:48:51 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 10 Oct 2016 18:48:51 +0200 Subject: [Freeipa-devel] [freeipa PR#145][comment] [WIP] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Title: #145: [WIP] Refactoring: LDAP Connection Management mbasti-rh commented: """ I did some inline comments, I'm not fully satisfied with implementation of the connection manager, I'll think about it tomorrow. """ See the full comment at https://github.com/freeipa/freeipa/pull/145#issuecomment-252676568 From freeipa-github-notification at redhat.com Mon Oct 10 17:26:14 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 10 Oct 2016 19:26:14 +0200 Subject: [Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker gkaihorodova commented: """ You're right, empty dict is more applicable here. I will close that one and open new with suggested fix. """ See the full comment at https://github.com/freeipa/freeipa/pull/148#issuecomment-252685347 From freeipa-github-notification at redhat.com Mon Oct 10 17:26:15 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 10 Oct 2016 19:26:15 +0200 Subject: [Freeipa-devel] [freeipa PR#148][closed] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Author: gkaihorodova Title: #148: Unaccessible variable self.attrs in Tracker Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/148/head:pr148 git checkout pr148 From freeipa-github-notification at redhat.com Mon Oct 10 17:35:44 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 10 Oct 2016 19:35:44 +0200 Subject: [Freeipa-devel] [freeipa PR#149][opened] Tests: Unaccessible variable self.attrs in Tracker Message-ID: URL: https://github.com/freeipa/freeipa/pull/149 Author: gkaihorodova Title: #149: Tests: Unaccessible variable self.attrs in Tracker Action: opened PR body: """ In tracker, 'self.attrs' variable is created and filled in track_create method. Some objects are not created but still require access to this variable. Created 'self.attrs' variable in init https://fedorahosted.org/freeipa/ticket/6125 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/149/head:pr149 git checkout pr149 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-149.patch Type: text/x-diff Size: 969 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 11 06:05:23 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 11 Oct 2016 08:05:23 +0200 Subject: [Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker stlaz commented: """ That's not how pull requests work. You should change the commit and force push it to the branch instead. """ See the full comment at https://github.com/freeipa/freeipa/pull/148#issuecomment-252822061 From freeipa-github-notification at redhat.com Tue Oct 11 06:13:24 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 11 Oct 2016 08:13:24 +0200 Subject: [Freeipa-devel] [freeipa PR#149][comment] Tests: Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/149 Title: #149: Tests: Unaccessible variable self.attrs in Tracker stlaz commented: """ Please fix this in the original PR, it will be a nice training for you ;) """ See the full comment at https://github.com/freeipa/freeipa/pull/149#issuecomment-252822977 From freeipa-github-notification at redhat.com Tue Oct 11 06:13:29 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 11 Oct 2016 08:13:29 +0200 Subject: [Freeipa-devel] [freeipa PR#149][+rejected] Tests: Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/149 Title: #149: Tests: Unaccessible variable self.attrs in Tracker Label: +rejected From freeipa-github-notification at redhat.com Tue Oct 11 06:13:33 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 11 Oct 2016 08:13:33 +0200 Subject: [Freeipa-devel] [freeipa PR#149][closed] Tests: Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/149 Author: gkaihorodova Title: #149: Tests: Unaccessible variable self.attrs in Tracker Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/149/head:pr149 git checkout pr149 From freeipa-github-notification at redhat.com Tue Oct 11 06:13:46 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 11 Oct 2016 08:13:46 +0200 Subject: [Freeipa-devel] [freeipa PR#148][reopened] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Author: gkaihorodova Title: #148: Unaccessible variable self.attrs in Tracker Action: reopened To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/148/head:pr148 git checkout pr148 From freeipa-github-notification at redhat.com Tue Oct 11 06:48:16 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 08:48:16 +0200 Subject: [Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker mbasti-rh commented: """ You can check last step in this howto http://www.freeipa.org/page/Pull_request_on_Github """ See the full comment at https://github.com/freeipa/freeipa/pull/148#issuecomment-252827639 From jcholast at redhat.com Tue Oct 11 07:00:15 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Oct 2016 09:00:15 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: References: Message-ID: <2a292802-240c-4257-72c3-f435140c3ece@redhat.com> Hi, On 7.10.2016 11:56, Petr Spacek wrote: > Dear FreeIPA developers and packagers, > > you can find first version of the Build system refactoring design document on: > http://www.freeipa.org/page/V4/Build_system_refactoring > > If you do not care about implementation details, please be so kind and quickly > scan through chapter > http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management > > I'm not an FreeIPA packager so I might miss some important thing which needs > to be configurable. 1) There should be a --with-python switch to select the version of Python to use in our command line tools and/or during build. The default would be "python", i.e. the default Python interpreter found in the path. 2) There is --with-pylint, --with-jslint, but no --with-po-validate. 3) I would prefer that if pylint (or jslint or python-polib) is not installed the build would fail instead of silently skipping the lint. Let it be a wilful decision of the packager whether to run the lint or not. 4) It is explicitly stated that I can turn off features using --without-feature. But how do I disable building server components? > > > Also, I would appreciate ideas how to handle build versioning: > http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning > > My main questions are: > * What is triggering IPA upgrade? > * Would it be sufficient to bump release in RPM? (I mean - theoretically. > Could the code be modified to detect this?) > > Here I'm trying to avoid unnecessary rebuilds caused by changes to > IPA_VENDOR_VERSION during each build. How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it is written only to ipapython/version.py: $ git grep -E '\bIPA_VENDOR_VERSION\b' Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" ipapython/version.py Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Tue Oct 11 07:02:55 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 11 Oct 2016 09:02:55 +0200 Subject: [Freeipa-devel] [freeipa PR#142][synchronized] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Author: dkupka Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/142/head:pr142 git checkout pr142 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-142.patch Type: text/x-diff Size: 2117 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 11 07:36:49 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Oct 2016 09:36:49 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: <2a292802-240c-4257-72c3-f435140c3ece@redhat.com> References: <2a292802-240c-4257-72c3-f435140c3ece@redhat.com> Message-ID: <6921c81e-ad8e-7dc6-56d3-e58a022a35e8@redhat.com> On 11.10.2016 09:00, Jan Cholasta wrote: > Hi, > > On 7.10.2016 11:56, Petr Spacek wrote: >> Dear FreeIPA developers and packagers, >> >> you can find first version of the Build system refactoring design document on: >> http://www.freeipa.org/page/V4/Build_system_refactoring >> >> If you do not care about implementation details, please be so kind and quickly >> scan through chapter >> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management >> >> I'm not an FreeIPA packager so I might miss some important thing which needs >> to be configurable. > > 1) There should be a --with-python switch to select the version of Python to > use in our command line tools and/or during build. The default would be > "python", i.e. the default Python interpreter found in the path. Okay. Can we pick some descriptive name? --with-default-python or --with--python? I think that it would be confusing if we had just --with-python --with-python2 --with-python3 Besides that, I would make --with-default-python to accept either "2" or "3" (and thus use path specified by --with-python? option). > 2) There is --with-pylint, --with-jslint, but no --with-po-validate. Let me clarify: I plan to use --with for things which have paths or other parameters, --enable for booleans. Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is calling script ../../ipatests/i18n.py which is in IPA source tree anyway. Do you want to have a --enable/--disable switch for these PO checks? > 3) I would prefer that if pylint (or jslint or python-polib) is not installed > the build would fail instead of silently skipping the lint. Let it be a wilful > decision of the packager whether to run the lint or not. Yes, that is my intent. It will not skip anything automatically. > 4) It is explicitly stated that I can turn off features using > --without-feature. But how do I disable building server components? I've added explicit mention of --disable-feature: http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring&type=revision&diff=14311&oldid=14310 >> Also, I would appreciate ideas how to handle build versioning: >> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning >> >> My main questions are: >> * What is triggering IPA upgrade? >> * Would it be sufficient to bump release in RPM? (I mean - theoretically. >> Could the code be modified to detect this?) >> >> Here I'm trying to avoid unnecessary rebuilds caused by changes to >> IPA_VENDOR_VERSION during each build. > > How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it > is written only to ipapython/version.py: > > $ git grep -E '\bIPA_VENDOR_VERSION\b' > Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) > Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" > ipapython/version.py My bad, I should write 'IPA*VERSION*'. Especially unconditional write to version.m4 is problematic but unconditional writes to other files slows things as well, just not that much. -- Petr^2 Spacek From abokovoy at redhat.com Tue Oct 11 07:45:02 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Oct 2016 10:45:02 +0300 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: <6921c81e-ad8e-7dc6-56d3-e58a022a35e8@redhat.com> References: <2a292802-240c-4257-72c3-f435140c3ece@redhat.com> <6921c81e-ad8e-7dc6-56d3-e58a022a35e8@redhat.com> Message-ID: <20161011074502.pmdnfakcwdjejoeu@redhat.com> On ti, 11 loka 2016, Petr Spacek wrote: >On 11.10.2016 09:00, Jan Cholasta wrote: >> Hi, >> >> On 7.10.2016 11:56, Petr Spacek wrote: >>> Dear FreeIPA developers and packagers, >>> >>> you can find first version of the Build system refactoring design document on: >>> http://www.freeipa.org/page/V4/Build_system_refactoring >>> >>> If you do not care about implementation details, please be so kind and quickly >>> scan through chapter >>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management >>> >>> I'm not an FreeIPA packager so I might miss some important thing which needs >>> to be configurable. >> >> 1) There should be a --with-python switch to select the version of Python to >> use in our command line tools and/or during build. The default would be >> "python", i.e. the default Python interpreter found in the path. > >Okay. Can we pick some descriptive name? > >--with-default-python >or >--with--python? > >I think that it would be confusing if we had just >--with-python >--with-python2 >--with-python3 --with-python=/path/to/python.binary is enough. We have the same in Samba where a secondary build against another python interpreter is regulated with '--extra-python' pointing to the Python's executable. > >Besides that, I would make --with-default-python to accept either "2" or "3" >(and thus use path specified by --with-python? option). I don't think we need --with-default-python=2|3 at all. Once you have a Python binary, you can discover the flavor in the code: $ python -c 'import sys; print sys.version_info.major' 2 -- / Alexander Bokovoy From jcholast at redhat.com Tue Oct 11 08:04:02 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Oct 2016 10:04:02 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: <6921c81e-ad8e-7dc6-56d3-e58a022a35e8@redhat.com> References: <2a292802-240c-4257-72c3-f435140c3ece@redhat.com> <6921c81e-ad8e-7dc6-56d3-e58a022a35e8@redhat.com> Message-ID: <3929e066-980b-bfff-ea49-7c17fde1d612@redhat.com> On 11.10.2016 09:36, Petr Spacek wrote: > On 11.10.2016 09:00, Jan Cholasta wrote: >> Hi, >> >> On 7.10.2016 11:56, Petr Spacek wrote: >>> Dear FreeIPA developers and packagers, >>> >>> you can find first version of the Build system refactoring design document on: >>> http://www.freeipa.org/page/V4/Build_system_refactoring >>> >>> If you do not care about implementation details, please be so kind and quickly >>> scan through chapter >>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management >>> >>> I'm not an FreeIPA packager so I might miss some important thing which needs >>> to be configurable. >> >> 1) There should be a --with-python switch to select the version of Python to >> use in our command line tools and/or during build. The default would be >> "python", i.e. the default Python interpreter found in the path. > > Okay. Can we pick some descriptive name? > > --with-default-python > or > --with--python? > > I think that it would be confusing if we had just > --with-python > --with-python2 > --with-python3 If the default values are "python", "python2", "python3" respectively, I don't think it would be confusing, since most of the time you only need to specify --with-python, if anything. Do we even need --with-python2 and --with-python3? I think they would only make sense if you had multiple Python minor versions installed and wanted to make packages for all of them. > > > Besides that, I would make --with-default-python to accept either "2" or "3" > (and thus use path specified by --with-python? option). > > > >> 2) There is --with-pylint, --with-jslint, but no --with-po-validate. > > Let me clarify: I plan to use --with for things which have paths or other > parameters, --enable for booleans. I see, that was not clear to me, I confused the two. > > Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is > calling script ../../ipatests/i18n.py which is in IPA source tree anyway. > > Do you want to have a --enable/--disable switch for these PO checks? Not really. > > >> 3) I would prefer that if pylint (or jslint or python-polib) is not installed >> the build would fail instead of silently skipping the lint. Let it be a wilful >> decision of the packager whether to run the lint or not. > > Yes, that is my intent. It will not skip anything automatically. Right. > > > >> 4) It is explicitly stated that I can turn off features using >> --without-feature. But how do I disable building server components? > > I've added explicit mention of --disable-feature: > http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring&type=revision&diff=14311&oldid=14310 Thanks. > > >>> Also, I would appreciate ideas how to handle build versioning: >>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning >>> >>> My main questions are: >>> * What is triggering IPA upgrade? >>> * Would it be sufficient to bump release in RPM? (I mean - theoretically. >>> Could the code be modified to detect this?) >>> >>> Here I'm trying to avoid unnecessary rebuilds caused by changes to >>> IPA_VENDOR_VERSION during each build. >> >> How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it >> is written only to ipapython/version.py: >> >> $ git grep -E '\bIPA_VENDOR_VERSION\b' >> Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) >> Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" >> ipapython/version.py > > My bad, I should write 'IPA*VERSION*'. > > Especially unconditional write to version.m4 is problematic but unconditional > writes to other files slows things as well, just not that much. Could this be worked around by writing into a temporary file, comparing it with the real file and mv'ing the temporary file over the real file only if the differ? -- Jan Cholasta From freeipa-github-notification at redhat.com Tue Oct 11 08:03:24 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 11 Oct 2016 10:03:24 +0200 Subject: [Freeipa-devel] [freeipa PR#117][synchronized] Make ipa-replica-install run in interactive mode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/117 Author: stlaz Title: #117: Make ipa-replica-install run in interactive mode Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/117/head:pr117 git checkout pr117 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-117.patch Type: text/x-diff Size: 8311 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 11 08:10:06 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Oct 2016 10:10:06 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: <3929e066-980b-bfff-ea49-7c17fde1d612@redhat.com> References: <2a292802-240c-4257-72c3-f435140c3ece@redhat.com> <6921c81e-ad8e-7dc6-56d3-e58a022a35e8@redhat.com> <3929e066-980b-bfff-ea49-7c17fde1d612@redhat.com> Message-ID: <4d88ea44-ec1a-3a2b-34aa-a4394c21b09a@redhat.com> On 11.10.2016 10:04, Jan Cholasta wrote: > On 11.10.2016 09:36, Petr Spacek wrote: >> On 11.10.2016 09:00, Jan Cholasta wrote: >>> Hi, >>> >>> On 7.10.2016 11:56, Petr Spacek wrote: >>>> Dear FreeIPA developers and packagers, >>>> >>>> you can find first version of the Build system refactoring design document >>>> on: >>>> http://www.freeipa.org/page/V4/Build_system_refactoring >>>> >>>> If you do not care about implementation details, please be so kind and >>>> quickly >>>> scan through chapter >>>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management >>>> >>>> I'm not an FreeIPA packager so I might miss some important thing which needs >>>> to be configurable. >>> >>> 1) There should be a --with-python switch to select the version of Python to >>> use in our command line tools and/or during build. The default would be >>> "python", i.e. the default Python interpreter found in the path. >> >> Okay. Can we pick some descriptive name? >> >> --with-default-python >> or >> --with--python? >> >> I think that it would be confusing if we had just >> --with-python >> --with-python2 >> --with-python3 > > If the default values are "python", "python2", "python3" respectively, I don't These need to be full paths. I hope that some autoconf detection logic will help with autodetection. > think it would be confusing, since most of the time you only need to specify > --with-python, if anything. Okay, let me be explicit: It *is* confusing for me. Would you be okay with --with-default-python ? > Do we even need --with-python2 and --with-python3? I think they would only > make sense if you had multiple Python minor versions installed and wanted to > make packages for all of them. AFAIK autoconf-style is to provide these for options where path to external binary is needed. I would like to keep these conventions to avoid NIH syndrome in the new build system. Also, --without-python2/--without-python3 is needed anyway to disable this part of build on systems without Python X version. I want to keep this explicit (as with any other optional part of the build). >> Besides that, I would make --with-default-python to accept either "2" or "3" >> (and thus use path specified by --with-python? option). >> >> >> >>> 2) There is --with-pylint, --with-jslint, but no --with-po-validate. >> >> Let me clarify: I plan to use --with for things which have paths or other >> parameters, --enable for booleans. > > I see, that was not clear to me, I confused the two. > >> >> Where po-validate belongs? AFAIK target validate-po in install/po/Makefile is >> calling script ../../ipatests/i18n.py which is in IPA source tree anyway. >> >> Do you want to have a --enable/--disable switch for these PO checks? > > Not really. > >> >> >>> 3) I would prefer that if pylint (or jslint or python-polib) is not installed >>> the build would fail instead of silently skipping the lint. Let it be a wilful >>> decision of the packager whether to run the lint or not. >> >> Yes, that is my intent. It will not skip anything automatically. > > Right. > >> >> >> >>> 4) It is explicitly stated that I can turn off features using >>> --without-feature. But how do I disable building server components? >> >> I've added explicit mention of --disable-feature: >> http://www.freeipa.org/index.php?title=V4%2FBuild_system_refactoring&type=revision&diff=14311&oldid=14310 >> > > Thanks. > >> >> >>>> Also, I would appreciate ideas how to handle build versioning: >>>> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning >>>> >>>> My main questions are: >>>> * What is triggering IPA upgrade? >>>> * Would it be sufficient to bump release in RPM? (I mean - theoretically. >>>> Could the code be modified to detect this?) >>>> >>>> Here I'm trying to avoid unnecessary rebuilds caused by changes to >>>> IPA_VENDOR_VERSION during each build. >>> >>> How exactly is IPA_VENDOR_VERSION causing unnecessary rebuilds? I can see it >>> is written only to ipapython/version.py: >>> >>> $ git grep -E '\bIPA_VENDOR_VERSION\b' >>> Makefile:IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX) >>> Makefile: sed -i -e "s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION):" >>> ipapython/version.py >> >> My bad, I should write 'IPA*VERSION*'. >> >> Especially unconditional write to version.m4 is problematic but unconditional >> writes to other files slows things as well, just not that much. > > Could this be worked around by writing into a temporary file, comparing it > with the real file and mv'ing the temporary file over the real file only if > the differ? Right now IPA_VERSION_IS_GIT_SNAPSHOT is always appends timestamp to the string so the move would happen always ... This is why I'm trying to understand where the versions are used and if they really have to change at every (devel) build. -- Petr^2 Spacek From abokovoy at redhat.com Tue Oct 11 08:21:40 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Oct 2016 11:21:40 +0300 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: <4d88ea44-ec1a-3a2b-34aa-a4394c21b09a@redhat.com> References: <2a292802-240c-4257-72c3-f435140c3ece@redhat.com> <6921c81e-ad8e-7dc6-56d3-e58a022a35e8@redhat.com> <3929e066-980b-bfff-ea49-7c17fde1d612@redhat.com> <4d88ea44-ec1a-3a2b-34aa-a4394c21b09a@redhat.com> Message-ID: <20161011082140.5g6a2xpcwawkoojh@redhat.com> On ti, 11 loka 2016, Petr Spacek wrote: >On 11.10.2016 10:04, Jan Cholasta wrote: >> On 11.10.2016 09:36, Petr Spacek wrote: >>> On 11.10.2016 09:00, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 7.10.2016 11:56, Petr Spacek wrote: >>>>> Dear FreeIPA developers and packagers, >>>>> >>>>> you can find first version of the Build system refactoring design document >>>>> on: >>>>> http://www.freeipa.org/page/V4/Build_system_refactoring >>>>> >>>>> If you do not care about implementation details, please be so kind and >>>>> quickly >>>>> scan through chapter >>>>> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management >>>>> >>>>> I'm not an FreeIPA packager so I might miss some important thing which needs >>>>> to be configurable. >>>> >>>> 1) There should be a --with-python switch to select the version of Python to >>>> use in our command line tools and/or during build. The default would be >>>> "python", i.e. the default Python interpreter found in the path. >>> >>> Okay. Can we pick some descriptive name? >>> >>> --with-default-python >>> or >>> --with--python? >>> >>> I think that it would be confusing if we had just >>> --with-python >>> --with-python2 >>> --with-python3 >> >> If the default values are "python", "python2", "python3" respectively, I don't > >These need to be full paths. I hope that some autoconf detection logic will >help with autodetection. > > >> think it would be confusing, since most of the time you only need to specify >> --with-python, if anything. > >Okay, let me be explicit: It *is* confusing for me. Would you be okay with >--with-default-python ? > > >> Do we even need --with-python2 and --with-python3? I think they would only >> make sense if you had multiple Python minor versions installed and wanted to >> make packages for all of them. > >AFAIK autoconf-style is to provide these for options where path to external >binary is needed. I would like to keep these conventions to avoid NIH syndrome >in the new build system. > >Also, --without-python2/--without-python3 is needed anyway to disable this >part of build on systems without Python X version. I want to keep this >explicit (as with any other optional part of the build). Why so complex? Allow --with-python to be specified multiple times and enable all python versions that resolve through --with-python specified executables: --with-python=/bin/python2 --with-python=/bin/python3 would enable both Python 2 and Python 3. Specifying none will enable default version found on the system. Specifying one will enable explicitly only one. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Tue Oct 11 09:35:21 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Tue, 11 Oct 2016 11:35:21 +0200 Subject: [Freeipa-devel] [freeipa PR#140][synchronized] Tests: Remove invalid certplugin tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Author: mirielka Title: #140: Tests: Remove invalid certplugin tests Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/140/head:pr140 git checkout pr140 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-140.patch Type: text/x-diff Size: 7696 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 11 09:49:54 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 11 Oct 2016 11:49:54 +0200 Subject: [Freeipa-devel] [freeipa PR#141][+ack] Tests: Fix failing test_ipalib/test_parameters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/141 Title: #141: Tests: Fix failing test_ipalib/test_parameters Label: +ack From freeipa-github-notification at redhat.com Tue Oct 11 09:56:48 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Tue, 11 Oct 2016 11:56:48 +0200 Subject: [Freeipa-devel] [freeipa PR#148][synchronized] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Author: gkaihorodova Title: #148: Unaccessible variable self.attrs in Tracker Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/148/head:pr148 git checkout pr148 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-148.patch Type: text/x-diff Size: 969 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 11 10:11:57 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 11 Oct 2016 12:11:57 +0200 Subject: [Freeipa-devel] [freeipa PR#150][opened] Fix compatibility with python-dns 1.15.0 Message-ID: URL: https://github.com/freeipa/freeipa/pull/150 Author: pspacek Title: #150: Fix compatibility with python-dns 1.15.0 Action: opened PR body: """ From https://github.com/rthalley/dnspython/issues/214: The FreeIPA code is directly invoking the TXT RR constructor instread of calling dns.rdata.from_text(), which is how dnspython would like you to do this kind of thing. https://fedorahosted.org/freeipa/ticket/6390 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/150/head:pr150 git checkout pr150 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-150.patch Type: text/x-diff Size: 2122 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 11 10:31:47 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 11 Oct 2016 12:31:47 +0200 Subject: [Freeipa-devel] [freeipa PR#134][synchronized] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-134.patch Type: text/x-diff Size: 38679 bytes Desc: not available URL: From sbose at redhat.com Tue Oct 11 11:37:09 2016 From: sbose at redhat.com (Sumit Bose) Date: Tue, 11 Oct 2016 13:37:09 +0200 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > Hi, > > I've started to write a SSSD design page about enhancing the current > mapping of certificates to users and how to select/match a suitable > certificate if multiple certificates are on a Smartcard. > > My currently thoughts and idea and be found at > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates > and for your convenience below as well. > > Comments and suggestions are welcome. Please let me know about concerns, > alternatives and missing use-cases/user-stories. > > bye, > Sumit > Hi, Rob, Fraser, Alexander, thank you for your comments. I think both the issuer specific matching and the OID in the SUBJECT matching are good ideas. I updated the design page accordingly. The changes can be shown with https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff&version=9&old_version=6 The updated version can be found below as well. Of course more comments and suggestions are still very welcome. bye, Sumit = Matching and Mapping Certificates = Related ticket(s): * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping === Problem statement === ==== Mapping ==== Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. ==== Matching ==== Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. === Use cases === ==== Mapping ==== In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: * Certificates/Smartcards are issued externally * LDAP schema extension is not possible or not allowed ==== Matching ==== A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. === Overview of the solution === To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. === Implementation details === ==== Matching ==== The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are * regular-expression * regular-expression * regular-expression * extended-key-usage-list * key-usage-list and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate. '''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?''' While and are (imo) already quite flexible I can see some potential extensions for the other components. and in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless). The component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with ===== Issuer specific matching ===== Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. How the issuer string is linked to the matching rules depends on the storage (LDAP or sssd.conf, see below for details). ==== Mapping ==== Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case. If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|". A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g. * * where O.I.D. is either the OID or name of a RDN type or the OID or some well-known-name of the SAN component respectively. Since the SUBJECT might contain multiple RDNs of the same type always the "most specific" is selected because in general this will be the most suited one to map the certificate to a specific user. "most specific" means the last in X.500 order and the first in LDAP order (see discussion below for details). If the O.I.D. is missing the full SUBJECT is used for mapping. If 'DN' is used as ldapAttributeName SUBJECT is expected to be the DN of the user. If the O.I.D. is missing in the SAN case the same default as with matching (id-pkinit-san and szOID_NT_PRINCIPAL_NAME OID) is used. If both SAN values can be found in the certificate and are different the LDAP search filter will combine both with the or-operator. Currently I see no usage for , and in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add based mappings. ===== Future consideration ===== Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of might be tricky as discussed below. Nevertheless it might be possible to add to following in a future release if more complex operations on the values are needed: * /regexp/replacement/ * /regexp/replacement/ where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like {{{ /^CN=\([^,]*\).*$/\1/ }}} would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expressions.html#g-regex-replace g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. Maybe even search-and-replace are not sufficient for all cases and something like embedded lua scripts are needed. But since certificate mapping is about access control and authorization it should be always considered if adding a new attribute to the users LDAP entry which makes mapping easy and straight-forward wouldn't be the better solution. ===== Some notes about DNs ===== The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the * X.500 order: DC=com,DC=example,CN=users,CN=Certuser or in the * LDAP order: CN=Certuser,CN=Users,DC=example,DC=com As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111). This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP) Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user at example.com', certtool as 'EMAIL=user at example.com' and certutil as 'E=user at example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]: * CN commonName (2.5.4.3) * L localityName (2.5.4.7) * ST stateOrProvinceName (2.5.4.8) * O organizationName (2.5.4.10) * OU organizationalUnitName (2.5.4.11) * C countryName (2.5.4.6) * STREET streetAddress (2.5.4.9) * DC domainComponent (0.9.2342.19200300.100.1.25) * UID userId (0.9.2342.19200300.100.1.1) ==== About restricting or enforcing the mapping an matching any further ==== The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing. Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together. In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in. But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from. So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in. ==== Storing matching and mapping configuration ==== On the IPA server a new objectclass can be created to store an matching-mapping rule pair together with a specific issuer. All attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping. If only a specific issuer is given certificates from this issuer must be stored in the LDAP entry of the user to make authentication possible. Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule. Issuer specific rules will have three pairs of curly braces where the first pair must contain an issuer string. ===== Future considerations ===== If it turns out that this option is used quite often and it gets complicated to manage a larger set of rules with it and storing the rules in LDAP/IPA/AD is not an option we might add support to read the rules from a separate file (certificate_rules = FILE:///etc/sssd/cert_rules) with a more suitable format, e.g. ini where a list can be defined by given the same option multiple times. ===== Examples ===== * '''certificate_rules = {msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with * '''certificate_rules = {1.3.6.1.4.1.311.20.2.2}''': see above * '''certificate_rules = {*my-company**@my-company.com$}{}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user. === Configuration changes === Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for. === How To Test === This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus. === How To Debug === Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for. === Authors === Give credit to authors of the design in this section. From pvoborni at redhat.com Tue Oct 11 13:11:13 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 11 Oct 2016 15:11:13 +0200 Subject: [Freeipa-devel] Feature branches for sub-team efforts Message-ID: Hi List, we discussed locally a proposal about creating a feature branch for each sub-team effort in our main git. Currently it would be for the 4 ongoing refactoring efforts + Simo's work Why? It will allow each developer to create a pull request against the feature branch and thus it will enable iterative development by multiple devs without affecting other sub-teams. When the feature(refactoring) is finished, the branch would be rebased on master and merged there. Note: rebases can be done as needed - e.g. when other subteam finishes its work. Concerns: 1. Upstream git repo would be full of such branches. - This can be mitigated by deleting the feature branches when their are released or merged(up to discussion) 2. Too big traffic on a list. - IMO we actually want it - progress will be visible to others Naming: I propose: refactoring-XXX feature-XXX Thoughts? Anyone against? -- Petr Vobornik From jpazdziora at redhat.com Tue Oct 11 13:12:24 2016 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 11 Oct 2016 15:12:24 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: References: Message-ID: <20161011131224.GB8635@redhat.com> On Fri, Oct 07, 2016 at 11:56:26AM +0200, Petr Spacek wrote: > Dear FreeIPA developers and packagers, > > you can find first version of the Build system refactoring design document on: > http://www.freeipa.org/page/V4/Build_system_refactoring > > If you do not care about implementation details, please be so kind and quickly > scan through chapter > http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management I'm not sure who exactly is the tester -- is it QE team, developer testing someone else's patch, or someone else who just wants to try a particular build? I'd often like to test a build but I'd like to use yum repo for that, not building locally with "make rpms" because I'd likely need additional dependencies installed for that and I'll likely need some runtime dependencies as well. IMO, QE teams shouldn't be building rpms themselves either, they should consume nightly/snapshot builds produced by engineering, either automatically or manually. Could we add some high level goals for the refactoring effort, and add a goal of having repoclosure'd yum repo for master and interesting branches / pull requests? -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat From tkrizek at redhat.com Tue Oct 11 13:36:05 2016 From: tkrizek at redhat.com (Tomas Krizek) Date: Tue, 11 Oct 2016 15:36:05 +0200 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: References: Message-ID: On 10/11/2016 03:11 PM, Petr Vobornik wrote: > Hi List, > > we discussed locally a proposal about creating a feature branch for each > sub-team effort in our main git. Currently it would be for the 4 ongoing > refactoring efforts + Simo's work > > Why? > It will allow each developer to create a pull request against the > feature branch and thus it will enable iterative development by multiple > devs without affecting other sub-teams. When the feature(refactoring) is > finished, the branch would be rebased on master and merged there. Note: > rebases can be done as needed - e.g. when other subteam finishes its work. > > Concerns: > 1. Upstream git repo would be full of such branches. > - This can be mitigated by deleting the feature branches when their are > released or merged(up to discussion) > > 2. Too big traffic on a list. > - IMO we actually want it - progress will be visible to others > > > Naming: > I propose: > refactoring-XXX > feature-XXX > > Thoughts? Anyone against? Hi, I think feature branches are a good idea. Once they're merged, I would delete them. I'm for the refactoring-XXX naming convention. -- Tomas Krizek From jcholast at redhat.com Tue Oct 11 13:42:56 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 11 Oct 2016 15:42:56 +0200 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: References: Message-ID: <3eaa0008-3b3e-0859-b5f6-45a407ee8506@redhat.com> Hi, On 11.10.2016 15:11, Petr Vobornik wrote: > Hi List, > > we discussed locally a proposal about creating a feature branch for each > sub-team effort in our main git. Currently it would be for the 4 ongoing > refactoring efforts + Simo's work > > Why? > It will allow each developer to create a pull request against the > feature branch and thus it will enable iterative development by multiple > devs without affecting other sub-teams. When the feature(refactoring) is > finished, the branch would be rebased on master and merged there. Note: > rebases can be done as needed - e.g. when other subteam finishes its work. +1 > > Concerns: > 1. Upstream git repo would be full of such branches. > - This can be mitigated by deleting the feature branches when their are > released or merged(up to discussion) Personally I would just keep them there, but I don't really care. > > 2. Too big traffic on a list. > - IMO we actually want it - progress will be visible to others +1 > > > Naming: > I propose: > refactoring-XXX > feature-XXX I would be perfectly fine with just XXX, but again I don't really care. > > Thoughts? Anyone against? > Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Tue Oct 11 13:44:38 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 15:44:38 +0200 Subject: [Freeipa-devel] [freeipa PR#150][+ack] Fix compatibility with python-dns 1.15.0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/150 Title: #150: Fix compatibility with python-dns 1.15.0 Label: +ack From freeipa-github-notification at redhat.com Tue Oct 11 13:46:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 15:46:01 +0200 Subject: [Freeipa-devel] [freeipa PR#150][+pushed] Fix compatibility with python-dns 1.15.0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/150 Title: #150: Fix compatibility with python-dns 1.15.0 Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 11 13:46:05 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 15:46:05 +0200 Subject: [Freeipa-devel] [freeipa PR#150][closed] Fix compatibility with python-dns 1.15.0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/150 Author: pspacek Title: #150: Fix compatibility with python-dns 1.15.0 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/150/head:pr150 git checkout pr150 From freeipa-github-notification at redhat.com Tue Oct 11 13:46:07 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 15:46:07 +0200 Subject: [Freeipa-devel] [freeipa PR#150][comment] Fix compatibility with python-dns 1.15.0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/150 Title: #150: Fix compatibility with python-dns 1.15.0 mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/8e02652e7c889ce7d32b592b5235917a0f519503 ipa-4-4: https://fedorahosted.org/freeipa/changeset/82bc75fe63acef482e9c59969ba352759ee48fa3 """ See the full comment at https://github.com/freeipa/freeipa/pull/150#issuecomment-252921049 From pvoborni at redhat.com Tue Oct 11 13:47:40 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 11 Oct 2016 15:47:40 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: References: Message-ID: <0ac07073-83ea-2753-dca3-6f6cee2e9599@redhat.com> On 10/07/2016 11:56 AM, Petr Spacek wrote: > Dear FreeIPA developers and packagers, > > you can find first version of the Build system refactoring design document on: > http://www.freeipa.org/page/V4/Build_system_refactoring > > If you do not care about implementation details, please be so kind and quickly > scan through chapter > http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management > > I'm not an FreeIPA packager so I might miss some important thing which needs > to be configurable. > > > Also, I would appreciate ideas how to handle build versioning: > http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning > > My main questions are: > * What is triggering IPA upgrade? > * Would it be sufficient to bump release in RPM? (I mean - theoretically. > Could the code be modified to detect this?) > > Here I'm trying to avoid unnecessary rebuilds caused by changes to > IPA_VENDOR_VERSION during each build. > > > Timo, what can I do to help you with packaging for Ubuntu/Debian? > > Dream big, even wild ideas are welcome! > I'd like to add one use case which is a prerequisite for "packager": release engineer. Currently, IPA is released by running $ make IPA_VERSION_IS_GIT_SNAPSHOT=no rpms Then tarball is copied from dist/sources to freeipa.org http://www.freeipa.org/page/Release#Building_the_sources With current code, it may be done only with: $ make tarball But it probably wasn't tested much so I'd not rely on it. What I'd like to see: Release engineer: $ make dist $ # copy tarball Packager: $ ./configure [--options] $ make install I think that this workflow is implied by "Automake: Standard Targets" but IMHO it should be specified in the design explicitly because it is a change in our process. -- Petr Vobornik From freeipa-github-notification at redhat.com Tue Oct 11 13:49:24 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 11 Oct 2016 15:49:24 +0200 Subject: [Freeipa-devel] [freeipa PR#151][opened] Make httpd publish its CA certificate on DL1 Message-ID: URL: https://github.com/freeipa/freeipa/pull/151 Author: stlaz Title: #151: Make httpd publish its CA certificate on DL1 Action: opened PR body: """ httpd did not publish its certificate on DL1 which could cause issues during client installation in a rare corner case where there would be no way of getting the certificate but from a HTTP instance. https://fedorahosted.org/freeipa/ticket/6393 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/151/head:pr151 git checkout pr151 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-151.patch Type: text/x-diff Size: 1405 bytes Desc: not available URL: From abokovoy at redhat.com Tue Oct 11 13:50:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Oct 2016 16:50:50 +0300 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: References: Message-ID: <20161011135050.crkf25psdffdnws4@redhat.com> On ti, 11 loka 2016, Petr Vobornik wrote: >Hi List, > >we discussed locally a proposal about creating a feature branch for each >sub-team effort in our main git. Currently it would be for the 4 ongoing >refactoring efforts + Simo's work > >Why? >It will allow each developer to create a pull request against the >feature branch and thus it will enable iterative development by multiple >devs without affecting other sub-teams. When the feature(refactoring) is >finished, the branch would be rebased on master and merged there. Note: >rebases can be done as needed - e.g. when other subteam finishes its work. > >Concerns: >1. Upstream git repo would be full of such branches. >- This can be mitigated by deleting the feature branches when their are >released or merged(up to discussion) Don't put them in the upstream git repo. Let people decide where they want to have them -- all Fedora contributors have access to fedorapeople.org git hosting and there is github one button click ('Clone') away from the github mirror. It is not a problem to keep a separate git branch published this way. May be I misunderstand you -- if you just want people to propose merge requests on github with pre-defined names, then that's just fine. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Tue Oct 11 13:51:29 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 15:51:29 +0200 Subject: [Freeipa-devel] [freeipa PR#141][comment] Tests: Fix failing test_ipalib/test_parameters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/141 Title: #141: Tests: Fix failing test_ipalib/test_parameters mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/c3e3130a35f05348405701731ec2d5b85a772997 """ See the full comment at https://github.com/freeipa/freeipa/pull/141#issuecomment-252922588 From freeipa-github-notification at redhat.com Tue Oct 11 13:51:30 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 15:51:30 +0200 Subject: [Freeipa-devel] [freeipa PR#141][closed] Tests: Fix failing test_ipalib/test_parameters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/141 Author: mirielka Title: #141: Tests: Fix failing test_ipalib/test_parameters Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/141/head:pr141 git checkout pr141 From freeipa-github-notification at redhat.com Tue Oct 11 13:51:32 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 15:51:32 +0200 Subject: [Freeipa-devel] [freeipa PR#141][+pushed] Tests: Fix failing test_ipalib/test_parameters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/141 Title: #141: Tests: Fix failing test_ipalib/test_parameters Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 11 14:01:08 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:01:08 +0200 Subject: [Freeipa-devel] [freeipa PR#138][+pushed] Fix ipa-cacert-manage man page In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Title: #138: Fix ipa-cacert-manage man page Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 11 14:01:09 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:01:09 +0200 Subject: [Freeipa-devel] [freeipa PR#138][comment] Fix ipa-cacert-manage man page In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Title: #138: Fix ipa-cacert-manage man page mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/eb75578cbb2447fc2fafb8a79d8500b27e3edff0 """ See the full comment at https://github.com/freeipa/freeipa/pull/138#issuecomment-252925331 From freeipa-github-notification at redhat.com Tue Oct 11 14:01:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:01:11 +0200 Subject: [Freeipa-devel] [freeipa PR#138][closed] Fix ipa-cacert-manage man page In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/138 Author: flo-renaud Title: #138: Fix ipa-cacert-manage man page Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/138/head:pr138 git checkout pr138 From pspacek at redhat.com Tue Oct 11 14:04:20 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Oct 2016 16:04:20 +0200 Subject: [Freeipa-devel] Build system refactoring - design document In-Reply-To: <0ac07073-83ea-2753-dca3-6f6cee2e9599@redhat.com> References: <0ac07073-83ea-2753-dca3-6f6cee2e9599@redhat.com> Message-ID: <27609d44-7c1a-d1fe-2f45-aaa83b2d131f@redhat.com> On 11.10.2016 15:47, Petr Vobornik wrote: > On 10/07/2016 11:56 AM, Petr Spacek wrote: >> Dear FreeIPA developers and packagers, >> >> you can find first version of the Build system refactoring design document on: >> http://www.freeipa.org/page/V4/Build_system_refactoring >> >> If you do not care about implementation details, please be so kind and quickly >> scan through chapter >> http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management >> >> I'm not an FreeIPA packager so I might miss some important thing which needs >> to be configurable. >> >> >> Also, I would appreciate ideas how to handle build versioning: >> http://www.freeipa.org/page/V4/Build_system_refactoring#Versioning >> >> My main questions are: >> * What is triggering IPA upgrade? >> * Would it be sufficient to bump release in RPM? (I mean - theoretically. >> Could the code be modified to detect this?) >> >> Here I'm trying to avoid unnecessary rebuilds caused by changes to >> IPA_VENDOR_VERSION during each build. >> >> >> Timo, what can I do to help you with packaging for Ubuntu/Debian? >> >> Dream big, even wild ideas are welcome! >> > > I'd like to add one use case which is a prerequisite for "packager": > release engineer. > > Currently, IPA is released by running > $ make IPA_VERSION_IS_GIT_SNAPSHOT=no rpms > > Then tarball is copied from dist/sources to freeipa.org > > http://www.freeipa.org/page/Release#Building_the_sources > > With current code, it may be done only with: > $ make tarball > > But it probably wasn't tested much so I'd not rely on it. > > What I'd like to see: > > Release engineer: > $ make dist > $ # copy tarball > > Packager: > $ ./configure [--options] > $ make install > > I think that this workflow is implied by "Automake: Standard Targets" > but IMHO it should be specified in the design explicitly because it is a > change in our process. Fine with me. Please formulate your requirements to user stories and add them to: http://www.freeipa.org/page/V4/Build_system_refactoring#User_stories I will look at them after that. -- Petr^2 Spacek From freeipa-github-notification at redhat.com Tue Oct 11 14:16:57 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Tue, 11 Oct 2016 16:16:57 +0200 Subject: [Freeipa-devel] [freeipa PR#144][comment] Pylint: remove unused values - the last part In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/144 Title: #144: Pylint: remove unused values - the last part pvomacka commented: """ ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/144#issuecomment-252929696 From freeipa-github-notification at redhat.com Tue Oct 11 14:17:09 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Tue, 11 Oct 2016 16:17:09 +0200 Subject: [Freeipa-devel] [freeipa PR#144][+ack] Pylint: remove unused values - the last part In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/144 Title: #144: Pylint: remove unused values - the last part Label: +ack From pvoborni at redhat.com Tue Oct 11 14:19:22 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 11 Oct 2016 16:19:22 +0200 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: <20161011135050.crkf25psdffdnws4@redhat.com> References: <20161011135050.crkf25psdffdnws4@redhat.com> Message-ID: <4103ebfc-8319-0226-9567-e43bb7f36b02@redhat.com> On 10/11/2016 03:50 PM, Alexander Bokovoy wrote: > On ti, 11 loka 2016, Petr Vobornik wrote: >> Hi List, >> >> we discussed locally a proposal about creating a feature branch for each >> sub-team effort in our main git. Currently it would be for the 4 ongoing >> refactoring efforts + Simo's work >> >> Why? >> It will allow each developer to create a pull request against the >> feature branch and thus it will enable iterative development by multiple >> devs without affecting other sub-teams. When the feature(refactoring) is >> finished, the branch would be rebased on master and merged there. Note: >> rebases can be done as needed - e.g. when other subteam finishes its >> work. >> >> Concerns: >> 1. Upstream git repo would be full of such branches. >> - This can be mitigated by deleting the feature branches when their are >> released or merged(up to discussion) > Don't put them in the upstream git repo. Let people decide where they > want to have them -- all Fedora contributors have access to > fedorapeople.org git hosting and there is github one button click > ('Clone') away from the github mirror. > > It is not a problem to keep a separate git branch published this way. > It is not a matter of making the code public. That can be done easily as you write. Other alternative is own branch in GitHub fork. > May be I misunderstand you -- if you just want people to propose merge > requests on github with pre-defined names, then that's just fine. > Basically it's all about review. Example use case: More than 1 devs are working on a same big effort. This effort will probably consists of 10s of commits. The big effort is divided into smaller ones which can be implemented and reviewed separately. In our previous mode, the sub task would be merged to master it is reviewed and ACKed. But now we cannot do that. We want to merge the whole big task at once when it is finishes and tested. One dev could probably have a branch on personal fork of FreeIPA on GitHub which would work as the feature branch. Other team members would create pull requests against it. In such case we would loose mail notifications and would have to extend our tooling because ipatool can use only one upstream on push. Pre-defined names for PRs is a good idea - we could easily see what effort the pull request is related to. -- Petr Vobornik From abokovoy at redhat.com Tue Oct 11 14:27:18 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Oct 2016 17:27:18 +0300 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: <4103ebfc-8319-0226-9567-e43bb7f36b02@redhat.com> References: <20161011135050.crkf25psdffdnws4@redhat.com> <4103ebfc-8319-0226-9567-e43bb7f36b02@redhat.com> Message-ID: <20161011142718.7hockhxitytbwgkh@redhat.com> On ti, 11 loka 2016, Petr Vobornik wrote: >On 10/11/2016 03:50 PM, Alexander Bokovoy wrote: >> On ti, 11 loka 2016, Petr Vobornik wrote: >>> Hi List, >>> >>> we discussed locally a proposal about creating a feature branch for each >>> sub-team effort in our main git. Currently it would be for the 4 ongoing >>> refactoring efforts + Simo's work >>> >>> Why? >>> It will allow each developer to create a pull request against the >>> feature branch and thus it will enable iterative development by multiple >>> devs without affecting other sub-teams. When the feature(refactoring) is >>> finished, the branch would be rebased on master and merged there. Note: >>> rebases can be done as needed - e.g. when other subteam finishes its >>> work. >>> >>> Concerns: >>> 1. Upstream git repo would be full of such branches. >>> - This can be mitigated by deleting the feature branches when their are >>> released or merged(up to discussion) >> Don't put them in the upstream git repo. Let people decide where they >> want to have them -- all Fedora contributors have access to >> fedorapeople.org git hosting and there is github one button click >> ('Clone') away from the github mirror. >> >> It is not a problem to keep a separate git branch published this way. >> > >It is not a matter of making the code public. That can be done easily as >you write. Other alternative is own branch in GitHub fork. > >> May be I misunderstand you -- if you just want people to propose merge >> requests on github with pre-defined names, then that's just fine. >> > >Basically it's all about review. > >Example use case: More than 1 devs are working on a same big effort. >This effort will probably consists of 10s of commits. The big effort is >divided into smaller ones which can be implemented and reviewed >separately. In our previous mode, the sub task would be merged to master >it is reviewed and ACKed. But now we cannot do that. We want to merge >the whole big task at once when it is finishes and tested. > >One dev could probably have a branch on personal fork of FreeIPA on >GitHub which would work as the feature branch. Other team members would >create pull requests against it. > >In such case we would loose mail notifications and would have to extend >our tooling because ipatool can use only one upstream on push. So I still think this is not a problem. If people can agree which git repo clone will be primary one and submit merge requests against it, then there is no problem in having that git repo's branch to be submitted as the pull request against the main git repo. This way you'll get all the changes seen at the pull request sync time. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Tue Oct 11 14:31:26 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:31:26 +0200 Subject: [Freeipa-devel] [freeipa PR#134][+ack] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support Label: +ack From freeipa-github-notification at redhat.com Tue Oct 11 14:49:08 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:49:08 +0200 Subject: [Freeipa-devel] [freeipa PR#134][+pushed] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 11 14:49:10 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:49:10 +0200 Subject: [Freeipa-devel] [freeipa PR#134][comment] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Title: #134: DNS URI support mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/f363dfbeed7aeba51d694a60b29389d94c7bda44 https://fedorahosted.org/freeipa/changeset/bf96b80200c3e8d1795a913db4e0222ea558e609 https://fedorahosted.org/freeipa/changeset/51af7a15981eca753dfbda133cc557d0512f6e95 """ See the full comment at https://github.com/freeipa/freeipa/pull/134#issuecomment-252939875 From freeipa-github-notification at redhat.com Tue Oct 11 14:49:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:49:11 +0200 Subject: [Freeipa-devel] [freeipa PR#134][closed] DNS URI support In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/134 Author: pspacek Title: #134: DNS URI support Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/134/head:pr134 git checkout pr134 From freeipa-github-notification at redhat.com Tue Oct 11 14:50:52 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:50:52 +0200 Subject: [Freeipa-devel] [freeipa PR#144][+pushed] Pylint: remove unused values - the last part In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/144 Title: #144: Pylint: remove unused values - the last part Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 11 14:50:53 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:50:53 +0200 Subject: [Freeipa-devel] [freeipa PR#144][comment] Pylint: remove unused values - the last part In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/144 Title: #144: Pylint: remove unused values - the last part mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/49b29591aa979560068449b78fd547915420ff08 https://fedorahosted.org/freeipa/changeset/4628522c532c6df0295308e5f749989c2536caa6 """ See the full comment at https://github.com/freeipa/freeipa/pull/144#issuecomment-252940396 From freeipa-github-notification at redhat.com Tue Oct 11 14:50:55 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:50:55 +0200 Subject: [Freeipa-devel] [freeipa PR#144][closed] Pylint: remove unused values - the last part In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/144 Author: mbasti-rh Title: #144: Pylint: remove unused values - the last part Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/144/head:pr144 git checkout pr144 From freeipa-github-notification at redhat.com Tue Oct 11 14:51:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:51:59 +0200 Subject: [Freeipa-devel] [freeipa PR#133][+ack] Tests: print what was expected from exceptions and callables in xmlrpc_tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/133 Title: #133: Tests: print what was expected from exceptions and callables in xmlrpc_tests Label: +ack From freeipa-github-notification at redhat.com Tue Oct 11 14:52:56 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:52:56 +0200 Subject: [Freeipa-devel] [freeipa PR#133][+pushed] Tests: print what was expected from exceptions and callables in xmlrpc_tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/133 Title: #133: Tests: print what was expected from exceptions and callables in xmlrpc_tests Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 11 14:52:58 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:52:58 +0200 Subject: [Freeipa-devel] [freeipa PR#133][comment] Tests: print what was expected from exceptions and callables in xmlrpc_tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/133 Title: #133: Tests: print what was expected from exceptions and callables in xmlrpc_tests mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/8683cbf1242230fff8cd94da8aa27b27e9307535 """ See the full comment at https://github.com/freeipa/freeipa/pull/133#issuecomment-252941044 From freeipa-github-notification at redhat.com Tue Oct 11 14:52:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 16:52:59 +0200 Subject: [Freeipa-devel] [freeipa PR#133][closed] Tests: print what was expected from exceptions and callables in xmlrpc_tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/133 Author: pspacek Title: #133: Tests: print what was expected from exceptions and callables in xmlrpc_tests Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/133/head:pr133 git checkout pr133 From freeipa-github-notification at redhat.com Tue Oct 11 15:02:02 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 17:02:02 +0200 Subject: [Freeipa-devel] [freeipa PR#136][comment] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Title: #136: Fix KRA install tests mbasti-rh commented: """ Self NACK, I should not remove tests, I have to fix tasks.py to install replica properly with KRA, because we actually support --setup-kra option """ See the full comment at https://github.com/freeipa/freeipa/pull/136#issuecomment-252943729 From freeipa-github-notification at redhat.com Tue Oct 11 15:03:33 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 17:03:33 +0200 Subject: [Freeipa-devel] [freeipa PR#140][edited] Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Author: mirielka Title: #140: Tests: Fix cert revocation tests Action: edited Changed field: title Original value: """ Tests: Remove invalid certplugin tests """ From freeipa-github-notification at redhat.com Tue Oct 11 15:21:03 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 17:21:03 +0200 Subject: [Freeipa-devel] [freeipa PR#146][+ack] WebUI: fix API Browser menu label In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/146 Title: #146: WebUI: fix API Browser menu label Label: +ack From freeipa-github-notification at redhat.com Tue Oct 11 15:25:03 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 17:25:03 +0200 Subject: [Freeipa-devel] [freeipa PR#146][+pushed] WebUI: fix API Browser menu label In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/146 Title: #146: WebUI: fix API Browser menu label Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 11 15:25:04 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 17:25:04 +0200 Subject: [Freeipa-devel] [freeipa PR#146][comment] WebUI: fix API Browser menu label In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/146 Title: #146: WebUI: fix API Browser menu label mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/28c7644980186f50ee007cd5c2f2edcf103eb942 """ See the full comment at https://github.com/freeipa/freeipa/pull/146#issuecomment-252950758 From freeipa-github-notification at redhat.com Tue Oct 11 15:25:06 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 17:25:06 +0200 Subject: [Freeipa-devel] [freeipa PR#146][closed] WebUI: fix API Browser menu label In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/146 Author: pvomacka Title: #146: WebUI: fix API Browser menu label Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/146/head:pr146 git checkout pr146 From freeipa-github-notification at redhat.com Tue Oct 11 17:00:34 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 11 Oct 2016 19:00:34 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Draft for a new setup.py (WIP) mbasti-rh commented: """ I cannot reinstall packages using your commits ``` dnf reinstall .rpm ... Error: Transaction check error: file /usr/lib/python2.7/site-packages/ipalib-4.4.90-py2.7.egg-info from install of python2-ipalib-4.4.90-0.fc24.noarch conflicts with file from package python2-ipalib-4.4.90-0.fc24.noarch file /usr/lib/python2.7/site-packages/ipaplatform-4.4.90-py2.7.egg-info from install of python2-ipalib-4.4.90-0.fc24.noarch conflicts with file from package python2-ipalib-4.4.90-0.fc24.noarch file /usr/lib/python2.7/site-packages/ipapython-4.4.90-py2.7.egg-info from install of python2-ipalib-4.4.90-0.fc24.noarch conflicts with file from package python2-ipalib-4.4.90-0.fc24.noarch file /usr/lib/python2.7/site-packages/ipaclient-4.4.90-py2.7.egg-info from install of python2-ipaclient-4.4.90-0.fc24.noarch conflicts with file from package python2-ipaclient-4.4.90-0.fc24.noarch file /usr/lib/python3.5/site-packages/ipalib-4.4.90-py3.5.egg-info from install of python3-ipalib-4.4.90-0.fc24.noarch conflicts with file from package python3-ipalib-4.4.90-0.fc24.noarch file /usr/lib/python3.5/site-packages/ipaplatform-4.4.90-py3.5.egg-info from install of python3-ipalib-4.4.90-0.fc24.noarch conflicts with file from package python3-ipalib-4.4.90-0.fc24.noarch file /usr/lib/python3.5/site-packages/ipapython-4.4.90-py3.5.egg-info from install of python3-ipalib-4.4.90-0.fc24.noarch conflicts with file from package python3-ipalib-4.4.90-0.fc24.noarch file /usr/lib/python3.5/site-packages/ipaclient-4.4.90-py3.5.egg-info from install of python3-ipaclient-4.4.90-0.fc24.noarch conflicts with file from package python3-ipaclient-4.4.90-0.fc24.noarch file /usr/lib/python3.5/site-packages/ipatests-4.4.90-py3.5.egg-info from install of python3-ipatests-4.4.90-0.fc24.noarch conflicts with file from package python3-ipatests-4.4.90-0.fc24.noarch file /usr/lib/python2.7/site-packages/ipatests-4.4.90-py2.7.egg-info from install of python2-ipatests-4.4.90-0.fc24.noarch conflicts with file from package python2-ipatests-4.4.90-0.fc24.noarch ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-252978511 From freeipa-github-notification at redhat.com Tue Oct 11 17:15:00 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 11 Oct 2016 19:15:00 +0200 Subject: [Freeipa-devel] [freeipa PR#152][opened] Fix warnings reported by pylint in rawhide Message-ID: URL: https://github.com/freeipa/freeipa/pull/152 Author: martbab Title: #152: Fix warnings reported by pylint in rawhide Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6391 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/152/head:pr152 git checkout pr152 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-152.patch Type: text/x-diff Size: 15217 bytes Desc: not available URL: From mharmsen at redhat.com Tue Oct 11 19:12:46 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 11 Oct 2016 13:12:46 -0600 Subject: [Freeipa-devel] Karma Requests for pki-core-10.3.5-7 and pki-console-10.3.5-2 Message-ID: <16446870-894a-178a-a664-58c009c62931@redhat.com> *The following updated candidate builds of pki-core 10.3.5 and pki-console 10.3.5 were generated:* * *Fedora 24* o *pki-core-10.3.5-7.fc24 * o *pki-console-10.3.5-2.fc24 * * *Fedora 25* o *pki-core-10.3.5-7.fc25 * o *pki-console-10.3.5-2.fc25 * * *Fedora 26* o *pki-core-10.3.5-7.fc26 (still working on build issues encountered on rawhide)* o *pki-console-10.3.5-2.fc26 * *Additionally, the CentOS 7 COPR EPEL Builds of Dogtag 10.3.3 were also updated:* * *https://copr.fedorainfracloud.org/coprs/g/pki/epel-7.3/repo/epel-7/group_pki-epel-7.3-epel-7.repo* [group_pki-epel-7.3] name=Copr repo for epel-7.3 owned by @pki baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/epel-7.3/epel-7-$basearch/ type=rpm-md skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/epel-7.3/pubkey.gpg repo_gpgcheck=0 enabled=1 enabled_metadata=1 *These builds address the following PKI tickets:* * PKI TRAC Ticket #1527 - TPS Enrollment always goes to "ca1" (cfu) * PKI TRAC Ticket #1664 - [BUG] Add ability to disallow TPS to enroll a single user on multiple tokens. (jmagne) * PKI TRAC Ticket #2463 - Troubleshooting improvements (edewata) o potentially more to come in future releases * PKI TRAC Ticket #2466 - two-step externally-signed CA installation fails due to missing AuthorityID (ftweedal) * PKI TRAC Ticket #2475 - Multiple host authority entries created (ftweedal) * PKI TRAC Ticket #2476 - Dogtag Miscellaneous Minor Changes (edewata) o potentially more to come in future releases * PKI TRAC Ticket #2478 - pkispawn fails as it is not able to find openssl as a dependency package (mharmsen) * PKI TRAC Ticket #2483 - Unable to read an encrypted email using renewed tokens (jmagne) * PKI TRAC Ticket #2496 - Cert/Key recovery is successful when the cert serial number and key id on the ldap user mismatches (cfu) * PKI TRAC Ticket #2497 - KRA installation failed against externally-signed CA with partial certificate chain (edewata) * PKI TRAC Ticket #2505 - Fix packaging duplicates of classes in multiple jar files (edewata) *Please provide Karma for the following builds:* * *Fedora 24* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-76fae7b25f pki-core-10.3.5-7.fc24 * o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-a9e6c42783 pki-console-10.3.5-2.fc24 * * *Fedora 25* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3496056579 pki-core-10.3.5-7.fc25* o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-70b3b8b697 pki-console-10.3.5-2.fc25 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Oct 12 06:06:27 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 12 Oct 2016 08:06:27 +0200 Subject: [Freeipa-devel] [freeipa PR#142][synchronized] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Author: dkupka Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/142/head:pr142 git checkout pr142 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-142.patch Type: text/x-diff Size: 1827 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 07:23:09 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 09:23:09 +0200 Subject: [Freeipa-devel] [freeipa PR#152][+ack] Fix warnings reported by pylint in rawhide In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/152 Title: #152: Fix warnings reported by pylint in rawhide Label: +ack From freeipa-github-notification at redhat.com Wed Oct 12 07:28:39 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 12 Oct 2016 09:28:39 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Fix cert revocation tests pvomacka commented: """ Works correctly. ACK """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-253139511 From freeipa-github-notification at redhat.com Wed Oct 12 07:28:49 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 12 Oct 2016 09:28:49 +0200 Subject: [Freeipa-devel] [freeipa PR#140][+ack] Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Fix cert revocation tests Label: +ack From freeipa-github-notification at redhat.com Wed Oct 12 08:36:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:36:11 +0200 Subject: [Freeipa-devel] [freeipa PR#142][+ack] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Label: +ack From freeipa-github-notification at redhat.com Wed Oct 12 08:39:15 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:39:15 +0200 Subject: [Freeipa-devel] [freeipa PR#152][closed] Fix warnings reported by pylint in rawhide In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/152 Author: martbab Title: #152: Fix warnings reported by pylint in rawhide Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/152/head:pr152 git checkout pr152 From freeipa-github-notification at redhat.com Wed Oct 12 08:39:16 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:39:16 +0200 Subject: [Freeipa-devel] [freeipa PR#152][comment] Fix warnings reported by pylint in rawhide In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/152 Title: #152: Fix warnings reported by pylint in rawhide mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/29829cc55a6be697abf881ea7867ef834bb66be7 https://fedorahosted.org/freeipa/changeset/71f642f75132fe30b40062ce5abc8558a275b9bb """ See the full comment at https://github.com/freeipa/freeipa/pull/152#issuecomment-253153404 From freeipa-github-notification at redhat.com Wed Oct 12 08:39:18 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:39:18 +0200 Subject: [Freeipa-devel] [freeipa PR#152][+pushed] Fix warnings reported by pylint in rawhide In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/152 Title: #152: Fix warnings reported by pylint in rawhide Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 12 08:42:45 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:42:45 +0200 Subject: [Freeipa-devel] [freeipa PR#142][+pushed] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 12 08:42:47 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:42:47 +0200 Subject: [Freeipa-devel] [freeipa PR#142][comment] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/fb85230e25bd37a2a02a9d90793f337aad40a037 ipa-4-4: https://fedorahosted.org/freeipa/changeset/1b6ba5283e4980da7bd5f1d98b5518062a4c61ad """ See the full comment at https://github.com/freeipa/freeipa/pull/142#issuecomment-253154169 From freeipa-github-notification at redhat.com Wed Oct 12 08:42:48 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:42:48 +0200 Subject: [Freeipa-devel] [freeipa PR#142][closed] CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/142 Author: dkupka Title: #142: CheckedIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/142/head:pr142 git checkout pr142 From freeipa-github-notification at redhat.com Wed Oct 12 08:45:05 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:45:05 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Fix cert revocation tests mbasti-rh commented: """ `Tests: Certificate revocation` doesn't apply to ipa-4-4 branch, please open separate PR against IPA 4.4 """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-253154655 From freeipa-github-notification at redhat.com Wed Oct 12 08:45:42 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:45:42 +0200 Subject: [Freeipa-devel] [freeipa PR#140][+pushed] Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Fix cert revocation tests Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 12 08:45:43 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:45:43 +0200 Subject: [Freeipa-devel] [freeipa PR#140][comment] Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Title: #140: Tests: Fix cert revocation tests mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/c9c92e3a7f4961d91e0395daf17f5aeb34c20178 https://fedorahosted.org/freeipa/changeset/8f04d1a793b8ff01804bc03eac9b7aaa4f7a7f78 """ See the full comment at https://github.com/freeipa/freeipa/pull/140#issuecomment-253154795 From freeipa-github-notification at redhat.com Wed Oct 12 08:45:44 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:45:44 +0200 Subject: [Freeipa-devel] [freeipa PR#140][closed] Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/140 Author: mirielka Title: #140: Tests: Fix cert revocation tests Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/140/head:pr140 git checkout pr140 From freeipa-github-notification at redhat.com Wed Oct 12 08:54:03 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:54:03 +0200 Subject: [Freeipa-devel] [freeipa PR#137][+pushed] Test: disabled wrong client domain tests for domlevel 0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/137 Title: #137: Test: disabled wrong client domain tests for domlevel 0 Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 12 08:54:05 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:54:05 +0200 Subject: [Freeipa-devel] [freeipa PR#137][comment] Test: disabled wrong client domain tests for domlevel 0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/137 Title: #137: Test: disabled wrong client domain tests for domlevel 0 mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/8b0faa25d1c47f605bc6c91933469bb2370276c1 ipa-4-4: https://fedorahosted.org/freeipa/changeset/1a27d3037fa6fbbddcdfb08fe41690bf534e6f7b """ See the full comment at https://github.com/freeipa/freeipa/pull/137#issuecomment-253156632 From freeipa-github-notification at redhat.com Wed Oct 12 08:54:06 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 10:54:06 +0200 Subject: [Freeipa-devel] [freeipa PR#137][closed] Test: disabled wrong client domain tests for domlevel 0 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/137 Author: ofayans Title: #137: Test: disabled wrong client domain tests for domlevel 0 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/137/head:pr137 git checkout pr137 From rajat.linux at gmail.com Wed Oct 12 08:55:39 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Wed, 12 Oct 2016 10:55:39 +0200 Subject: [Freeipa-devel] HBAC for AD users Active Directory trust setup Message-ID: Hi, Normally HBAC for AD users should be done through an external group. So for example if we have 500+ users on AD and only 100 user are administrator and they have Linux server access. I want to set the HBAC and sudo rules for users. So user have correct access server access and sudo rights and I am using the *Active Directory trust setup* In this case i need to add all of the 100 users on in Freeipa as external group. for example :- user1 user name in AD *user1-external* external group in IPA for trusted domain users *user1 :- *POSIX group for external Do we have document for implementing the HBAC and Sudo Rules for external group. Or is there any other best way to implement the HBAC and Sudo Rules on AD users. -- *Rajat Gupta* -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Oct 12 09:00:33 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 12 Oct 2016 11:00:33 +0200 Subject: [Freeipa-devel] [freeipa PR#153][opened] [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 Message-ID: URL: https://github.com/freeipa/freeipa/pull/153 Author: martbab Title: #153: [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 Action: opened PR body: """ Pylint shipped in Fedora 25 reports 'trailing-newlines' and 'consider-iterating-dictionary' warnings which break FreeIPA builds. On ipa-4-4 branch it is safer to just disable these warnings so as to not mess with code considered stable https://fedorahosted.org/freeipa/ticket/6391 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/153/head:pr153 git checkout pr153 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-153.patch Type: text/x-diff Size: 892 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 09:00:39 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Wed, 12 Oct 2016 11:00:39 +0200 Subject: [Freeipa-devel] [freeipa PR#154][opened] [ipa-4-4] Rebase: Tests: Fix cert revocation tests Message-ID: URL: https://github.com/freeipa/freeipa/pull/154 Author: mirielka Title: #154: [ipa-4-4] Rebase: Tests: Fix cert revocation tests Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/154/head:pr154 git checkout pr154 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-154.patch Type: text/x-diff Size: 7702 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 12 09:05:14 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Oct 2016 12:05:14 +0300 Subject: [Freeipa-devel] HBAC for AD users Active Directory trust setup In-Reply-To: References: Message-ID: <20161012090514.f67kubhrt3xwlxnh@redhat.com> On ke, 12 loka 2016, rajat gupta wrote: >Hi, > >Normally HBAC for AD users should be done through an external group. You should use freeipa-users@ mailing list for these questions. And start with documentation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html > >So for example if we have 500+ users on AD and only 100 user are >administrator and they have Linux server access. > >I want to set the HBAC and sudo rules for users. So user have correct >access server access and sudo rights and I am using the *Active Directory >trust setup* > >In this case i need to add all of the 100 users on in Freeipa as external >group. > >for example :- user1 user name in AD > >*user1-external* external group in IPA for trusted domain users >*user1 :- *POSIX group for external No, you don't need to do that. All you need to do is to create a group on AD side where your users to access Linux systems would be added and then add that group to the external group on IPA side. >Do we have document for implementing the HBAC and Sudo Rules for external >group. See above documentation and discussions on freeipa-users@ mailing list. -- / Alexander Bokovoy From pspacek at redhat.com Wed Oct 12 09:11:54 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Oct 2016 11:11:54 +0200 Subject: [Freeipa-devel] Broken IPA installation caused by new python-dns package In-Reply-To: <7ec8e751-af67-5850-d051-d1f7fe96025f@redhat.com> References: <7ec8e751-af67-5850-d051-d1f7fe96025f@redhat.com> Message-ID: On 10.10.2016 10:28, Martin Basti wrote: > https://bodhi.fedoraproject.org/updates/FEDORA-2016-1857421df6 > > > Please set karma accordingly > > > Traceback: > > ... > > File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", > line 426, in update_dns_records > self.update_base_records(), > File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", > line 377, in update_base_records > base_zone = self.get_base_records() > File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", > line 328, in get_base_records > include_kerberos_realm=include_kerberos_realm > File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", > line 179, in _add_base_dns_records_for_server > self.__add_kerberos_txt_rec(zone_obj) > File "/usr/lib/python2.7/site-packages/ipaserver/dns_data_management.py", > line 165, in __add_kerberos_txt_rec > rdataset.add(rd, ttl=86400) # FIXME: use TTL from config > File "/usr/lib/python2.7/site-packages/dns/rdataset.py", line 129, in add > super(Rdataset, self).add(rd) > File "/usr/lib/python2.7/site-packages/dns/set.py", line 49, in add > if item not in self.items: > File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 217, in __eq__ > return self._cmp(other) == 0 > File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 203, in _cmp > our = self.to_digestable(dns.name.root) > File "/usr/lib/python2.7/site-packages/dns/rdata.py", line 174, in > to_digestable > self.to_wire(f, None, origin) > File "/usr/lib/python2.7/site-packages/dns/rdtypes/txtbase.py", line 75, in > to_wire > file.write(s) > > 2016-10-10T04:44:05Z DEBUG The ipa-replica-install command failed, exception: > TypeError: 'unicode' does not have the buffer interface > 2016-10-10T04:44:05Z ERROR 'unicode' does not have the buffer interface > > > I'll investigate if IPA using it wrong or there is new error introduced in > pyhton-dns For archaeologists: Fix https://github.com/freeipa/freeipa/pull/150 was merged. -- Petr^2 Spacek From freeipa-github-notification at redhat.com Wed Oct 12 09:14:40 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 11:14:40 +0200 Subject: [Freeipa-devel] [freeipa PR#153][+ack] [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/153 Title: #153: [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 Label: +ack From freeipa-github-notification at redhat.com Wed Oct 12 09:15:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 11:15:11 +0200 Subject: [Freeipa-devel] [freeipa PR#153][+pushed] [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/153 Title: #153: [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 12 09:15:13 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 11:15:13 +0200 Subject: [Freeipa-devel] [freeipa PR#153][comment] [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/153 Title: #153: [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 mbasti-rh commented: """ Fixed upstream ipa-4-4: https://fedorahosted.org/freeipa/changeset/2b2fc1abf1844b807e50b99f0912fa10d9169eca """ See the full comment at https://github.com/freeipa/freeipa/pull/153#issuecomment-253161249 From freeipa-github-notification at redhat.com Wed Oct 12 09:15:14 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 11:15:14 +0200 Subject: [Freeipa-devel] [freeipa PR#153][closed] [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/153 Author: martbab Title: #153: [ipa-4-4 only] disable warnings reported by pylint-1.6.4-1 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/153/head:pr153 git checkout pr153 From freeipa-github-notification at redhat.com Wed Oct 12 09:32:05 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 12 Oct 2016 11:32:05 +0200 Subject: [Freeipa-devel] [freeipa PR#155][opened] Build system cleanup Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Author: pspacek Title: #155: Build system cleanup Action: opened PR body: """ This is first step in build system refactoring effort. This patch set contains cleanup patches for daemons/configure.ac. After the cleanup, the file will be "promoted" to top-level configure.ac and merged with other configure.ac files in subdirectories. I did not touch other configure.ac files on purpose as these mostly duplicate daemons/configure.ac and will be simply dropped later on. From functional perspective, there should not be any visible changes. FreeIPA should build as before, using the same horrible Makefile. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/155/head:pr155 git checkout pr155 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-155.patch Type: text/x-diff Size: 12104 bytes Desc: not available URL: From rajat.linux at gmail.com Wed Oct 12 09:38:22 2016 From: rajat.linux at gmail.com (rajat gupta) Date: Wed, 12 Oct 2016 11:38:22 +0200 Subject: [Freeipa-devel] HBAC for AD users Active Directory trust setup In-Reply-To: <20161012090514.f67kubhrt3xwlxnh@redhat.com> References: <20161012090514.f67kubhrt3xwlxnh@redhat.com> Message-ID: Hi, thank you for answering. I this case i need to create multiple group in AD side. like user1 have only "server1.example.com" and "server2.example.com" access and some other user have some other server access. Then only the my HBAC rule will be implemented to particular group and every time i need to add user in AD side on particular group if I want to give some other server access to user. And i don't want do like this. On Wed, Oct 12, 2016 at 11:05 AM, Alexander Bokovoy wrote: > On ke, 12 loka 2016, rajat gupta wrote: > >> Hi, >> >> Normally HBAC for AD users should be done through an external group. >> > You should use freeipa-users@ mailing list for these questions. > > And start with documentation: https://access.redhat.com/docu > mentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/ > Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html > https://access.redhat.com/documentation/en-US/Red_Hat_Enterp > rise_Linux/7/html-single/Windows_Integration_Guide/index.html > > > >> So for example if we have 500+ users on AD and only 100 user are >> administrator and they have Linux server access. >> >> I want to set the HBAC and sudo rules for users. So user have correct >> access server access and sudo rights and I am using the *Active Directory >> trust setup* >> >> In this case i need to add all of the 100 users on in Freeipa as external >> group. >> >> for example :- user1 user name in AD >> >> *user1-external* external group in IPA for trusted domain users >> *user1 :- *POSIX group for external >> > No, you don't need to do that. All you need to do is to create a group > on AD side where your users to access Linux systems would be added and > then add that group to the external group on IPA side. > > Do we have document for implementing the HBAC and Sudo Rules for external >> group. >> > See above documentation and discussions on freeipa-users@ mailing list. > > -- > / Alexander Bokovoy > -- *Rajat Gupta * -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Oct 12 10:30:20 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Oct 2016 13:30:20 +0300 Subject: [Freeipa-devel] HBAC for AD users Active Directory trust setup In-Reply-To: References: <20161012090514.f67kubhrt3xwlxnh@redhat.com> Message-ID: <20161012103019.u72spwg7tmoig7xb@redhat.com> On ke, 12 loka 2016, rajat gupta wrote: >Hi, > >thank you for answering. > >I this case i need to create multiple group in AD side. like user1 have >only "server1.example.com" and "server2.example.com" access and some other >user have some other server access. Then only the my HBAC >rule will be implemented to particular group and every time i need to add >user in AD side on particular group if I want to give some other server >access to user. And i don't want do like this. It is up to you what you want to implement. The means are all there. But read my responses on the freeipa-users@ to understand why we implemented it this way. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Wed Oct 12 10:47:35 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 12 Oct 2016 12:47:35 +0200 Subject: [Freeipa-devel] [freeipa PR#154][+ack] [ipa-4-4] Rebase: Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/154 Title: #154: [ipa-4-4] Rebase: Tests: Fix cert revocation tests Label: +ack From freeipa-github-notification at redhat.com Wed Oct 12 10:48:42 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 12:48:42 +0200 Subject: [Freeipa-devel] [freeipa PR#154][closed] [ipa-4-4] Rebase: Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/154 Author: mirielka Title: #154: [ipa-4-4] Rebase: Tests: Fix cert revocation tests Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/154/head:pr154 git checkout pr154 From freeipa-github-notification at redhat.com Wed Oct 12 10:48:43 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 12:48:43 +0200 Subject: [Freeipa-devel] [freeipa PR#154][comment] [ipa-4-4] Rebase: Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/154 Title: #154: [ipa-4-4] Rebase: Tests: Fix cert revocation tests mbasti-rh commented: """ Fixed upstream ipa-4-4: https://fedorahosted.org/freeipa/changeset/afabdd365a35e0e454997ff021152422bcbcf785 https://fedorahosted.org/freeipa/changeset/c8cdc6a9e6cfffff68f67d2e8df5aa7b22e13c26 """ See the full comment at https://github.com/freeipa/freeipa/pull/154#issuecomment-253180869 From freeipa-github-notification at redhat.com Wed Oct 12 10:48:45 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 12 Oct 2016 12:48:45 +0200 Subject: [Freeipa-devel] [freeipa PR#154][+pushed] [ipa-4-4] Rebase: Tests: Fix cert revocation tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/154 Title: #154: [ipa-4-4] Rebase: Tests: Fix cert revocation tests Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 12 11:07:45 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 12 Oct 2016 13:07:45 +0200 Subject: [Freeipa-devel] [freeipa PR#155][synchronized] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Author: pspacek Title: #155: Build system cleanup Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/155/head:pr155 git checkout pr155 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-155.patch Type: text/x-diff Size: 12740 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 11:10:38 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 12 Oct 2016 13:10:38 +0200 Subject: [Freeipa-devel] [freeipa PR#156][opened] cert: add revocation reason back to cert-find output Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Author: jcholast Title: #156: cert: add revocation reason back to cert-find output Action: opened PR body: """ In commit c718ef058847bb39e78236e8af0ad69ac961bbcf some param values were accidentally removed from cert-find output. In commit 22d5f579bbd8bb452cf1bf620294ab6ade6e7c47 `serial_number_hex` and `revoked` were added back. Add back `revocation_reason` as well. https://fedorahosted.org/freeipa/ticket/6269 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/156/head:pr156 git checkout pr156 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-156.patch Type: text/x-diff Size: 1966 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 11:40:30 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Wed, 12 Oct 2016 13:40:30 +0200 Subject: [Freeipa-devel] [freeipa PR#157][opened] git: Add commit template Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Author: mzidek-rh Title: #157: git: Add commit template Action: opened PR body: """ In order to use the commit template, run the following command: git config commit.template .git-commit-template """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/157/head:pr157 git checkout pr157 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-157.patch Type: text/x-diff Size: 816 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 11:40:57 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Wed, 12 Oct 2016 13:40:57 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template mzidek-rh commented: """ This is the same commit template we use in SSSD. Maybe it will be helpful for FreeIPA too. """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-253190654 From freeipa-github-notification at redhat.com Wed Oct 12 11:47:47 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 12 Oct 2016 13:47:47 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template martbab commented: """ Could you please change the link in the template to: https://fedorahosted.org/freeipa/ticket/XXXX just to avoid copy-paste errors when filling in ticket No.? """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-253191997 From freeipa-github-notification at redhat.com Wed Oct 12 11:53:09 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Wed, 12 Oct 2016 13:53:09 +0200 Subject: [Freeipa-devel] [freeipa PR#157][synchronized] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Author: mzidek-rh Title: #157: git: Add commit template Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/157/head:pr157 git checkout pr157 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-157.patch Type: text/x-diff Size: 819 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 11:54:28 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Wed, 12 Oct 2016 13:54:28 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template mzidek-rh commented: """ Sure, that was a copy paste mistake in itself :) . Patch updated. """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-253193300 From ofayans at redhat.com Wed Oct 12 12:03:47 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 12 Oct 2016 14:03:47 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> Message-ID: <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> Hi Martin, After extensive discussion with Ludwig, I finally got the clue on how does this feature work. When we uninstall the replica, the master cleans the replication agreements with this replica and automatically cleans all replica's RUVs. If we clean replica's RUVs on master without uninstalling the replica, the replica's RUVs get recreated on master (replication works!). So, the only way to test the clean-ruv subcommand is to turn off the replica, or block the traffic on it so it gets inaccessible to updates from master. The testcases were updated, see [1] and [2] The updated versions of the patches are attached [1] http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs [2] http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand On 08/05/2016 06:36 PM, Martin Basti wrote: > > > On 03.08.2016 14:45, Oleg Fayans wrote: >> Hi Martin, >> >> Thanks for the review! Both patches were updated. >> >> On 07/28/2016 04:11 PM, Martin Basti wrote: >>> >>> >>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review! >>>> >>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>> Hi guys, >>>>>> >>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>> before >>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>> feature. >>>>>> >>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>> One more test was added to the patch-0048 >>>>>>> >>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases from >>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>> IIUC, this will turn off the machine completely, how is cleanup done >>>>> then. AFAIK our tests cannot turn on machine again and run >>>>> cleanup, so >>>>> you will not be able to run more tests on the same topology without >>>>> manual cleanup and manual start. >>>>> >>>>> + replica = self.replicas[0] >>>>> + replica.run_command(['poweroff']) >>>>> >>>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>>> >>>> Agreed! Fixed. >>>> >>>>> >>>>> Martin^2 >>>>> >>>> >>>> >>>> >>> *Automated ipa-replica-manage del tests* >>> >>> 1) >>> + replica.run_command(['ipactl', 'stop']) >>> + time.sleep(3) >>> >>> Why do you need sleep here? >> >> Removed, it was left from the old "poweroff" approach >> >>> >>> >>> 2) >>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>> + '-p', master.config.dirman_password, >>> + replica_ruvs[0]]) >>> >>> Because you are using re.findall(), without any match you will receive >>> IndexError here replica_ruvs[0]. IMO it deserves assert before >> >> Implemented the assert which checks that the output contains enough >> replica RUVs >> >>> >>> 3) >>> assert(replica.hostname in result1.stdout_text) >>> >>> I think that this is error prone. What if there is just error 'could not >>> connect to replica ', or something similar. instead of >>> listing/cleaning/whatever operation was executed. I think that it should >>> be more specific regexp than just finding a replica name substring (Yes >>> In IPA we dont always print error so stderr) >>> >>> I'm not sure, but probably there might be cases when non critical error >>> happen and exist status is still 0 >> >> Agree. Implemented a regex-based search >> >>> >>> 4) >>> >>> + replica.run_command(['poweroff']) >>> + time.sleep(3) >>> >>> There should not be poweroff, probably sleep could be removed too. >> >> Gone >> >>> >>> >>> * Automated clean-ruv subcommand test* >>> >>> 1) PEP8, 2 new lines expected >>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>> blank lines, found 0 >>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too long >>> (85 > 79 characters) >> >> Fixed >> >>> >>> >>> 2) >>> I dont like doing assert just with count of occurences of substring in >>> STDOUT, would be possible to improve this somehow? >> >> Maybe, but frankly, I don't see how. In this case we are making sure >> that both simple and CA-specific RUVs of a replica are displayed. The >> format of the output is strict: >> Replica Update Vectors: >> replica1_hostname:389: RUV_id >> replica2_hostname:389: RUV_id >> Certificate Server Replica Update Vectors: >> replica1_hostname:389: RUV_id >> replica2_hostname:389: RUV_id >> If we do not see 2 occurrences of the replica hostname than definitely >> something went wrong >> >>> >>> 3) >>> I'm not sure if clean-ruv is instant operations or there is some magic >>> happening in background (we have abort-clean-ruv). Maybe some sleep >>> should be there, but this needs investigation. >>> >>> + assert(replica.hostname in result2.stdout_text), ( >>> + "The wrong RUV was deleted") >>> + result3 = master.run_command(['ipa-replica-manage', 'list-ruv', >>> + '-p', >>> master.config.dirman_password]) >>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>> + "CA RUV of the replica is still displayed") >>> >> >> Based on my discussion with Stanislav Laznicka, I understood that by >> default clean-ruv does not return the shell until the operation is >> finished. You can force dropping into the shell by pressing CTRL+C, in >> which case the background job will still be running, but this is not >> the default behavior >> > Test failed: > result4 = master.run_command(['ipa-replica-manage', 'list-ruv', > '-p', master.config.dirman_password]) >> assert(replica.hostname not in result4.stdout_text), ( > "replica's RUV is still displayed") > E AssertionError: replica's RUV is still displayed > E assert 'replica3.ipa.test' not in 'Replica Update > V...ipa.test:389: 8\n' > E 'replica3.ipa.test' is contained here: > E Replica Update Vectors: > E \tmaster.ipa.test:389: 4 > E \treplica3.ipa.test:389: 3 > E \treplica2.ipa.test:389: 7 > E Certificate Server Replica Update Vectors: > E \tmaster.ipa.test:389: 6 > E \treplica2.ipa.test:389: 8 > > > [root at master ~]# ipa topologysegment-find > Suffix name: domain > ------------------ > 2 segments matched > ------------------ > Segment name: master.ipa.test-to-replica2.ipa.test > Left node: master.ipa.test > Right node: replica2.ipa.test > Connectivity: both > > Segment name: master.ipa.test-to-replica3.ipa.test > Left node: master.ipa.test > Right node: replica3.ipa.test > Connectivity: both > ---------------------------- > Number of entries returned 2 > ---------------------------- > [root at master ~]# ipa-replica-manage list-ruv > Directory Manager password: > > Replica Update Vectors: > master.ipa.test:389: 4 > replica2.ipa.test:389: 7 > replica3.ipa.test:389: 3 > Certificate Server Replica Update Vectors: > master.ipa.test:389: 6 > replica2.ipa.test:389: 8 > [root at master ~]# > > Then I tried manually to clean RUV 3, and it behaves somehow odd > > [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' '-f' > Clean the Replication Update Vector for replica3.ipa.test:389 > Background task created to clean replication data. This may take a while. > This may be safely interrupted with Ctrl+C > Cleanup task created > [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors > [root at master ~]# ipa-replica-manage list-ruv > Directory Manager password: > > Replica Update Vectors: > master.ipa.test:389: 4 > replica2.ipa.test:389: 7 > replica3.ipa.test:389: 3 > Certificate Server Replica Update Vectors: > master.ipa.test:389: 6 > replica2.ipa.test:389: 8 > [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' '-f' > Clean the Replication Update Vector for replica3.ipa.test:389 > CLEANALLRUV task for replica id 3 already exists. > This may be safely interrupted with Ctrl+C > Cleanup task created > > [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 > No CLEANALLRUV tasks running > > No abort CLEANALLRUV tasks running > [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' 'Secret123' '-f' > Clean the Replication Update Vector for replica3.ipa.test:389 > Background task created to clean replication data. This may take a while. > This may be safely interrupted with Ctrl+C > Cleanup task created > [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 > CLEANALLRUV tasks > RID 3: Successfully cleaned rid(3). > > No abort CLEANALLRUV tasks running > [root at master ~]# ipa-replica-manage list-ruv -p Secret123 > Replica Update Vectors: > master.ipa.test:389: 4 > replica2.ipa.test:389: 7 > Certificate Server Replica Update Vectors: > master.ipa.test:389: 6 > replica2.ipa.test:389: 8 > > > I'm not sure if this behavior is right, Ludwig may know. -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0047.3-Automated-clean-ruv-subcommand-test.patch Type: text/x-patch Size: 5331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0048.4-Automated-ipa-replica-manage-del-tests.patch Type: text/x-patch Size: 4692 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 12:20:15 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 12 Oct 2016 14:20:15 +0200 Subject: [Freeipa-devel] [freeipa PR#158][opened] WebUI: update Patternfly and Bootstrap Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Author: pvomacka Title: #158: WebUI: update Patternfly and Bootstrap Action: opened PR body: """ Current versions: PatternFly: 3.9.0 Boostrap: 3.3.7 Bootstrap-select: 1.4.3 Font-Awesome: 4.0.3 https://fedorahosted.org/freeipa/ticket/6394 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/158/head:pr158 git checkout pr158 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-158.patch Type: text/x-diff Size: 539517 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 12:31:59 2016 From: freeipa-github-notification at redhat.com (redhatrises) Date: Wed, 12 Oct 2016 14:31:59 +0200 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap redhatrises commented: """ @pvomacka should this use the patternfly RPM rather than having the code copied here as well? See https://www.redhat.com/archives/patternfly/2014-July/msg00017.html """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-253200408 From freeipa-github-notification at redhat.com Wed Oct 12 12:32:28 2016 From: freeipa-github-notification at redhat.com (redhatrises) Date: Wed, 12 Oct 2016 14:32:28 +0200 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap redhatrises commented: """ @pvomacka should this use the patternfly RPM rather than having the code copied here as well? See https://www.redhat.com/archives/patternfly/2014-July/msg00017.html """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-253200408 From mbasti at redhat.com Wed Oct 12 12:35:58 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 12 Oct 2016 14:35:58 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> Message-ID: 1) Can you just turn off dirsrv on replica instead of doing iptables magic? 2) NACK No more eval() ever in code, use 'getattr', 'get' or whatever in the object that can be used. + evalhost = eval("args[0].%s" % host) Martin^2 On 12.10.2016 14:03, Oleg Fayans wrote: > Hi Martin, > > After extensive discussion with Ludwig, I finally got the clue on how > does this feature work. When we uninstall the replica, the master > cleans the replication agreements with this replica and automatically > cleans all replica's RUVs. > If we clean replica's RUVs on master without uninstalling the replica, > the replica's RUVs get recreated on master (replication works!). So, > the only way to test the clean-ruv subcommand is to turn off the > replica, or block the traffic on it so it gets inaccessible to updates > from master. > The testcases were updated, see [1] and [2] > > The updated versions of the patches are attached > > [1] > http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs > > [2] > http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand > > On 08/05/2016 06:36 PM, Martin Basti wrote: >> >> >> On 03.08.2016 14:45, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Thanks for the review! Both patches were updated. >>> >>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>> >>>> >>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Thanks for the review! >>>>> >>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>> before >>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>> feature. >>>>>>> >>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>> One more test was added to the patch-0048 >>>>>>>> >>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>> from >>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> IIUC, this will turn off the machine completely, how is cleanup done >>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>> cleanup, so >>>>>> you will not be able to run more tests on the same topology without >>>>>> manual cleanup and manual start. >>>>>> >>>>>> + replica = self.replicas[0] >>>>>> + replica.run_command(['poweroff']) >>>>>> >>>>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>>>> >>>>> Agreed! Fixed. >>>>> >>>>>> >>>>>> Martin^2 >>>>>> >>>>> >>>>> >>>>> >>>> *Automated ipa-replica-manage del tests* >>>> >>>> 1) >>>> + replica.run_command(['ipactl', 'stop']) >>>> + time.sleep(3) >>>> >>>> Why do you need sleep here? >>> >>> Removed, it was left from the old "poweroff" approach >>> >>>> >>>> >>>> 2) >>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>> + '-p', master.config.dirman_password, >>>> + replica_ruvs[0]]) >>>> >>>> Because you are using re.findall(), without any match you will receive >>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>> >>> Implemented the assert which checks that the output contains enough >>> replica RUVs >>> >>>> >>>> 3) >>>> assert(replica.hostname in result1.stdout_text) >>>> >>>> I think that this is error prone. What if there is just error >>>> 'could not >>>> connect to replica ', or something similar. >>>> instead of >>>> listing/cleaning/whatever operation was executed. I think that it >>>> should >>>> be more specific regexp than just finding a replica name substring >>>> (Yes >>>> In IPA we dont always print error so stderr) >>>> >>>> I'm not sure, but probably there might be cases when non critical >>>> error >>>> happen and exist status is still 0 >>> >>> Agree. Implemented a regex-based search >>> >>>> >>>> 4) >>>> >>>> + replica.run_command(['poweroff']) >>>> + time.sleep(3) >>>> >>>> There should not be poweroff, probably sleep could be removed too. >>> >>> Gone >>> >>>> >>>> >>>> * Automated clean-ruv subcommand test* >>>> >>>> 1) PEP8, 2 new lines expected >>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>> blank lines, found 0 >>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>> long >>>> (85 > 79 characters) >>> >>> Fixed >>> >>>> >>>> >>>> 2) >>>> I dont like doing assert just with count of occurences of substring in >>>> STDOUT, would be possible to improve this somehow? >>> >>> Maybe, but frankly, I don't see how. In this case we are making sure >>> that both simple and CA-specific RUVs of a replica are displayed. The >>> format of the output is strict: >>> Replica Update Vectors: >>> replica1_hostname:389: RUV_id >>> replica2_hostname:389: RUV_id >>> Certificate Server Replica Update Vectors: >>> replica1_hostname:389: RUV_id >>> replica2_hostname:389: RUV_id >>> If we do not see 2 occurrences of the replica hostname than definitely >>> something went wrong >>> >>>> >>>> 3) >>>> I'm not sure if clean-ruv is instant operations or there is some magic >>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>> should be there, but this needs investigation. >>>> >>>> + assert(replica.hostname in result2.stdout_text), ( >>>> + "The wrong RUV was deleted") >>>> + result3 = master.run_command(['ipa-replica-manage', >>>> 'list-ruv', >>>> + '-p', >>>> master.config.dirman_password]) >>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>> + "CA RUV of the replica is still displayed") >>>> >>> >>> Based on my discussion with Stanislav Laznicka, I understood that by >>> default clean-ruv does not return the shell until the operation is >>> finished. You can force dropping into the shell by pressing CTRL+C, in >>> which case the background job will still be running, but this is not >>> the default behavior >>> >> Test failed: >> result4 = master.run_command(['ipa-replica-manage', 'list-ruv', >> '-p', >> master.config.dirman_password]) >>> assert(replica.hostname not in result4.stdout_text), ( >> "replica's RUV is still displayed") >> E AssertionError: replica's RUV is still displayed >> E assert 'replica3.ipa.test' not in 'Replica Update >> V...ipa.test:389: 8\n' >> E 'replica3.ipa.test' is contained here: >> E Replica Update Vectors: >> E \tmaster.ipa.test:389: 4 >> E \treplica3.ipa.test:389: 3 >> E \treplica2.ipa.test:389: 7 >> E Certificate Server Replica Update Vectors: >> E \tmaster.ipa.test:389: 6 >> E \treplica2.ipa.test:389: 8 >> >> >> [root at master ~]# ipa topologysegment-find >> Suffix name: domain >> ------------------ >> 2 segments matched >> ------------------ >> Segment name: master.ipa.test-to-replica2.ipa.test >> Left node: master.ipa.test >> Right node: replica2.ipa.test >> Connectivity: both >> >> Segment name: master.ipa.test-to-replica3.ipa.test >> Left node: master.ipa.test >> Right node: replica3.ipa.test >> Connectivity: both >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> [root at master ~]# ipa-replica-manage list-ruv >> Directory Manager password: >> >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> replica3.ipa.test:389: 3 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> [root at master ~]# >> >> Then I tried manually to clean RUV 3, and it behaves somehow odd >> >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >> 'Secret123' '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> Background task created to clean replication data. This may take a >> while. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >> [root at master ~]# ipa-replica-manage list-ruv >> Directory Manager password: >> >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> replica3.ipa.test:389: 3 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >> 'Secret123' '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> CLEANALLRUV task for replica id 3 already exists. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> >> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >> No CLEANALLRUV tasks running >> >> No abort CLEANALLRUV tasks running >> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >> 'Secret123' '-f' >> Clean the Replication Update Vector for replica3.ipa.test:389 >> Background task created to clean replication data. This may take a >> while. >> This may be safely interrupted with Ctrl+C >> Cleanup task created >> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >> CLEANALLRUV tasks >> RID 3: Successfully cleaned rid(3). >> >> No abort CLEANALLRUV tasks running >> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >> Replica Update Vectors: >> master.ipa.test:389: 4 >> replica2.ipa.test:389: 7 >> Certificate Server Replica Update Vectors: >> master.ipa.test:389: 6 >> replica2.ipa.test:389: 8 >> >> >> I'm not sure if this behavior is right, Ludwig may know. > From dkupka at redhat.com Wed Oct 12 13:03:34 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 12 Oct 2016 15:03:34 +0200 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: <20161011142718.7hockhxitytbwgkh@redhat.com> References: <20161011135050.crkf25psdffdnws4@redhat.com> <4103ebfc-8319-0226-9567-e43bb7f36b02@redhat.com> <20161011142718.7hockhxitytbwgkh@redhat.com> Message-ID: <106abfa6-1b3c-ebff-4350-62076f5a1193@redhat.com> On 11/10/16 16:27, Alexander Bokovoy wrote: > On ti, 11 loka 2016, Petr Vobornik wrote: >> On 10/11/2016 03:50 PM, Alexander Bokovoy wrote: >>> On ti, 11 loka 2016, Petr Vobornik wrote: >>>> Hi List, >>>> >>>> we discussed locally a proposal about creating a feature branch for >>>> each >>>> sub-team effort in our main git. Currently it would be for the 4 >>>> ongoing >>>> refactoring efforts + Simo's work >>>> >>>> Why? >>>> It will allow each developer to create a pull request against the >>>> feature branch and thus it will enable iterative development by >>>> multiple >>>> devs without affecting other sub-teams. When the >>>> feature(refactoring) is >>>> finished, the branch would be rebased on master and merged there. Note: >>>> rebases can be done as needed - e.g. when other subteam finishes its >>>> work. >>>> >>>> Concerns: >>>> 1. Upstream git repo would be full of such branches. >>>> - This can be mitigated by deleting the feature branches when their are >>>> released or merged(up to discussion) >>> Don't put them in the upstream git repo. Let people decide where they >>> want to have them -- all Fedora contributors have access to >>> fedorapeople.org git hosting and there is github one button click >>> ('Clone') away from the github mirror. >>> >>> It is not a problem to keep a separate git branch published this way. >>> >> >> It is not a matter of making the code public. That can be done easily as >> you write. Other alternative is own branch in GitHub fork. >> >>> May be I misunderstand you -- if you just want people to propose merge >>> requests on github with pre-defined names, then that's just fine. >>> >> >> Basically it's all about review. >> >> Example use case: More than 1 devs are working on a same big effort. >> This effort will probably consists of 10s of commits. The big effort is >> divided into smaller ones which can be implemented and reviewed >> separately. In our previous mode, the sub task would be merged to master >> it is reviewed and ACKed. But now we cannot do that. We want to merge >> the whole big task at once when it is finishes and tested. >> >> One dev could probably have a branch on personal fork of FreeIPA on >> GitHub which would work as the feature branch. Other team members would >> create pull requests against it. >> >> In such case we would loose mail notifications and would have to extend >> our tooling because ipatool can use only one upstream on push. > So I still think this is not a problem. If people can agree which git > repo clone will be primary one and submit merge requests against it, > then there is no problem in having that git repo's branch to be > submitted as the pull request against the main git repo. This way you'll > get all the changes seen at the pull request sync time. > From my POV, when we create the refactoring branches in upstream we get this for free: * our minimal but convenient CI (lint + build on each PR) * mail notifications * tooling (ipatool pr-push XYZ -b refactoring-xyz just works) When creating them elsewhere we get: * confusion (no team-wide notifications, each effort in other fork) * manual rebasing and pushing So I think it's best to create the branches in upstream repo. I don't care about names and also I don't care what happens with them after the effort is done. -- David Kupka From abokovoy at redhat.com Wed Oct 12 13:21:35 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Oct 2016 16:21:35 +0300 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: <106abfa6-1b3c-ebff-4350-62076f5a1193@redhat.com> References: <20161011135050.crkf25psdffdnws4@redhat.com> <4103ebfc-8319-0226-9567-e43bb7f36b02@redhat.com> <20161011142718.7hockhxitytbwgkh@redhat.com> <106abfa6-1b3c-ebff-4350-62076f5a1193@redhat.com> Message-ID: <20161012132135.umlbdw2griucr23g@redhat.com> On ke, 12 loka 2016, David Kupka wrote: >On 11/10/16 16:27, Alexander Bokovoy wrote: >>On ti, 11 loka 2016, Petr Vobornik wrote: >>>On 10/11/2016 03:50 PM, Alexander Bokovoy wrote: >>>>On ti, 11 loka 2016, Petr Vobornik wrote: >>>>>Hi List, >>>>> >>>>>we discussed locally a proposal about creating a feature branch for >>>>>each >>>>>sub-team effort in our main git. Currently it would be for the 4 >>>>>ongoing >>>>>refactoring efforts + Simo's work >>>>> >>>>>Why? >>>>>It will allow each developer to create a pull request against the >>>>>feature branch and thus it will enable iterative development by >>>>>multiple >>>>>devs without affecting other sub-teams. When the >>>>>feature(refactoring) is >>>>>finished, the branch would be rebased on master and merged there. Note: >>>>>rebases can be done as needed - e.g. when other subteam finishes its >>>>>work. >>>>> >>>>>Concerns: >>>>>1. Upstream git repo would be full of such branches. >>>>>- This can be mitigated by deleting the feature branches when their are >>>>>released or merged(up to discussion) >>>>Don't put them in the upstream git repo. Let people decide where they >>>>want to have them -- all Fedora contributors have access to >>>>fedorapeople.org git hosting and there is github one button click >>>>('Clone') away from the github mirror. >>>> >>>>It is not a problem to keep a separate git branch published this way. >>>> >>> >>>It is not a matter of making the code public. That can be done easily as >>>you write. Other alternative is own branch in GitHub fork. >>> >>>>May be I misunderstand you -- if you just want people to propose merge >>>>requests on github with pre-defined names, then that's just fine. >>>> >>> >>>Basically it's all about review. >>> >>>Example use case: More than 1 devs are working on a same big effort. >>>This effort will probably consists of 10s of commits. The big effort is >>>divided into smaller ones which can be implemented and reviewed >>>separately. In our previous mode, the sub task would be merged to master >>>it is reviewed and ACKed. But now we cannot do that. We want to merge >>>the whole big task at once when it is finishes and tested. >>> >>>One dev could probably have a branch on personal fork of FreeIPA on >>>GitHub which would work as the feature branch. Other team members would >>>create pull requests against it. >>> >>>In such case we would loose mail notifications and would have to extend >>>our tooling because ipatool can use only one upstream on push. >>So I still think this is not a problem. If people can agree which git >>repo clone will be primary one and submit merge requests against it, >>then there is no problem in having that git repo's branch to be >>submitted as the pull request against the main git repo. This way you'll >>get all the changes seen at the pull request sync time. >> > >From my POV, when we create the refactoring branches in upstream we >get this for free: >* our minimal but convenient CI (lint + build on each PR) >* mail notifications >* tooling (ipatool pr-push XYZ -b refactoring-xyz just works) > >When creating them elsewhere we get: >* confusion (no team-wide notifications, each effort in other fork) >* manual rebasing and pushing This is rehashing of what Petr wrote already. And I understand the benefits of it. However, I don't like one part of the proposal: removing branches from upstream when feature is merged. This is heavily against accountability -- we should never remove anything from the primary git tree. Also, this churn of branches creates a lot of issues in terms of maintaining internal git datastore as you'll need to clean it from time to time. At this point I don't really see how benefits could outweigh the negatives in the longer term. Thousands of projects are working with separate git trees and do pull requests without negative of having to keep all the temporary feature branches in the main git tree. Why can't we? > >So I think it's best to create the branches in upstream repo. I don't >care about names and also I don't care what happens with them after >the effort is done. > >-- >David Kupka -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Wed Oct 12 13:22:33 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 12 Oct 2016 15:22:33 +0200 Subject: [Freeipa-devel] [freeipa PR#159][opened] spec file: clean up BuildRequires Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: opened PR body: """ Add missing cyrus-sasl-devel, python-cffi, python-custodia, python-nose, python-paste, python-sssdconfig and systemd-python BuildRequires. Remove unused custodia, java-headless, m4, policycoreutils, python-kdcproxy, python-rhsm, pyOpenSSL and systemd-units BuildRequires. Correct versioned BuildRequires and provide explanatory comments. **spec file: do not include BuildRequires for lint by default** Lint is never executed from rpmbuild, so the BuildRequires for lint are purely informational. Include them only if %with_lint RPM macro is specified. **pylint: enable the import-error check** Check for import errors with pylint to make sure new python package dependencies are not overlooked. **ipaserver: remove ipalib import from setup.py** Instead of importing ipalib to get IPA version string, create setup.py from a template and have the version string automatically filled in. This makes it possible to build the ipaserver package without having to have ipalib dependencies installed. **makeapi, makeaci: do not fail on missing imports** Add import hook to makeapi and makeaci which makes them ignore import errors in modules in our source tree and instead print a warning. This makes it possible to build IPA without having to have most of our runtime dependencies installed. **client: remove unused libcurl build dependency** **pwpolicy: do not run klist on import** On pwpolicy module import, "klist -V" is run to determine if the installed krb5 version supports account lockout (>= 1.8). Remove the check, as we require a krb5 version which does support account lockout (1.12). """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 45624 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 12 13:44:41 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Wed, 12 Oct 2016 15:44:41 +0200 Subject: [Freeipa-devel] [freeipa PR#157][synchronized] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Author: mzidek-rh Title: #157: git: Add commit template Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/157/head:pr157 git checkout pr157 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-157.patch Type: text/x-diff Size: 807 bytes Desc: not available URL: From dkupka at redhat.com Wed Oct 12 15:19:42 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 12 Oct 2016 17:19:42 +0200 Subject: [Freeipa-devel] Building refactoring branches in copr Message-ID: <4e6f54dd-849c-dd00-0eda-a992c0cf35c8@redhat.com> Hello everyone, as we already agreed we will have branches for our refactoring efforts somewhere and we will build them in copr so then can be easily consumed by CI and also everyone else willing to test them. I already put together simple script that pulls new patches makes srpm and submits it to copr build system. In order to avoid everyone else inventing the same wheel I can add all the refactoring branches, create copr repos and run the script with cron. If you would like me to take care about your refactoring branch just send me its location and consider it done. -- David Kupka From freeipa-github-notification at redhat.com Wed Oct 12 15:46:09 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 12 Oct 2016 17:46:09 +0200 Subject: [Freeipa-devel] [freeipa PR#156][comment] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Title: #156: cert: add revocation reason back to cert-find output pvomacka commented: """ I found one difference in output of cert-find command before and after this patch, it behaves differently only with --raw option. In output of the command without your commit there is following line: revoked: True . With your changes this line is missing. Tried using this command (the same behaviour is in API): ipa cert-find --user='test_user' --raw (--all) Would it be possible to keep there also this information? """ See the full comment at https://github.com/freeipa/freeipa/pull/156#issuecomment-253252364 From freeipa-github-notification at redhat.com Wed Oct 12 16:15:59 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Wed, 12 Oct 2016 18:15:59 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template mzidek-rh commented: """ Forgot to add a comment. I updated the patch according to jcholast's comments. """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-253261173 From freeipa-github-notification at redhat.com Wed Oct 12 16:19:52 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 12 Oct 2016 18:19:52 +0200 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap pvomacka commented: """ @redhatrises Thank you for the comment and the link. I agree that it would be really nice, but unfortunately there is no PatternFly package in Fedora. Anyway, I would be happy to do a review of a PatternFly package. """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-253262288 From freeipa-github-notification at redhat.com Wed Oct 12 16:56:47 2016 From: freeipa-github-notification at redhat.com (redhatrises) Date: Wed, 12 Oct 2016 18:56:47 +0200 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap redhatrises commented: """ > @redhatrises Thank you for the comment and the link. I agree that it would be really nice, but unfortunately there is no PatternFly package in Fedora. @pvomacka you're right. I should have checked. They do exist in the Patternfly Copr repos: https://copr.fedorainfracloud.org/coprs/patternfly/ Not sure if those can be used or a request needs to be made to include those RPMs into Fedora? """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-253272562 From freeipa-github-notification at redhat.com Wed Oct 12 17:12:46 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Wed, 12 Oct 2016 19:12:46 +0200 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap pvoborni commented: """ I don't think the patternfly package can be included in Fedora as is. It internally bundles several packages, some of them already packaged (jquery, fontawesome-fonts, OpenSans-fonts). Additionally tha package puts files on non-standard place. Some info about Fedora packaging: * https://fedoraproject.org/wiki/Packaging:JavaScript * https://fedoraproject.org/wiki/Packaging:Web_Assets """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-253276778 From pspacek at redhat.com Wed Oct 12 17:56:24 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Oct 2016 19:56:24 +0200 Subject: [Freeipa-devel] links to docs in the messages from code Message-ID: Hello FreeIPA developers, looking at freeipa-users mailing list, a lot of questions could be answered by just quick glance to the docs. I wonder if we should add links HTML version of docs on access.redhat.com to the messages generated by the code. If we really want, we can make these platform-specific, but I would not even bother with it. Fedora & CentOS & RHEL users end up on the very same page, only the way how then find it is different (mailing list vs. Google vs. paid support). Examples: a) Installation without DNS could end up with message like this: Do not forget to finish post-installation steps listed on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-dns b) Failed connection check could print link to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports c) Failed DNS check could mention link https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs d) Failed attempt to find AD DC could print a link to: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings etc. What do you think about this? -- Petr^2 Spacek From pspacek at redhat.com Wed Oct 12 18:15:22 2016 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Oct 2016 20:15:22 +0200 Subject: [Freeipa-devel] Heimdal Kerberos support for client Message-ID: <6d24638e-8198-4e00-22df-bf1bacc5288f@redhat.com> Hello list, I just noticed that client/configure.ac contains some checks to detect and support Heimdal Kerberos libraries. Was it tested? Does it work? Can I drop it? :-) -- Petr^2 Spacek From rcritten at redhat.com Wed Oct 12 18:22:37 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Oct 2016 14:22:37 -0400 Subject: [Freeipa-devel] Heimdal Kerberos support for client In-Reply-To: <6d24638e-8198-4e00-22df-bf1bacc5288f@redhat.com> References: <6d24638e-8198-4e00-22df-bf1bacc5288f@redhat.com> Message-ID: <57FE7F6D.8070902@redhat.com> Petr Spacek wrote: > Hello list, > > I just noticed that client/configure.ac contains some checks to detect and > support Heimdal Kerberos libraries. > > Was it tested? Does it work? Can I drop it? :-) > Wow, that's some old code. Only Simo would know if it was ever tested or ever worked. I suppose since theoretically the client can be built separately theoretically it might do the right thing in some cases. Seems like enough of a corner case to me that I'd remove it, given it is likely untested these last 9 years or so. I'll give Simo the final say though. rob From bind-dyndb-ldap-github-notification at redhat.com Thu Oct 13 02:42:42 2016 From: bind-dyndb-ldap-github-notification at redhat.com (stutiredboy) Date: Thu, 13 Oct 2016 04:42:42 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][opened] fix ldif syntax and add idnsTemplateAttribute Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Author: stutiredboy Title: #2: fix ldif syntax and add idnsTemplateAttribute Action: opened PR body: """ schema.ldif lost some white space in the line end. schema.ldif lost the idnsTemplateAttribute definitition """ To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/2/head:pr2 git checkout pr2 -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pr-2.patch Type: text/x-diff Size: 2077 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 13 05:51:04 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 13 Oct 2016 07:51:04 +0200 Subject: [Freeipa-devel] [freeipa PR#156][comment] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Title: #156: cert: add revocation reason back to cert-find output jcholast commented: """ It's intentional. With `--raw`, only data retrieved directly from the backend should be returned. `cert-show` does the same. I should have mentioned it in the commit message though... """ See the full comment at https://github.com/freeipa/freeipa/pull/156#issuecomment-253420497 From freeipa-github-notification at redhat.com Thu Oct 13 05:53:16 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 13 Oct 2016 07:53:16 +0200 Subject: [Freeipa-devel] [freeipa PR#156][synchronized] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Author: jcholast Title: #156: cert: add revocation reason back to cert-find output Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/156/head:pr156 git checkout pr156 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-156.patch Type: text/x-diff Size: 2038 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 13 06:48:38 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Thu, 13 Oct 2016 08:48:38 +0200 Subject: [Freeipa-devel] [freeipa PR#160][opened] Reverted the essertion for replica uninstall returncode Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Author: ofayans Title: #160: Reverted the essertion for replica uninstall returncode Action: opened PR body: """ As the issue with ipa installer always returning 0 returncode is apparently addressed, the test needs to be made aware of this change. https://fedorahosted.org/freeipa/ticket/3230 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/160/head:pr160 git checkout pr160 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-160.patch Type: text/x-diff Size: 1719 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 13 06:54:25 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Oct 2016 08:54:25 +0200 Subject: [Freeipa-devel] links to docs in the messages from code In-Reply-To: References: Message-ID: On 12.10.2016 19:56, Petr Spacek wrote: > Hello FreeIPA developers, > > looking at freeipa-users mailing list, a lot of questions could be answered by > just quick glance to the docs. > > I wonder if we should add links HTML version of docs on access.redhat.com to > the messages generated by the code. > > If we really want, we can make these platform-specific, but I would not even > bother with it. Fedora & CentOS & RHEL users end up on the very same page, > only the way how then find it is different (mailing list vs. Google vs. paid > support). > > > Examples: > > a) Installation without DNS could end up with message like this: > Do not forget to finish post-installation steps listed on > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-dns > > > b) Failed connection check could print link to > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports > > > c) Failed DNS check could mention link > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs > > > d) Failed attempt to find AD DC could print a link to: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings > > etc. > > What do you think about this? > I'm afraid that those links can change over time, so we have to check them regularly otherwise we may end up with links pointing to nowhere. I'm not excited too much with this idea. Martin^2 From bind-dyndb-ldap-github-notification at redhat.com Thu Oct 13 07:00:20 2016 From: bind-dyndb-ldap-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 09:00:20 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][comment] fix ldif syntax and add idnsTemplateAttribute In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Title: #2: fix ldif syntax and add idnsTemplateAttribute mbasti-rh commented: """ Hello, I wrote inline comments. Please set proper author name in commit (no root please) """ See the full comment at https://github.com/freeipa/bind-dyndb-ldap/pull/2#issuecomment-253430426 From bind-dyndb-ldap-github-notification at redhat.com Thu Oct 13 07:03:23 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Thu, 13 Oct 2016 09:03:23 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][comment] fix ldif syntax and add idnsTemplateAttribute In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Title: #2: fix ldif syntax and add idnsTemplateAttribute pspacek commented: """ @mbasti-rh , the white-space at the end of line is required here because the first space at the beginning of line will be consumed by LDIF parser. I agree that root should not be author of the commit :-) """ See the full comment at https://github.com/freeipa/bind-dyndb-ldap/pull/2#issuecomment-253430924 From freeipa-github-notification at redhat.com Thu Oct 13 07:08:48 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 13 Oct 2016 09:08:48 +0200 Subject: [Freeipa-devel] [freeipa PR#160][comment] Reverted the essertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Title: #160: Reverted the essertion for replica uninstall returncode martbab commented: """ Please mention either git commit (f7764cda6824a2fe73abe11f6daa28758a185319) that fixed this behavior, or put the link to closed ticket (https://fedorahosted.org/freeipa/ticket/5725) that addressed this. Everything is recorded in our git history and/or tracking system, so 'apparently addressed' really has no place in our commit messages. """ See the full comment at https://github.com/freeipa/freeipa/pull/160#issuecomment-253432003 From pspacek at redhat.com Thu Oct 13 07:10:59 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Oct 2016 09:10:59 +0200 Subject: [Freeipa-devel] links to docs in the messages from code In-Reply-To: References: Message-ID: <064db796-6171-dabd-2cc6-c95a94813303@redhat.com> On 13.10.2016 08:54, Martin Basti wrote: > > > On 12.10.2016 19:56, Petr Spacek wrote: >> Hello FreeIPA developers, >> >> looking at freeipa-users mailing list, a lot of questions could be answered by >> just quick glance to the docs. >> >> I wonder if we should add links HTML version of docs on access.redhat.com to >> the messages generated by the code. >> >> If we really want, we can make these platform-specific, but I would not even >> bother with it. Fedora & CentOS & RHEL users end up on the very same page, >> only the way how then find it is different (mailing list vs. Google vs. paid >> support). >> >> >> Examples: >> >> a) Installation without DNS could end up with message like this: >> Do not forget to finish post-installation steps listed on >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-dns >> >> >> >> b) Failed connection check could print link to >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports >> >> >> >> c) Failed DNS check could mention link >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs >> >> >> >> d) Failed attempt to find AD DC could print a link to: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings >> >> >> etc. >> >> What do you think about this? >> > > I'm afraid that those links can change over time, so we have to check them > regularly otherwise we may end up with links pointing to nowhere. This check can be easily automated. AFAIK docs team already have tools like this. > I'm not excited too much with this idea. Okay then. I'm open to any other idea to alleviate the problem with ever-repeating questions on the freeipa-users list. Do you have one? -- Petr^2 Spacek From pvomacka at redhat.com Thu Oct 13 07:11:02 2016 From: pvomacka at redhat.com (Pavel Vomacka) Date: Thu, 13 Oct 2016 09:11:02 +0200 Subject: [Freeipa-devel] links to docs in the messages from code In-Reply-To: References: Message-ID: <2d882b63-c4ba-bbb5-c77b-74fd8f428990@redhat.com> On 10/13/2016 08:54 AM, Martin Basti wrote: > > > On 12.10.2016 19:56, Petr Spacek wrote: >> Hello FreeIPA developers, >> >> looking at freeipa-users mailing list, a lot of questions could be >> answered by >> just quick glance to the docs. >> >> I wonder if we should add links HTML version of docs on >> access.redhat.com to >> the messages generated by the code. >> >> If we really want, we can make these platform-specific, but I would >> not even >> bother with it. Fedora & CentOS & RHEL users end up on the very same >> page, >> only the way how then find it is different (mailing list vs. Google >> vs. paid >> support). >> >> >> Examples: >> >> a) Installation without DNS could end up with message like this: >> Do not forget to finish post-installation steps listed on >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-server.html#install-server-without-dns >> >> >> >> b) Failed connection check could print link to >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#prereq-ports >> >> >> >> c) Failed DNS check could mention link >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs >> >> >> >> d) Failed attempt to find AD DC could print a link to: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-requirements.html#dns-realm-settings >> >> >> etc. >> >> What do you think about this? >> > > I'm afraid that those links can change over time, so we have to check > them regularly otherwise we may end up with links pointing to nowhere. > I'm not excited too much with this idea. > > Martin^2 > I think that we probably could check these link automatically, the only thing which would be necessary is to store these links in some format which can be easily parsed. We could use the Emender and modify its TestLinks [1]. This test now consume .xml files, but it should not be hard to change it to different format. [1] https://github.com/emender/emender-fedora/blob/master/test/TestLinks.lua -- Pavel^3 Vomacka From freeipa-github-notification at redhat.com Thu Oct 13 07:57:55 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Thu, 13 Oct 2016 09:57:55 +0200 Subject: [Freeipa-devel] [freeipa PR#156][comment] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Title: #156: cert: add revocation reason back to cert-find output pvomacka commented: """ Ah, OK, then it works correctly. ACK """ See the full comment at https://github.com/freeipa/freeipa/pull/156#issuecomment-253441752 From freeipa-github-notification at redhat.com Thu Oct 13 07:58:01 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Thu, 13 Oct 2016 09:58:01 +0200 Subject: [Freeipa-devel] [freeipa PR#156][+ack] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Title: #156: cert: add revocation reason back to cert-find output Label: +ack From freeipa-github-notification at redhat.com Thu Oct 13 08:17:24 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 13 Oct 2016 10:17:24 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ Interestingly, the CI failed with following errors: ************* Module ipatests.test_xmlrpc.test_automount_plugin ipatests/test_xmlrpc/test_automount_plugin.py:34: [E0401(import-error), ] Unable to import 'nose.tools') ************* Module ipatests.test_xmlrpc.test_hbactest_plugin ipatests/test_xmlrpc/test_hbactest_plugin.py:27: [E0401(import-error), ] Unable to import 'nose.tools') ************* Module ipatests.test_xmlrpc.test_pwpolicy_plugin ipatests/test_xmlrpc/test_pwpolicy_plugin.py:24: [E0401(import-error), ] Unable to import 'nose.tools') ************* Module ipatests.test_xmlrpc.test_external_members ipatests/test_xmlrpc/test_external_members.py:24: [E0401(import-error), ] Unable to import 'nose') ************* Module lite-server lite-server.py:36: [E0401(import-error), ] Unable to import 'paste') lite-server.py:37: [E0401(import-error), ] Unable to import 'paste.gzipper') lite-server.py:38: [E0401(import-error), ] Unable to import 'paste.urlmap') ************* Module ipa-ods-exporter daemons/dnssec/ipa-ods-exporter:29: [E0401(import-error), ] Unable to import 'systemd.daemon') daemons/dnssec/ipa-ods-exporter:30: [E0401(import-error), ] Unable to import 'systemd.journal') Weren't you to eager in pruning BuildRequires? :-) """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-253445874 From freeipa-github-notification at redhat.com Thu Oct 13 08:46:29 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Thu, 13 Oct 2016 10:46:29 +0200 Subject: [Freeipa-devel] [freeipa PR#160][synchronized] Reverted the essertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Author: ofayans Title: #160: Reverted the essertion for replica uninstall returncode Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/160/head:pr160 git checkout pr160 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-160.patch Type: text/x-diff Size: 1709 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 13 08:49:48 2016 From: freeipa-github-notification at redhat.com (ofayans) Date: Thu, 13 Oct 2016 10:49:48 +0200 Subject: [Freeipa-devel] [freeipa PR#160][comment] Reverted the essertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Title: #160: Reverted the essertion for replica uninstall returncode ofayans commented: """ Fair point. Fixed. Should we also update the initial (3230) issue? """ See the full comment at https://github.com/freeipa/freeipa/pull/160#issuecomment-253453106 From bind-dyndb-ldap-github-notification at redhat.com Thu Oct 13 09:07:56 2016 From: bind-dyndb-ldap-github-notification at redhat.com (stutiredboy) Date: Thu, 13 Oct 2016 11:07:56 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][synchronized] fix ldif syntax and add idnsTemplateAttribute In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Author: stutiredboy Title: #2: fix ldif syntax and add idnsTemplateAttribute Action: synchronized To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/2/head:pr2 git checkout pr2 -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pr-2.patch Type: text/x-diff Size: 1296 bytes Desc: not available URL: From bind-dyndb-ldap-github-notification at redhat.com Thu Oct 13 09:11:52 2016 From: bind-dyndb-ldap-github-notification at redhat.com (stutiredboy) Date: Thu, 13 Oct 2016 11:11:52 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][comment] fix ldif syntax and add idnsTemplateAttribute In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Title: #2: fix ldif syntax and add idnsTemplateAttribute stutiredboy commented: """ so sorry for the root committer, but the white space is needed by OpenLDAP LDIF parser. I have fixed the ugly pull request. :-) Thanks. """ See the full comment at https://github.com/freeipa/bind-dyndb-ldap/pull/2#issuecomment-253458793 From freeipa-github-notification at redhat.com Thu Oct 13 10:19:55 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 13 Oct 2016 12:19:55 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 46119 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 13 10:53:22 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 13 Oct 2016 12:53:22 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 46134 bytes Desc: not available URL: From sbose at redhat.com Thu Oct 13 11:01:47 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 13 Oct 2016 13:01:47 +0200 Subject: [Freeipa-devel] FleetCommander integration In-Reply-To: <20160906101814.aotuinw5y4v6ihzk@redhat.com> References: <20160906101814.aotuinw5y4v6ihzk@redhat.com> Message-ID: <20161013110147.GF4864@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Sep 06, 2016 at 01:18:14PM +0300, Alexander Bokovoy wrote: > Hi, > > Now that FreeIPA 4.4.1 is out, I've pushed to github my prototype for > FleetCommander integration: https://github.com/abbra/freeipa-desktop-profile/ > > You can read the design page: > https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki Hi Alexander, if I understand it correctly each profile has a priority which is used by FleetCommander on the client side to order the different profiles if for a given user and host multiple rules matches. To make this work smoothly each priority value should be only assigned once to avoid a tie. Are you planning to use the uniqueness plugin on the priority value or are there other ways to solve ties reliable in FleetCommander? bye, Sumit > > The design was mostly figured out in discussions with Alberto, Fabiano, > Nathaniel, and Jakub, so we are more or less on the common ground here > between SSSD and FleetCommander. You can send pull requests to me on > github to update the design. ;) > > You can cut a tarball using > git archive --format=tar.gz --prefix=freeipa-desktop-profile-0.0.1/ \ > --output ~/rpmbuild/SOURCES/freeipa-desktop-profile-0.0.1.tar.gz \ > freeipa-desktop-profile-0.0.1 > > And then build the package with > rpmbuild -ta freeipa-desktop-profile-0.0.1.tar.gz > > When installed, the package does not run ipa-server-upgrade by itself, > yet. So you need to run ipa-server-upgrade manually. Once ran, > deskprofile/deskprofilerule topics would become available and can be > used for testing purposes. For Fedora 24 one can use FreeIPA 4.4.1 from > COPR, for Fedora 25 we have FreeIPA 4.4.1 in updates stable as of today. > > UI plugin is not ready yet and is disabled in the spec file as it breaks > loading the whole UI. > > -- > / 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 From freeipa-github-notification at redhat.com Thu Oct 13 11:09:08 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 13:09:08 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires mbasti-rh commented: """ Please update BUILD.txt with how to run pylint with build, probably freeipa.org should be updated as well """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-253483810 From freeipa-github-notification at redhat.com Thu Oct 13 11:10:32 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 13 Oct 2016 13:10:32 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 46136 bytes Desc: not available URL: From abokovoy at redhat.com Thu Oct 13 11:12:50 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Oct 2016 14:12:50 +0300 Subject: [Freeipa-devel] FleetCommander integration In-Reply-To: <20161013110147.GF4864@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20160906101814.aotuinw5y4v6ihzk@redhat.com> <20161013110147.GF4864@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20161013111250.dy435mfsmv65f3gt@redhat.com> On to, 13 loka 2016, Sumit Bose wrote: >On Tue, Sep 06, 2016 at 01:18:14PM +0300, Alexander Bokovoy wrote: >> Hi, >> >> Now that FreeIPA 4.4.1 is out, I've pushed to github my prototype for >> FleetCommander integration: https://github.com/abbra/freeipa-desktop-profile/ >> >> You can read the design page: >> https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki > >Hi Alexander, > >if I understand it correctly each profile has a priority which is used >by FleetCommander on the client side to order the different profiles if >for a given user and host multiple rules matches. > >To make this work smoothly each priority value should be only assigned >once to avoid a tie. Are you planning to use the uniqueness plugin on >the priority value or are there other ways to solve ties reliable in >FleetCommander? I'm not planning to make priorities unique. Do we really need that? My idea was to make sure we provide clear sorting logic: ---------------- profilename.json file name is built using profile RDN and is prefixed by the priority of the profile rule using leading zeros. To ease handling of the files, SSSD may transform RDN value by removing certain characters used by the shell for globing purposes and by replacing spaces with underscores. Since the name of the file is only used to ensure ordering of the profiles when merging them, a lexicographical sort of names should be enough. .... Example: For a profile rule 'Minimal Desktop For Guests' stored as cn=Minimal desktop for guests,cn=rules,cn=desktop-profile,$SUFFIX with a priority 100, SSSD would use a file name '000100_Minimal_desktop_for_guests.json'. ---------------- Given that you would not be able to have exact same RDN value in two different profiles, using lexicographical sort gives you explicit ordering schema. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Thu Oct 13 11:20:54 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 13:20:54 +0200 Subject: [Freeipa-devel] [freeipa PR#160][edited] Reverted the assertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Author: ofayans Title: #160: Reverted the assertion for replica uninstall returncode Action: edited Changed field: title Original value: """ Reverted the essertion for replica uninstall returncode """ From freeipa-github-notification at redhat.com Thu Oct 13 11:28:55 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 13 Oct 2016 13:28:55 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 46555 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 13 11:31:36 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 13:31:36 +0200 Subject: [Freeipa-devel] [freeipa PR#127][comment] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension mbasti-rh commented: """ Hello @tjaalton, I cannot apply second commit, it needs rebase. """ See the full comment at https://github.com/freeipa/freeipa/pull/127#issuecomment-253487937 From freeipa-github-notification at redhat.com Thu Oct 13 11:45:10 2016 From: freeipa-github-notification at redhat.com (tjaalton) Date: Thu, 13 Oct 2016 13:45:10 +0200 Subject: [Freeipa-devel] [freeipa PR#127][synchronized] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Author: tjaalton Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/127/head:pr127 git checkout pr127 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-127.patch Type: text/x-diff Size: 29417 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 13 11:49:45 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 13 Oct 2016 13:49:45 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires jcholast commented: """ @pspacek, @mbasti-rh, fixed. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-253491282 From freeipa-github-notification at redhat.com Thu Oct 13 11:52:45 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 13:52:45 +0200 Subject: [Freeipa-devel] [freeipa PR#126][comment] Fix ipa migrate-ds when it finds a search reference In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/126 Title: #126: Fix ipa migrate-ds when it finds a search reference mbasti-rh commented: """ Hello, LGTM but PR needs rebase """ See the full comment at https://github.com/freeipa/freeipa/pull/126#issuecomment-253491876 From ofayans at redhat.com Thu Oct 13 12:01:52 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 13 Oct 2016 14:01:52 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> Message-ID: Hi Martin, Thanks for the review. With disabling directory server it works as well, thanks for the hint. Also I moved the cleanup logic to the test itself for the sake of simplicity. Patch-0048 was not changed On 10/12/2016 02:35 PM, Martin Basti wrote: > 1) > > Can you just turn off dirsrv on replica instead of doing iptables magic? > > > 2) NACK > > No more eval() ever in code, use 'getattr', 'get' or whatever in the > object that can be used. > > + evalhost = eval("args[0].%s" % host) > > Martin^2 > > On 12.10.2016 14:03, Oleg Fayans wrote: >> Hi Martin, >> >> After extensive discussion with Ludwig, I finally got the clue on how >> does this feature work. When we uninstall the replica, the master >> cleans the replication agreements with this replica and automatically >> cleans all replica's RUVs. >> If we clean replica's RUVs on master without uninstalling the replica, >> the replica's RUVs get recreated on master (replication works!). So, >> the only way to test the clean-ruv subcommand is to turn off the >> replica, or block the traffic on it so it gets inaccessible to updates >> from master. >> The testcases were updated, see [1] and [2] >> >> The updated versions of the patches are attached >> >> [1] >> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs >> >> >> [2] >> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand >> >> >> On 08/05/2016 06:36 PM, Martin Basti wrote: >>> >>> >>> On 03.08.2016 14:45, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review! Both patches were updated. >>>> >>>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thanks for the review! >>>>>> >>>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>>> before >>>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>>> feature. >>>>>>>> >>>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>>> One more test was added to the patch-0048 >>>>>>>>> >>>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>>> from >>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> IIUC, this will turn off the machine completely, how is cleanup done >>>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>>> cleanup, so >>>>>>> you will not be able to run more tests on the same topology without >>>>>>> manual cleanup and manual start. >>>>>>> >>>>>>> + replica = self.replicas[0] >>>>>>> + replica.run_command(['poweroff']) >>>>>>> >>>>>>> IMO would be better to just call 'ipactl stop' instead of 'poweroff' >>>>>> >>>>>> Agreed! Fixed. >>>>>> >>>>>>> >>>>>>> Martin^2 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> *Automated ipa-replica-manage del tests* >>>>> >>>>> 1) >>>>> + replica.run_command(['ipactl', 'stop']) >>>>> + time.sleep(3) >>>>> >>>>> Why do you need sleep here? >>>> >>>> Removed, it was left from the old "poweroff" approach >>>> >>>>> >>>>> >>>>> 2) >>>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % replica.hostname) >>>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>>> + '-p', master.config.dirman_password, >>>>> + replica_ruvs[0]]) >>>>> >>>>> Because you are using re.findall(), without any match you will receive >>>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>>> >>>> Implemented the assert which checks that the output contains enough >>>> replica RUVs >>>> >>>>> >>>>> 3) >>>>> assert(replica.hostname in result1.stdout_text) >>>>> >>>>> I think that this is error prone. What if there is just error >>>>> 'could not >>>>> connect to replica ', or something similar. >>>>> instead of >>>>> listing/cleaning/whatever operation was executed. I think that it >>>>> should >>>>> be more specific regexp than just finding a replica name substring >>>>> (Yes >>>>> In IPA we dont always print error so stderr) >>>>> >>>>> I'm not sure, but probably there might be cases when non critical >>>>> error >>>>> happen and exist status is still 0 >>>> >>>> Agree. Implemented a regex-based search >>>> >>>>> >>>>> 4) >>>>> >>>>> + replica.run_command(['poweroff']) >>>>> + time.sleep(3) >>>>> >>>>> There should not be poweroff, probably sleep could be removed too. >>>> >>>> Gone >>>> >>>>> >>>>> >>>>> * Automated clean-ruv subcommand test* >>>>> >>>>> 1) PEP8, 2 new lines expected >>>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>>> blank lines, found 0 >>>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>>> long >>>>> (85 > 79 characters) >>>> >>>> Fixed >>>> >>>>> >>>>> >>>>> 2) >>>>> I dont like doing assert just with count of occurences of substring in >>>>> STDOUT, would be possible to improve this somehow? >>>> >>>> Maybe, but frankly, I don't see how. In this case we are making sure >>>> that both simple and CA-specific RUVs of a replica are displayed. The >>>> format of the output is strict: >>>> Replica Update Vectors: >>>> replica1_hostname:389: RUV_id >>>> replica2_hostname:389: RUV_id >>>> Certificate Server Replica Update Vectors: >>>> replica1_hostname:389: RUV_id >>>> replica2_hostname:389: RUV_id >>>> If we do not see 2 occurrences of the replica hostname than definitely >>>> something went wrong >>>> >>>>> >>>>> 3) >>>>> I'm not sure if clean-ruv is instant operations or there is some magic >>>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>>> should be there, but this needs investigation. >>>>> >>>>> + assert(replica.hostname in result2.stdout_text), ( >>>>> + "The wrong RUV was deleted") >>>>> + result3 = master.run_command(['ipa-replica-manage', >>>>> 'list-ruv', >>>>> + '-p', >>>>> master.config.dirman_password]) >>>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>>> + "CA RUV of the replica is still displayed") >>>>> >>>> >>>> Based on my discussion with Stanislav Laznicka, I understood that by >>>> default clean-ruv does not return the shell until the operation is >>>> finished. You can force dropping into the shell by pressing CTRL+C, in >>>> which case the background job will still be running, but this is not >>>> the default behavior >>>> >>> Test failed: >>> result4 = master.run_command(['ipa-replica-manage', 'list-ruv', >>> '-p', >>> master.config.dirman_password]) >>>> assert(replica.hostname not in result4.stdout_text), ( >>> "replica's RUV is still displayed") >>> E AssertionError: replica's RUV is still displayed >>> E assert 'replica3.ipa.test' not in 'Replica Update >>> V...ipa.test:389: 8\n' >>> E 'replica3.ipa.test' is contained here: >>> E Replica Update Vectors: >>> E \tmaster.ipa.test:389: 4 >>> E \treplica3.ipa.test:389: 3 >>> E \treplica2.ipa.test:389: 7 >>> E Certificate Server Replica Update Vectors: >>> E \tmaster.ipa.test:389: 6 >>> E \treplica2.ipa.test:389: 8 >>> >>> >>> [root at master ~]# ipa topologysegment-find >>> Suffix name: domain >>> ------------------ >>> 2 segments matched >>> ------------------ >>> Segment name: master.ipa.test-to-replica2.ipa.test >>> Left node: master.ipa.test >>> Right node: replica2.ipa.test >>> Connectivity: both >>> >>> Segment name: master.ipa.test-to-replica3.ipa.test >>> Left node: master.ipa.test >>> Right node: replica3.ipa.test >>> Connectivity: both >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >>> [root at master ~]# ipa-replica-manage list-ruv >>> Directory Manager password: >>> >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> replica3.ipa.test:389: 3 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> [root at master ~]# >>> >>> Then I tried manually to clean RUV 3, and it behaves somehow odd >>> >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>> 'Secret123' '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> Background task created to clean replication data. This may take a >>> while. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >>> [root at master ~]# ipa-replica-manage list-ruv >>> Directory Manager password: >>> >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> replica3.ipa.test:389: 3 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>> 'Secret123' '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> CLEANALLRUV task for replica id 3 already exists. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> >>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>> No CLEANALLRUV tasks running >>> >>> No abort CLEANALLRUV tasks running >>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>> 'Secret123' '-f' >>> Clean the Replication Update Vector for replica3.ipa.test:389 >>> Background task created to clean replication data. This may take a >>> while. >>> This may be safely interrupted with Ctrl+C >>> Cleanup task created >>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>> CLEANALLRUV tasks >>> RID 3: Successfully cleaned rid(3). >>> >>> No abort CLEANALLRUV tasks running >>> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >>> Replica Update Vectors: >>> master.ipa.test:389: 4 >>> replica2.ipa.test:389: 7 >>> Certificate Server Replica Update Vectors: >>> master.ipa.test:389: 6 >>> replica2.ipa.test:389: 8 >>> >>> >>> I'm not sure if this behavior is right, Ludwig may know. >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0047.4-Automated-clean-ruv-subcommand-tests.patch Type: text/x-patch Size: 5671 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 13 15:18:10 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 17:18:10 +0200 Subject: [Freeipa-devel] [freeipa PR#161][opened] CI: workaround: wait for dogtag before replica-prepare Message-ID: URL: https://github.com/freeipa/freeipa/pull/161 Author: mbasti-rh Title: #161: CI: workaround: wait for dogtag before replica-prepare Action: opened PR body: """ In domain level 0 ipa-replica-prepare fails because dogtag is not ready so soon after final restart during installation (tests are too fast). Wait 30 seconds before ipa-replica-prepare is executed, to make sure that dogtag is ready. Remove this workaround when ticket is fixed. https://fedorahosted.org/freeipa/ticket/6274 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/161/head:pr161 git checkout pr161 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-161.patch Type: text/x-diff Size: 1271 bytes Desc: not available URL: From blipton at redhat.com Thu Oct 13 15:23:03 2016 From: blipton at redhat.com (Ben Lipton) Date: Thu, 13 Oct 2016 11:23:03 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: <82017bee-a989-cbe5-d5ed-f481441269e6@redhat.com> References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> <57BF50E1.8030209@redhat.com> <82017bee-a989-cbe5-d5ed-f481441269e6@redhat.com> Message-ID: Thank you, this was a really helpful clarification of your point. Comments below. Once again, I'm sorry I missed the email for so long. Ben On 09/05/2016 06:52 AM, Jan Cholasta wrote: > On 27.8.2016 22:40, Ben Lipton wrote: >> On 08/25/2016 04:11 PM, Rob Crittenden wrote: >>> Ben Lipton wrote: >>>> On 08/23/2016 03:54 AM, Jan Cholasta wrote: >>>>> On 8.8.2016 22:23, Ben Lipton wrote: >>>>>> On 07/25/2016 07:45 AM, Jan Cholasta wrote: >>>>>>> On 25.7.2016 13:11, Alexander Bokovoy wrote: >>>>>>>> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>>>>>> On 20.7.2016 16:05, Ben Lipton wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Thanks very much for the feedback! Some responses below; I hope >>>>>>>>>> you'll >>>>>>>>>> let me know what you think of my reasoning. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>>>>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>>>>>>>> Hello all, >>>>>>>>>>>>> >>>>>>>>>>>>> I have written up a design proposal for making certificate >>>>>>>>>>>>> requests >>>>>>>>>>>>> easier to generate when using alternate certificate profiles: >>>>>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The use case for this is described in >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be >>>>>>>>>>>>> working on >>>>>>>>>>>>> implementing this design over the next couple of months. >>>>>>>>>>>>> If you >>>>>>>>>>>>> have >>>>>>>>>>>>> the time and interest, please take a look and share any >>>>>>>>>>>>> comments or >>>>>>>>>>>>> concerns that you have. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> Ben >>>>>>>>>>>>> >>>>>>>>>>>> Just a quick update to say that I've created a new document >>>>>>>>>>>> that >>>>>>>>>>>> covers >>>>>>>>>>>> the proposed schema additions in a more descriptive way (with >>>>>>>>>>>> diagrams!) >>>>>>>>>>>> I'm very new to developing with LDAP, so some more experienced >>>>>>>>>>>> eyes on >>>>>>>>>>>> the proposal would be very helpful, even if you don't have >>>>>>>>>>>> time to >>>>>>>>>>>> absorb the full design. Please take a look at >>>>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> if you have a chance. >>>>>>>>>>> >>>>>>>>>>> I finally had a chance to take a look at this, here are some >>>>>>>>>>> comments: >>>>>>>>>>> >>>>>>>>>>> 1) I don't like how transformation rules are tied to a >>>>>>>>>>> particular >>>>>>>>>>> helper and have to be duplicated for each of them. They >>>>>>>>>>> should be >>>>>>>>>>> generic and work with any helper, as helpers are just an >>>>>>>>>>> implementation detail and their resulting data is the same. >>>>>>>>>>> >>>>>>>>>>> In fact, I think I would prefer if the CSR was generated using >>>>>>>>>>> python-cryptography's CertificateSigningRequestBuilder [1] >>>>>>>>>>> rather >>>>>>>>>>> than >>>>>>>>>>> openssl or certutil or any other command line tool. >>>>>>>>>>> >>>>>>>>>> There are lots of tools that users might want to use to manage >>>>>>>>>> their >>>>>>>>>> private keys, so I don't know if we can assume that whatever >>>>>>>>>> library we >>>>>>>>>> prefer will actually be able to access the private key to sign a >>>>>>>>>> CSR, >>>>>>>>>> which is why I thought it would be useful to support more than >>>>>>>>>> one. >>>>>>>>> >>>>>>>>> python-cryptography has the notion of backends, which allow it to >>>>>>>>> support multiple crypto implementations. Upstream it currently >>>>>>>>> supports only OpenSSL [2], but some work has been done on PKCS#11 >>>>>>>>> backend [3], which provides support for HSMs and soft-tokens >>>>>>>>> (like >>>>>>>>> NSS >>>>>>>>> databases). >>>>>>>>> >>>>>>>>> Alternatively, for NSS databases (and other "simple" cases), you >>>>>>>>> can >>>>>>>>> generate the private key with python-cryptography using the >>>>>>>>> default >>>>>>>>> backend, export it to a file and import the file to the target >>>>>>>>> database, so you don't actually need the PKCS#11 backend for >>>>>>>>> them. >>>>>>>>> >>>>>>>>> So, the only thing that's currently lacking is HSM support, but >>>>>>>>> given >>>>>>>>> that we don't support HSMs in IPA nor in certmonger, I don't >>>>>>>>> think >>>>>>>>> it's an issue for now. >>>>>>>>> >>>>>>>>>> The >>>>>>>>>> purpose of the mapping rule is to tie together the >>>>>>>>>> transformation >>>>>>>>>> rules >>>>>>>>>> that produce the same data into an object that's >>>>>>>>>> implementation-agnostic, so that profiles referencing those >>>>>>>>>> rules >>>>>>>>>> are >>>>>>>>>> automatically compatible with all the helper options. >>>>>>>>> >>>>>>>>> They are implementation-agnostic, as long as you consider >>>>>>>>> `openssl` >>>>>>>>> and `certutil` the only implementations :-) But I don't think >>>>>>>>> this >>>>>>>>> solution scales well to other possible implementations. >>>>>>>>> >>>>>>>>> Anyway, my main grudge is that the transformation rules shouldn't >>>>>>>>> really be stored on and processed by the server. The server >>>>>>>>> should >>>>>>>>> know the *what* (mapping rules), but not the *how* >>>>>>>>> (transformation >>>>>>>>> rules). The *how* is an implementation detail and does not >>>>>>>>> change in >>>>>>>>> time, so there's no benefit in handling it on the server. It >>>>>>>>> should be >>>>>>>>> handled exclusively on the client, which I believe would also >>>>>>>>> make >>>>>>>>> the >>>>>>>>> whole thing more robust (it would not be possible for a bug on >>>>>>>>> the >>>>>>>>> server to break all the clients). >>>>>>>> This is a good point. However, for the scope of Ben's project >>>>>>>> can we >>>>>>>> limit it by openssl and certutil support? Otherwise Ben >>>>>>>> wouldn't be >>>>>>>> able >>>>>>>> to complete the project in time. >>>>>>> >>>>>>> I'm fine with that, but I don't think it's up to me :-) >>>>>>> >>>>>>>> >>>>>>>>>> This is turning out to be a common (and, I think, reasonable) >>>>>>>>>> reaction >>>>>>>>>> to the proposal. It is rather complex, and I worry that it >>>>>>>>>> will be >>>>>>>>>> difficult to configure. On the other hand, there is some hidden >>>>>>>>>> complexity to enabling a simpler config format, as well. One of >>>>>>>>>> the >>>>>>>>>> goals of the project as it was presented to me was to allow the >>>>>>>>>> creation >>>>>>>>>> of profiles that add certificate extensions *that FreeIPA >>>>>>>>>> doesn't >>>>>>>>>> yet >>>>>>>>>> know about*. With the current proposal, one only has to add a >>>>>>>>>> rule >>>>>>>>>> generating text that the helper will understand. >>>>>>>>> >>>>>>>>> ... which will be possible only as long as the helper >>>>>>>>> understands the >>>>>>>>> extension. Which it might not, thus the current proposal works >>>>>>>>> only >>>>>>>>> for *some* extensions that FreeIPA doesn't yet support. >>>>>>>> We can go ad infinitum here but with any helper implementation, >>>>>>>> be it >>>>>>>> python-cryptography or anything else, you will need to have a >>>>>>>> support >>>>>>>> there as well. >>>>>>> >>>>>>> My point was that the current proposal is not any better than my >>>>>>> proposal in this regard, as neither of them allows one to use an >>>>>>> arbitrary extension. >>>>>>> >>>>>>>> The idea with unknown extensions was to allow mapping >>>>>>>> their acceptance to a specific relationship between IPA objects >>>>>>>> (optionally) and an input from the CSR. A simplest example would >>>>>>>> be an >>>>>>>> identity rule that would copy an ASN.1 encoded content from the >>>>>>>> CSR to >>>>>>>> the certificate. >>>>>>>> >>>>>>>> That's on the mapping side, not on the CSR generation side, but it >>>>>>>> would >>>>>>>> go similarly for the CSR if you would be able to enter unknown but >>>>>>>> otherwise correct ASN.1 stream. There is no difference at which >>>>>>>> helper >>>>>>>> type we are talking about because all of them support inserting >>>>>>>> ASN.1 >>>>>>>> content. >>>>>>>> >>>>>>>>>> With your suggestion, >>>>>>>>>> if there's a mapping between "san_directoryname" and the >>>>>>>>>> corresponding >>>>>>>>>> API calls or configuration lines, we need some way for users to >>>>>>>>>> augment >>>>>>>>>> that mapping without changing the code. If there's no >>>>>>>>>> mapping, and >>>>>>>>>> it's >>>>>>>>>> just done with text processing, we need enough in the config >>>>>>>>>> format to >>>>>>>>>> be able to generate fairly complex structures: >>>>>>>>>> >>>>>>>>>> builder = >>>>>>>>>> builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>>>>>>> builder = >>>>>>>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), >>>>>>>>>> False) >>>>>>>>>> >>>>>>>>>> and we need to do it without it being equivalent to calling >>>>>>>>>> eval() on >>>>>>>>>> the config attributes. I'm not sure how to achieve this (is it >>>>>>>>>> safe to >>>>>>>>>> call getattr(x509, extensiontype)(value) where extensiontype and >>>>>>>>>> value >>>>>>>>>> are user-specified?) and it definitely would have to be tied >>>>>>>>>> to a >>>>>>>>>> particular library/tool. >>>>>>>>> >>>>>>>>> As I pointed out above, this needs to be figured out for the >>>>>>>>> generic >>>>>>>>> case for both the current proposal and my suggestion. >>>>>> I have a proof of concept[1] for using openssl-based rules to add a >>>>>> subject alt name extension without using openssl's knowledge of that >>>>>> extension. It's not extremely pretty, and it took some trial and >>>>>> error, >>>>>> but no code changes. So, I think this actually is a difference >>>>>> between >>>>>> the two proposals. >>>>> >>>>> With the obvious catch being that it works only with OpenSSL, which >>>>> might not work for everyone, e.g. when using HSMs or SmartCards, due >>>>> to a limited PKCS#11 support in OpenSSL. >>>> >>>> Very true. Even certutil's equivalent feature (--extGeneric) doesn't >>>> seem like it would work very well in this context, as you are supposed >>>> to pass in an already-encoded extension, so text-based templating >>>> wouldn't be able to do much. >>> >>> Yeah, I struggled with this myself. I ended up writing a pyasn1 script >>> to generate the extension I needed, wrote that to a file, and passed >>> it to certutil using: >>> >>> --extGeneric 2.5.29.17:not-critical:/path/to/msupn.der >>> >>>>> >>>>>> >>>>>> Next we have the easy case, extensions that we as FreeIPA developers >>>>>> know are important and build support for. For these, the two >>>>>> proposals >>>>>> work equivalently well, but yours is simpler to configure because >>>>>> the >>>>>> knowledge of how to make a san_rfc822name is built into the library >>>>>> instead of being stored on the server as a set of rules. >>>>>> >>>>>> Finally, we have the case of extensions that are known to the >>>>>> helper, >>>>>> but not to FreeIPA. In the existing proposal, new rules can be >>>>>> written >>>>>> to support these extensions under a particular helper. Further, >>>>>> those >>>>>> rules can be used by reference in many profiles, reducing >>>>>> duplication of >>>>>> effort/data/errors. >>>>>> >>>>>> As I understand it, the main objections in this thread are that >>>>>> transformation rules are implementation (i.e. helper) specific data >>>>>> stored in the IPA server, and that the system has several levels of >>>>>> schema when it could just embed rules in the profile. But without >>>>>> helper-specific rules, administrators could not take advantage of >>>>>> the >>>>>> additional extensions supported by the helper they are using. >>>>> >>>>> There is *no* advantage in forcing the user to choose between helpers >>>>> which differ only in the set of limitations on the CSR they are able >>>>> to produce. The user should specify a) where the private key is >>>>> located and b) what profile to use, and that's it, it should just >>>>> work. >>>> Ok, this is a good point about usability. The user creating the CSR >>>> shouldn't have to care about helpers, and I agree that the current way >>>> they are exposed is clunky. I do think that an administrator creating >>>> custom rules might want to take advantage of a helper, so they >>>> wouldn't >>>> need to understand the ASN.1 representation of their chosen >>>> certificate >>>> extension. Of course, the desired extension might not be supported by >>>> the helper either. Since I don't know what specific extensions people >>>> will want to use this for, I don't know how to balance the better >>>> administrator experience of adding extensions via a helper with the >>>> limited extension support. >>>> >>>> The original reason we arrived at the concept of "helpers" was to >>>> support different ways of getting at private keys, but perhaps this >>>> should not be the concern of the CSR data generator. In your opinion, >>>> would it be sufficient to support just one key format (PKCS#12? PEM?) >>>> and let the user deal with putting those keys into whatever >>>> formats/databases they need? If that's ok, maybe we can stop having >>>> *multiple* helpers, but if we want to replace helpers entirely I'm >>>> still >>>> not certain what to replace them with. >>> >>> I'd just add an option to specify the output format, e.g PEM, NSS, >>> Java keystore, PKCS#12, whatever. You can probably get away with the >>> first two for starters. Different output format is going to mean >>> different options but that is probably not a big deal. >> >> My point was that if we want to get rid of all the helpers but one, or >> replace helpers with something else entirely like somehow templating >> ASN1 structures directly, it will get harder to support all those >> formats (or even both of the first two). For example, if we drop >> certutil as a helper, how will we sign CSRs with keys stored in NSS >> databases? > > 1. get the public part of the key from the NSS database > 2. construct a CertificationRequestInfo [1] from the template and the > public key > 3. sign the CertificationRequestInfo with NSS using the private key to > get a CSR > > This is purely client side, will work with any crypto library (just > substitute NSS for something else) and, if done right, using very > little code. Ok, I like this. If an encoded CertificationRequestInfo is something we can expect to be compatible with any reasonable library (it sounds like it should be) then the library can be used client-side to do the key-storage-specific parts. I'm going to try writing this data -> encoded CertificationRequestInfo -> CSR flow to make sure it works as well as it sounds. If it does, it will also be useful for the code I'm working on right now to connect certmonger with the current version of the CSR autogeneration tool. > >>> >>> Remember that the private key will be at rest for some period of time >>> while the CSR is being approved. The key needs to be protected at that >>> time. >>> >>> rob >>> >>>>> >>>>>> And >>>>>> without the separation of profiles from mapping rules in the schema, >>>>>> rules would need to be copy+pasted among profiles, and grouping >>>>>> rules >>>>>> with the same effect under different helpers would be much >>>>>> uglier. We >>>>>> can and should discuss whether these are the right tradeoffs, but >>>>>> this >>>>>> is where those decisions came from. >>>>>> >>>>>>>>> >>>>>>>>> OTOH, I think we could use GSER encoding of the extension value: >>>>>>>>> >>>>>>>>> { rfc822Name:"user at example.com", >>>>>>>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>>>>>>> GSER is not really used widely and does not have standardized >>>>>>>> encoding >>>>>>>> rules beyond its own definition. If you want to allow >>>>>>>> transformation >>>>>>>> rules in GSER that mention existing content in IPA objects, you >>>>>>>> would >>>>>>>> need to deal with templating anyway. At this point it becomes >>>>>>>> irrelevant >>>>>>>> what you are templating, though. >>>>>>> >>>>>>> True, but the goal here is not to avoid templating, but rather to >>>>>>> avoid implementation-specific bits on the server, and GSER is the >>>>>>> only >>>>>>> thing that is textual, implementation-neutral and, as a bonus, >>>>>>> standardized. >>>>>>> >>>>>> As I said elsewhere, we could use GSER as a textual output format >>>>>> instead of openssl or certutil, but it still needs its own >>>>>> "helper" to >>>>>> build the CSR, and unlike the other options, it seems like we might >>>>>> need >>>>>> to implement that helper. I'm not sure it's fair to call it >>>>>> implementation-neutral if no implementation exists yet :) >>>>> >>>>> Right. Like I said, using GSER was just a quick idea off the top >>>>> of my >>>>> head. I would actually rather use some sort of data structure >>>>> templating rather than textual templating on top of any kind of >>>>> textual representation of said data structures. I don't know if there >>>>> is such a thing, though. >>>> >>>> This sounds interesting, can you give an example of what this might >>>> look >>>> like? > > It would be something like XSLT, but for ASN.1 rather than XML. > >>>> >>>> I learned that there's also an XML encoding for ASN.1, XER, but that's >>>> still a textual representation and we'd have to insert the data >>>> textually. > > Well, yes and no. While it's true that it's still a textual > representation, what really makes a difference is that for XML, there > is a templating mechanism which understands the structure of the data > (XLST, as mentioned above). > > Unforutantely, XER has the same shortcoming as GSER: to be able to > convert it to DER, you need to know the ASN.1 definition of the data > structure. If we used XER+XSLT, we would also have to provide means of > adding custom ASN.1 definitions and run them through ASN.1 compiler to > convert between XER and DER. This is a little disappointing, but it makes sense. I don't think I realized that we'll need to compile the ASN.1 data definitions for any extensions we want to use in a cert. That limitation didn't come up when we were only talking about extensions that were supported by the helper utility. But providing the ASN.1 spec for unusual extensions an admin wants to use in their certs is probably a reasonable expectation. > >>>> It doesn't seem to be supported by any python libraries, >>>> either, but it does look like it's supported by the asn1 compiler >>>> in the >>>> IPA source distribution.I could imagine an implementation that builds >>>> an XML representation of the CSR via python templating, then makes a >>>> signed CSR out of it in C. I'm a little concerned about it because it >>>> would have to implement the whole CSR structure from scratch, but is >>>> this a prototype that you'd be interested in seeing? > > I can imagine something like this might work: > > 1. (client) generate a key pair > 2. (client) get SubjectPublicKeyInfo [2] for the public key > 3. (client) encode the SubjectPublicKeyInfo as XER using asn1c and > python-cffi in API mode [3] > 4. (client) call server to construct CertificationRequestInfo for > specified subject from a specified template and the SubjectPublicKeyInfo > 5. (server) get the subject's LDAP entry > 6. (server) create a XML document which contains the subject's LDAP > attributes and the SubjectPublicKeyInfo > 7. (server) use XSLT to transform the XML document to > CertificationRequestInfo using the specified template > 8. (server) return the CertificationRequestInfo to the client > 9. (client) convert the CertificationRequestInfo from XER to DER using > asn1c and python-cffi in API mode > 10. (client) sign the CertificationRequestInfo using the private key > to get a CSR > > It would be better if the XER-DER conversion was done on the server, > but I don't think that compiling and running code on the fly on the > server is a particularly good idea. Apparently there is a ASN.1 > compiler available for PyASN1 [4], maybe that could be used instead, > but we would have to write a XER codec for PyASN1 ourselves (which > shouldn't be too hard IMO). Yeah, running programs compiled from arbitrary ASN.1 seems like a risk. Maybe a little better because the ASN.1 is provided by an administrator, but we'd still be depending a lot on the security of the generated code. On the other hand, if we compile on the client, the CSR generation feature is limited to platforms where asn1c can be installed. I wish I could think of a way to do the compilation once when the profile is created, but run it on the client. That seems like asking for compatibility problems, though... > >>>> >> On further investigation, it turns out the version of >> python-cryptography in F24 includes a feature allowing arbitrary >> extensions to be added by adding an UnrecognizedExtension to the >> CertificateSigningRequestBuilder. This makes me feel somewhat better >> both about python-cryptography as a tool for this task and about the >> solution I just proposed. But I still don't have a clear idea that >> answers 1) how to make templates that we can turn into encoded >> extensions, and 2) how to deal with all the desired key formats. > > I hope the above clarifies these a little bit. > > [1] > [2] > [3] > [4] > From freeipa-github-notification at redhat.com Thu Oct 13 15:40:01 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 13 Oct 2016 17:40:01 +0200 Subject: [Freeipa-devel] [freeipa PR#161][+ack] CI: workaround: wait for dogtag before replica-prepare In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/161 Title: #161: CI: workaround: wait for dogtag before replica-prepare Label: +ack From freeipa-github-notification at redhat.com Thu Oct 13 15:40:37 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 13 Oct 2016 17:40:37 +0200 Subject: [Freeipa-devel] [freeipa PR#161][+pushed] CI: workaround: wait for dogtag before replica-prepare In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/161 Title: #161: CI: workaround: wait for dogtag before replica-prepare Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 13 15:40:39 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 13 Oct 2016 17:40:39 +0200 Subject: [Freeipa-devel] [freeipa PR#161][comment] CI: workaround: wait for dogtag before replica-prepare In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/161 Title: #161: CI: workaround: wait for dogtag before replica-prepare martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/91b51e702f1e105329ebea29c633d94516cd673c """ See the full comment at https://github.com/freeipa/freeipa/pull/161#issuecomment-253551844 From freeipa-github-notification at redhat.com Thu Oct 13 15:40:40 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 13 Oct 2016 17:40:40 +0200 Subject: [Freeipa-devel] [freeipa PR#161][closed] CI: workaround: wait for dogtag before replica-prepare In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/161 Author: mbasti-rh Title: #161: CI: workaround: wait for dogtag before replica-prepare Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/161/head:pr161 git checkout pr161 From freeipa-github-notification at redhat.com Thu Oct 13 15:46:33 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 13 Oct 2016 17:46:33 +0200 Subject: [Freeipa-devel] [freeipa PR#160][comment] Reverted the assertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Title: #160: Reverted the assertion for replica uninstall returncode martbab commented: """ I think that issue reported in https://fedorahosted.org/freeipa/ticket/3230 is orthogonal to uninstaller returning 0 on error. I fail to see why we are even discussing this ticket in this context. """ See the full comment at https://github.com/freeipa/freeipa/pull/160#issuecomment-253553642 From freeipa-github-notification at redhat.com Thu Oct 13 15:53:09 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 17:53:09 +0200 Subject: [Freeipa-devel] [freeipa PR#155][comment] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Title: #155: Build system cleanup mbasti-rh commented: """ Works for me, Not pushing yet to give time to others to disagree """ See the full comment at https://github.com/freeipa/freeipa/pull/155#issuecomment-253555492 From freeipa-github-notification at redhat.com Thu Oct 13 15:53:12 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 17:53:12 +0200 Subject: [Freeipa-devel] [freeipa PR#155][+ack] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Title: #155: Build system cleanup Label: +ack From pspacek at redhat.com Thu Oct 13 15:56:11 2016 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Oct 2016 17:56:11 +0200 Subject: [Freeipa-devel] Heimdal Kerberos support for client In-Reply-To: <57FE7F6D.8070902@redhat.com> References: <6d24638e-8198-4e00-22df-bf1bacc5288f@redhat.com> <57FE7F6D.8070902@redhat.com> Message-ID: On 12.10.2016 20:22, Rob Crittenden wrote: > Petr Spacek wrote: >> Hello list, >> >> I just noticed that client/configure.ac contains some checks to detect and >> support Heimdal Kerberos libraries. >> >> Was it tested? Does it work? Can I drop it? :-) >> > > Wow, that's some old code. > > Only Simo would know if it was ever tested or ever worked. > > I suppose since theoretically the client can be built separately theoretically > it might do the right thing in some cases. > > Seems like enough of a corner case to me that I'd remove it, given it is > likely untested these last 9 years or so. Simo told me on IRC that we could remove it. According to Alexander, Ubuntu is building IPA packages against MIT Kerberos so it should be okay. -- Petr^2 Spacek From freeipa-github-notification at redhat.com Thu Oct 13 16:06:20 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 18:06:20 +0200 Subject: [Freeipa-devel] [freeipa PR#160][comment] Reverted the assertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Title: #160: Reverted the assertion for replica uninstall returncode mbasti-rh commented: """ Ticket https://fedorahosted.org/freeipa/ticket/5725 is in already closed milestone, please create a new one (I suppose you want backport to 4.4.3) """ See the full comment at https://github.com/freeipa/freeipa/pull/160#issuecomment-253559347 From mbasti at redhat.com Thu Oct 13 16:10:22 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Oct 2016 18:10:22 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> Message-ID: <36a2eba5-a03d-131e-0042-46f0d4f0299a@redhat.com> I think that you forgot to squash commits. Patch 47 doesn't apply On 13.10.2016 14:01, Oleg Fayans wrote: > Hi Martin, > > Thanks for the review. > With disabling directory server it works as well, thanks for the hint. > Also I moved the cleanup logic to the test itself for the sake of > simplicity. Patch-0048 was not changed > > On 10/12/2016 02:35 PM, Martin Basti wrote: >> 1) >> >> Can you just turn off dirsrv on replica instead of doing iptables magic? >> >> >> 2) NACK >> >> No more eval() ever in code, use 'getattr', 'get' or whatever in the >> object that can be used. >> >> + evalhost = eval("args[0].%s" % host) >> >> Martin^2 >> >> On 12.10.2016 14:03, Oleg Fayans wrote: >>> Hi Martin, >>> >>> After extensive discussion with Ludwig, I finally got the clue on how >>> does this feature work. When we uninstall the replica, the master >>> cleans the replication agreements with this replica and automatically >>> cleans all replica's RUVs. >>> If we clean replica's RUVs on master without uninstalling the replica, >>> the replica's RUVs get recreated on master (replication works!). So, >>> the only way to test the clean-ruv subcommand is to turn off the >>> replica, or block the traffic on it so it gets inaccessible to updates >>> from master. >>> The testcases were updated, see [1] and [2] >>> >>> The updated versions of the patches are attached >>> >>> [1] >>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs >>> >>> >>> >>> [2] >>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand >>> >>> >>> >>> On 08/05/2016 06:36 PM, Martin Basti wrote: >>>> >>>> >>>> On 03.08.2016 14:45, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> Thanks for the review! Both patches were updated. >>>>> >>>>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> Thanks for the review! >>>>>>> >>>>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>>>> before >>>>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>>>> feature. >>>>>>>>> >>>>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>>>> One more test was added to the patch-0048 >>>>>>>>>> >>>>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>>>> from >>>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> IIUC, this will turn off the machine completely, how is cleanup >>>>>>>> done >>>>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>>>> cleanup, so >>>>>>>> you will not be able to run more tests on the same topology >>>>>>>> without >>>>>>>> manual cleanup and manual start. >>>>>>>> >>>>>>>> + replica = self.replicas[0] >>>>>>>> + replica.run_command(['poweroff']) >>>>>>>> >>>>>>>> IMO would be better to just call 'ipactl stop' instead of >>>>>>>> 'poweroff' >>>>>>> >>>>>>> Agreed! Fixed. >>>>>>> >>>>>>>> >>>>>>>> Martin^2 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> *Automated ipa-replica-manage del tests* >>>>>> >>>>>> 1) >>>>>> + replica.run_command(['ipactl', 'stop']) >>>>>> + time.sleep(3) >>>>>> >>>>>> Why do you need sleep here? >>>>> >>>>> Removed, it was left from the old "poweroff" approach >>>>> >>>>>> >>>>>> >>>>>> 2) >>>>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % >>>>>> replica.hostname) >>>>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>>>> + '-p', master.config.dirman_password, >>>>>> + replica_ruvs[0]]) >>>>>> >>>>>> Because you are using re.findall(), without any match you will >>>>>> receive >>>>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>>>> >>>>> Implemented the assert which checks that the output contains enough >>>>> replica RUVs >>>>> >>>>>> >>>>>> 3) >>>>>> assert(replica.hostname in result1.stdout_text) >>>>>> >>>>>> I think that this is error prone. What if there is just error >>>>>> 'could not >>>>>> connect to replica ', or something similar. >>>>>> instead of >>>>>> listing/cleaning/whatever operation was executed. I think that it >>>>>> should >>>>>> be more specific regexp than just finding a replica name substring >>>>>> (Yes >>>>>> In IPA we dont always print error so stderr) >>>>>> >>>>>> I'm not sure, but probably there might be cases when non critical >>>>>> error >>>>>> happen and exist status is still 0 >>>>> >>>>> Agree. Implemented a regex-based search >>>>> >>>>>> >>>>>> 4) >>>>>> >>>>>> + replica.run_command(['poweroff']) >>>>>> + time.sleep(3) >>>>>> >>>>>> There should not be poweroff, probably sleep could be removed too. >>>>> >>>>> Gone >>>>> >>>>>> >>>>>> >>>>>> * Automated clean-ruv subcommand test* >>>>>> >>>>>> 1) PEP8, 2 new lines expected >>>>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>>>> blank lines, found 0 >>>>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>>>> long >>>>>> (85 > 79 characters) >>>>> >>>>> Fixed >>>>> >>>>>> >>>>>> >>>>>> 2) >>>>>> I dont like doing assert just with count of occurences of >>>>>> substring in >>>>>> STDOUT, would be possible to improve this somehow? >>>>> >>>>> Maybe, but frankly, I don't see how. In this case we are making sure >>>>> that both simple and CA-specific RUVs of a replica are displayed. The >>>>> format of the output is strict: >>>>> Replica Update Vectors: >>>>> replica1_hostname:389: RUV_id >>>>> replica2_hostname:389: RUV_id >>>>> Certificate Server Replica Update Vectors: >>>>> replica1_hostname:389: RUV_id >>>>> replica2_hostname:389: RUV_id >>>>> If we do not see 2 occurrences of the replica hostname than >>>>> definitely >>>>> something went wrong >>>>> >>>>>> >>>>>> 3) >>>>>> I'm not sure if clean-ruv is instant operations or there is some >>>>>> magic >>>>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>>>> should be there, but this needs investigation. >>>>>> >>>>>> + assert(replica.hostname in result2.stdout_text), ( >>>>>> + "The wrong RUV was deleted") >>>>>> + result3 = master.run_command(['ipa-replica-manage', >>>>>> 'list-ruv', >>>>>> + '-p', >>>>>> master.config.dirman_password]) >>>>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>>>> + "CA RUV of the replica is still displayed") >>>>>> >>>>> >>>>> Based on my discussion with Stanislav Laznicka, I understood that by >>>>> default clean-ruv does not return the shell until the operation is >>>>> finished. You can force dropping into the shell by pressing >>>>> CTRL+C, in >>>>> which case the background job will still be running, but this is not >>>>> the default behavior >>>>> >>>> Test failed: >>>> result4 = master.run_command(['ipa-replica-manage', >>>> 'list-ruv', >>>> '-p', >>>> master.config.dirman_password]) >>>>> assert(replica.hostname not in result4.stdout_text), ( >>>> "replica's RUV is still displayed") >>>> E AssertionError: replica's RUV is still displayed >>>> E assert 'replica3.ipa.test' not in 'Replica Update >>>> V...ipa.test:389: 8\n' >>>> E 'replica3.ipa.test' is contained here: >>>> E Replica Update Vectors: >>>> E \tmaster.ipa.test:389: 4 >>>> E \treplica3.ipa.test:389: 3 >>>> E \treplica2.ipa.test:389: 7 >>>> E Certificate Server Replica Update Vectors: >>>> E \tmaster.ipa.test:389: 6 >>>> E \treplica2.ipa.test:389: 8 >>>> >>>> >>>> [root at master ~]# ipa topologysegment-find >>>> Suffix name: domain >>>> ------------------ >>>> 2 segments matched >>>> ------------------ >>>> Segment name: master.ipa.test-to-replica2.ipa.test >>>> Left node: master.ipa.test >>>> Right node: replica2.ipa.test >>>> Connectivity: both >>>> >>>> Segment name: master.ipa.test-to-replica3.ipa.test >>>> Left node: master.ipa.test >>>> Right node: replica3.ipa.test >>>> Connectivity: both >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> [root at master ~]# ipa-replica-manage list-ruv >>>> Directory Manager password: >>>> >>>> Replica Update Vectors: >>>> master.ipa.test:389: 4 >>>> replica2.ipa.test:389: 7 >>>> replica3.ipa.test:389: 3 >>>> Certificate Server Replica Update Vectors: >>>> master.ipa.test:389: 6 >>>> replica2.ipa.test:389: 8 >>>> [root at master ~]# >>>> >>>> Then I tried manually to clean RUV 3, and it behaves somehow odd >>>> >>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>> 'Secret123' '-f' >>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>> Background task created to clean replication data. This may take a >>>> while. >>>> This may be safely interrupted with Ctrl+C >>>> Cleanup task created >>>> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >>>> [root at master ~]# ipa-replica-manage list-ruv >>>> Directory Manager password: >>>> >>>> Replica Update Vectors: >>>> master.ipa.test:389: 4 >>>> replica2.ipa.test:389: 7 >>>> replica3.ipa.test:389: 3 >>>> Certificate Server Replica Update Vectors: >>>> master.ipa.test:389: 6 >>>> replica2.ipa.test:389: 8 >>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>> 'Secret123' '-f' >>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>> CLEANALLRUV task for replica id 3 already exists. >>>> This may be safely interrupted with Ctrl+C >>>> Cleanup task created >>>> >>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>> No CLEANALLRUV tasks running >>>> >>>> No abort CLEANALLRUV tasks running >>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>> 'Secret123' '-f' >>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>> Background task created to clean replication data. This may take a >>>> while. >>>> This may be safely interrupted with Ctrl+C >>>> Cleanup task created >>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>> CLEANALLRUV tasks >>>> RID 3: Successfully cleaned rid(3). >>>> >>>> No abort CLEANALLRUV tasks running >>>> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >>>> Replica Update Vectors: >>>> master.ipa.test:389: 4 >>>> replica2.ipa.test:389: 7 >>>> Certificate Server Replica Update Vectors: >>>> master.ipa.test:389: 6 >>>> replica2.ipa.test:389: 8 >>>> >>>> >>>> I'm not sure if this behavior is right, Ludwig may know. >>> >> > From freeipa-github-notification at redhat.com Thu Oct 13 16:36:21 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 18:36:21 +0200 Subject: [Freeipa-devel] [freeipa PR#136][synchronized] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Author: mbasti-rh Title: #136: Fix KRA install tests Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/136/head:pr136 git checkout pr136 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-136.patch Type: text/x-diff Size: 12183 bytes Desc: not available URL: From tjaalton at ubuntu.com Thu Oct 13 16:41:26 2016 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Thu, 13 Oct 2016 19:41:26 +0300 Subject: [Freeipa-devel] Heimdal Kerberos support for client In-Reply-To: References: <6d24638e-8198-4e00-22df-bf1bacc5288f@redhat.com> <57FE7F6D.8070902@redhat.com> Message-ID: <854ed2c8-e35a-96bd-3016-b5cbda9c4dc8@ubuntu.com> On 13.10.2016 18:56, Petr Spacek wrote: > On 12.10.2016 20:22, Rob Crittenden wrote: >> Petr Spacek wrote: >>> Hello list, >>> >>> I just noticed that client/configure.ac contains some checks to detect and >>> support Heimdal Kerberos libraries. >>> >>> Was it tested? Does it work? Can I drop it? :-) >>> >> >> Wow, that's some old code. >> >> Only Simo would know if it was ever tested or ever worked. >> >> I suppose since theoretically the client can be built separately theoretically >> it might do the right thing in some cases. >> >> Seems like enough of a corner case to me that I'd remove it, given it is >> likely untested these last 9 years or so. > > Simo told me on IRC that we could remove it. According to Alexander, Ubuntu is > building IPA packages against MIT Kerberos so it should be okay. Yes, everything I've touched uses MIT on Debian/Ubuntu. -- t From sbose at redhat.com Thu Oct 13 16:52:35 2016 From: sbose at redhat.com (Sumit Bose) Date: Thu, 13 Oct 2016 18:52:35 +0200 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> On Tue, Oct 11, 2016 at 01:37:09PM +0200, Sumit Bose wrote: > On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: > > Hi, > > > > I've started to write a SSSD design page about enhancing the current > > mapping of certificates to users and how to select/match a suitable > > certificate if multiple certificates are on a Smartcard. > > > > My currently thoughts and idea and be found at > > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates > > and for your convenience below as well. > > > > Comments and suggestions are welcome. Please let me know about concerns, > > alternatives and missing use-cases/user-stories. > > > > bye, > > Sumit > > > > Hi, > > Rob, Fraser, Alexander, thank you for your comments. I think both the > issuer specific matching and the OID in the SUBJECT matching are good > ideas. I updated the design page accordingly. The changes can be shown > with > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff&version=9&old_version=6 > > The updated version can be found below as well. Of course more comments and > suggestions are still very welcome. > I did another update. A "Compatibility with Active Director" section is added which made me realize that there are use-cases for using the issuer in the mapping as well and the sub-strings in LDAP search filters might be useful as well. The changes can be seen with https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff&version=10&old_version=9 Please let me know your comments and suggestions. bye, Sumit = Matching and Mapping Certificates = Related ticket(s): * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping === Problem statement === ==== Mapping ==== Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. ==== Matching ==== Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. === Use cases === ==== Mapping ==== In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: * Certificates/Smartcards are issued externally * LDAP schema extension is not possible or not allowed ==== Matching ==== A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. === Overview of the solution === To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. === Implementation details === ==== Matching ==== The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are * regular-expression * regular-expression * regular-expression * extended-key-usage-list * key-usage-list and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate. '''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?''' While and are (imo) already quite flexible I can see some potential extensions for the other components. and in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless). The component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with ===== Issuer specific matching ===== Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. How the issuer string is linked to the matching rules depends on the storage (LDAP or sssd.conf, see below for details). ==== Mapping ==== Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case. If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|". A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g. * * * where O.I.D. is either the OID or name of a RDN type or the OID or some well-known-name of the SAN component respectively. Since the SUBJECT might contain multiple RDNs of the same type always the "most specific" is selected because in general this will be the most suited one to map the certificate to a specific user. "most specific" means the last in X.500 order and the first in LDAP order (see discussion below for details). If the O.I.D. is missing the full SUBJECT/ISSUER is used for mapping. If 'DN' is used as ldapAttributeName SUBJECT is expected to be the DN of the user. If the O.I.D. is missing in the SAN case the same default as with matching (id-pkinit-san and szOID_NT_PRINCIPAL_NAME OID) is used. If both SAN values can be found in the certificate and are different the LDAP search filter will combine both with the or-operator. The optional '*' in the end indicates that a sub-string search (ldapAttributeName=*value*) should be used and not an exact match (ldapAttributeName=value). Please note that it depends on the server-side definition of the LDAP attribute if case-sensitive or case-insensitve matching is used. Currently I see no usage for and in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add based mappings. ===== Future consideration ===== Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of might be tricky as discussed below. Nevertheless it might be possible to add to following in a future release if more complex operations on the values are needed: * /regexp/replacement/ * /regexp/replacement/ where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like {{{ /^CN=\([^,]*\).*$/\1/ }}} would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expressions.html#g-regex-replace g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. Maybe even search-and-replace are not sufficient for all cases and something like embedded lua scripts are needed. But since certificate mapping is about access control and authorization it should be always considered if adding a new attribute to the users LDAP entry which makes mapping easy and straight-forward wouldn't be the better solution. ===== Some notes about DNs ===== The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the * X.500 order: DC=com,DC=example,CN=users,CN=Certuser or in the * LDAP order: CN=Certuser,CN=Users,DC=example,DC=com As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111). This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP) Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user at example.com', certtool as 'EMAIL=user at example.com' and certutil as 'E=user at example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]: * CN commonName (2.5.4.3) * L localityName (2.5.4.7) * ST stateOrProvinceName (2.5.4.8) * O organizationName (2.5.4.10) * OU organizationalUnitName (2.5.4.11) * C countryName (2.5.4.6) * STREET streetAddress (2.5.4.9) * DC domainComponent (0.9.2342.19200300.100.1.25) * UID userId (0.9.2342.19200300.100.1.1) ==== About restricting or enforcing the mapping an matching any further ==== The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing. Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together. In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in. But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from. So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in. ==== Storing matching and mapping configuration ==== On the IPA server a new objectclass can be created to store an matching-mapping rule pair together with a specific issuer. All attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping. If only a specific issuer is given certificates from this issuer must be stored in the LDAP entry of the user to make authentication possible. Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule. Issuer specific rules will have three pairs of curly braces where the first pair must contain an issuer string. ===== Future considerations ===== If it turns out that this option is used quite often and it gets complicated to manage a larger set of rules with it and storing the rules in LDAP/IPA/AD is not an option we might add support to read the rules from a separate file (certificate_rules = FILE:///etc/sssd/cert_rules) with a more suitable format, e.g. ini where a list can be defined by given the same option multiple times. ===== Examples ===== * '''certificate_rules = {msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with * '''certificate_rules = {1.3.6.1.4.1.311.20.2.2}''': see above * '''certificate_rules = {*my-company**@my-company.com$}{}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user. ==== Compatibility with Active Directory ==== Active Directory uses a per-user LDAP attribute [https://msdn.microsoft.com/en-us/library/cc220106.aspx altSecurityIdentities] to allow arbitrary user-certificate mappings is there is no suitable user-principal-name entry in the SAN of the certificate. Unfortunately it is more or less undocumented how AD use the values of this attribute. The best overview I found is in https://blogs.msdn.microsoft.com/spatdsg/2010/06/18/howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute/. It looks like the most important variant is the issuer-subject pair. This one is e.g. created when a certificate is added via the 'Name Mappings' context menu entry in AD's 'Users and Computers' utility ('Advanced Features' must be activated in the 'View' menu). The attribute value might look like {{{ altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate AuthorityDC =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co m,CN=Sumit Bose Sumit Bose }}} First it can be seen that X.500 ordering is used. Second, if RDN types not explicitly mentioned in the RFCs are used, you are on your own. As can be seen AD can translate the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] and uses 'E' as NSS. But the OID [http://www.oid-info.com/get/0.9.2342.19200300.100.1.1 0.9.2342.19200300.100.1.1] which is explicitly mentioned in RFC4514 is not translated as UID but the plain OID syntax is used (my guess it that Microsoft tries to be compatible with "older" versions because the UID was added in RFC2253 from 1997 but was not present in the RFC1779 from 1995 and RFC1485 from 1993). Nevertheless with the mapping rules described above a rule like {{{ }}} would product a LDAP search filter like {{{ (&(altSecurityIdentities=*Red Hat*)(altSecurityIdentities=*Sumit Bose Sumit Bose*)) }}} which should quite reliable find the right LDAP entry. As an alternative it would be possible to add special mapping rules like which would try in a best effort to produce the exact attribute value AD is using. This should work reliable with standard RDN types (see above). I think an optional 'ldapAttributeName' is useful here so that the same mapping rule can be used with different LDAP servers (e.g. IPA) where user-specific mapping attributes are used with the same content but a different attribute name. According to the blob post describing altSecurityIdentities some other additional mapping rules might be useful too. This will give us * * * * * * So far I didn't found a AD tool which creates to other mappings, if you know one, please let me know. === Configuration changes === Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for. === How To Test === This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus. === How To Debug === Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for. === Authors === Give credit to authors of the design in this section. From pvoborni at redhat.com Thu Oct 13 17:49:34 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Oct 2016 19:49:34 +0200 Subject: [Freeipa-devel] Broken IPA installation caused by new python-dns package In-Reply-To: References: <7ec8e751-af67-5850-d051-d1f7fe96025f@redhat.com> Message-ID: <168ccd5d-fd12-aa89-1665-36df3aa27a06@redhat.com> On 10/12/2016 11:11 AM, Petr Spacek wrote: > On 10.10.2016 10:28, Martin Basti wrote: >> https://bodhi.fedoraproject.org/updates/FEDORA-2016-1857421df6 >> >> >> Please set karma accordingly >> >> >> Traceback: >> >> ... >> >> 2016-10-10T04:44:05Z DEBUG The ipa-replica-install command failed, exception: >> TypeError: 'unicode' does not have the buffer interface >> 2016-10-10T04:44:05Z ERROR 'unicode' does not have the buffer interface >> >> >> I'll investigate if IPA using it wrong or there is new error introduced in >> pyhton-dns > > For archaeologists: > Fix > https://github.com/freeipa/freeipa/pull/150 > was merged. > We've pushed PR 150 to 4.4 and master. 4.4.2 release fixes f25 and f26 but F24 has 4.3 branch. Is it correct to assume that 4.3 is also affected? If so, then we need either to backport the patch to 4.3 and fix Fedora directly or completely block the python-dns update on f24. -- Petr Vobornik From mbasti at redhat.com Thu Oct 13 17:56:42 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 13 Oct 2016 19:56:42 +0200 Subject: [Freeipa-devel] Broken IPA installation caused by new python-dns package In-Reply-To: <168ccd5d-fd12-aa89-1665-36df3aa27a06@redhat.com> References: <7ec8e751-af67-5850-d051-d1f7fe96025f@redhat.com> <168ccd5d-fd12-aa89-1665-36df3aa27a06@redhat.com> Message-ID: On 13.10.2016 19:49, Petr Vobornik wrote: > On 10/12/2016 11:11 AM, Petr Spacek wrote: >> On 10.10.2016 10:28, Martin Basti wrote: >>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-1857421df6 >>> >>> >>> Please set karma accordingly >>> >>> >>> Traceback: >>> >>> ... >>> >>> 2016-10-10T04:44:05Z DEBUG The ipa-replica-install command failed, exception: >>> TypeError: 'unicode' does not have the buffer interface >>> 2016-10-10T04:44:05Z ERROR 'unicode' does not have the buffer interface >>> >>> >>> I'll investigate if IPA using it wrong or there is new error introduced in >>> pyhton-dns >> For archaeologists: >> Fix >> https://github.com/freeipa/freeipa/pull/150 >> was merged. >> > We've pushed PR 150 to 4.4 and master. 4.4.2 release fixes f25 and f26 > but F24 has 4.3 branch. > > Is it correct to assume that 4.3 is also affected? > > If so, then we need either to backport the patch to 4.3 and fix Fedora > directly or completely block the python-dns update on f24. 4.3 shouldn't be affected, because the code that has been failing is only in 4.4+ in DNS Locations related feature Martin^2 From freeipa-github-notification at redhat.com Thu Oct 13 18:54:32 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 20:54:32 +0200 Subject: [Freeipa-devel] [freeipa PR#127][+ack] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension Label: +ack From freeipa-github-notification at redhat.com Thu Oct 13 18:55:47 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 20:55:47 +0200 Subject: [Freeipa-devel] [freeipa PR#127][+pushed] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 13 18:55:49 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 20:55:49 +0200 Subject: [Freeipa-devel] [freeipa PR#127][comment] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/6c53765ac1746ea3cb82554775a37fe43af062e8 https://fedorahosted.org/freeipa/changeset/6c09d6f8788b5436d6c9a5af4cc079a843f00e33 """ See the full comment at https://github.com/freeipa/freeipa/pull/127#issuecomment-253605497 From freeipa-github-notification at redhat.com Thu Oct 13 18:55:50 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 20:55:50 +0200 Subject: [Freeipa-devel] [freeipa PR#127][closed] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Author: tjaalton Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/127/head:pr127 git checkout pr127 From freeipa-github-notification at redhat.com Thu Oct 13 19:04:28 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 21:04:28 +0200 Subject: [Freeipa-devel] [freeipa PR#156][+pushed] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Title: #156: cert: add revocation reason back to cert-find output Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 13 19:04:29 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 21:04:29 +0200 Subject: [Freeipa-devel] [freeipa PR#156][comment] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Title: #156: cert: add revocation reason back to cert-find output mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/16dad1c3cb09acee946bc5b2409447279a8bc0de ipa-4-4: https://fedorahosted.org/freeipa/changeset/30b478113e0dd7993f491c1582003567e9b20d13 """ See the full comment at https://github.com/freeipa/freeipa/pull/156#issuecomment-253607864 From freeipa-github-notification at redhat.com Thu Oct 13 19:04:30 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 21:04:30 +0200 Subject: [Freeipa-devel] [freeipa PR#156][closed] cert: add revocation reason back to cert-find output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/156 Author: jcholast Title: #156: cert: add revocation reason back to cert-find output Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/156/head:pr156 git checkout pr156 From freeipa-github-notification at redhat.com Thu Oct 13 19:13:18 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 21:13:18 +0200 Subject: [Freeipa-devel] [freeipa PR#136][edited] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Author: mbasti-rh Title: #136: Fix KRA install tests Action: edited Changed field: body Original value: """ - in test_installation testsuite KRA related tests were duplicated, this PR removes it - in test_installation test suite with domain level 0, some KRA tests must be skipped because does not work under domain level 0 by design - because in previous commits I decreased amount of replicas in test_installation, I added KRA tests into replication_layout test suite to test how KRA install works with more replicas and various layouts (needed mainly for domain level 0) https://fedorahosted.org/freeipa/ticket/6088 """ From pvoborni at redhat.com Thu Oct 13 19:17:43 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Oct 2016 21:17:43 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 4.4.2 Message-ID: <35f41ae2-9596-3b20-cf0c-35e5f34e1ad8@redhat.com> The FreeIPA team would like to announce FreeIPA 4.4.2 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora 24 will be available in the official COPR repository . This announcement is also available on http://www.freeipa.org/page/Releases/4.4.2 Fedora 25 update: https://bodhi.fedoraproject.org/updates/freeipa-4.4.2-1.fc25 == Highlights in 4.4.2 == === Known Issues === * ipa-ca-install fails on replica when master is CA-less #6226 * ipa cert-find command doesn't return revocation reason in output, Web UI then cannot display proper state of a certificate #6269 === Bug fixes === FreeIPA 4.4.2 is a stabilization release for the features delivered as a part of 4.4.0. There are more than 40 bug-fixes which details can be seen in the list of resolved tickets below. == Upgrading == Upgrade instructions are available on upgrade page . == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Resolved tickets == * 4802 Investigate & document if TLS 1.2 is properly supported * 5557 Strict dependency of optional package pam_krb5 * 5644 dnsrecord-del incompatible with admintools < ver 3.2 and server >= ver 3.2 * 5725 failed ipa-server-install --uninstall returns exit code 0 * 5754 ipa-client-install man page has incorrect data on hostname * 5755 test_0006_service_show in test_cert_plugin uses global variable wrong * 5809 ipa-server-install fails when using external certificates that encapsulate RDN components in double quotes * 5814 Change IP address validation errors to warnings [support for cloud environments] * 5818 webui: "Restore" option is not available for a preserved user in detailed info * 5822 Cannot create user with username exactly 255 charaters long * 5855 method get_primary_key_from_dn does not work for netgroups properly * 6057 adding two way non transitive(external) trust displays internal error on the console * 6095 ipa command stuck forever on higher versioned client with lower versioned server * 6155 [tracker] Failed to configure CA instance * 6190 Regressions found by test: ipa.test_ipalib.test_parameters * 6203 dnsrecord-add does not prompt for missing record parts internactively * 6212 Pretty-print mismatches in tests * 6216 webui: cert_revoke should use --cacn to set correct CA when revoking certificate * 6221 Certificate revocation in service-del and host-del isn't aware of Sub CAs * 6230 installer: external CA step 1 successful but reports ScriptError * 6238 Unable to view certificates issued by Sub CA in Web UI * 6256 [tracker] Revoke certificate on lightweight CA deletion * 6257 Implement ca-enable/disable commands. * 6260 cert-request: use better error message when CA is disabled * 6273 Command autocompletion without installed server prints an error message * 6279 CLI always sends default command version * 6285 Tests: Regex errors in trust tests * 6288 ipa-certupdate fails with "CA is not configured" * 6294 TypeError in installer * 6296 client-install with IPv6 address fails on link-local address (always) * 6300 Remove the assertion of incorrect return code from replica_promotion tests * 6301 Fix replica_promotion tests * 6304 cert-find --certificate does not work for certificates not in LDAP * 6306 Add cleanup to integration trust tests * 6309 cert-request does not raise error when CSR does not match profile pattern * 6312 Failing ldap backend test because service not found * 6313 Failing test in test_ipalib/test_plugable * 6322 Add krb5kdc restart to integration trust tests * 6323 Tests: Remove usage of krb5 ccache from test_ipaserver/test_ldap * 6326 Update host test with ipa-join * 6327 regression in `ipa cert-revoke --help` * 6328 ipa trust-fetch-domains throws internal error * 6329 WinSync users who have First.Last casing creates users who can have their password set * 6330 Invalid description for --hostname option in ipa-server-install man page * 6333 Skipped test_ipalib/test_text::test_TestLang::test_test_lang in outoftree suite * 6338 [Tests] Remove SSSD restart from integration tests * 6341 Certificate UI on details page shows add button even if user doesn't have write right * 6349 Tests: incomplete cleanup of CA plugin XMLRPC tests * 6366 Extend CA ACL tests for test cases with CSR containing Subject Alt Name * 6368 otpd doesn't properly handle closing of ldap connection * 6373 test_util.test_assert_deepequal fails * 6382 Test: disable test for wrong client domain in domain level 0 * 6385 ipa-server-install --external-ca fails with AttributeError * 6390 python-dns 1.15.0 breaks FreeIPA * 6391 make FreeIPA codebase ready for pylint in Fedora rawhide * 5791 CA fails to start after doing ipa-ca-install --external-ca == Detailed changelog since 4.4.1 == === Christian Heimes (1) === * Use RSA-OAEP instead of RSA PKCS#1 v1.5 === David Kupka (2) === * UnsafeIPAddress: Implement __(g|s)etstate__ and to ensure proper (un)pickling * schema cache: Store and check info for pre-schema servers === Florence Blanc-Renaud (2) === * Fix regression introduced in ipa-certupdate * Fix ipa-certupdate for CA-less installation === Fraser Tweedale (10) === * Add commentary about CA deletion to plugin doc * spec: require Dogtag >= 10.3.5-6 * cert-request: raise error when request fails * Make host/service cert revocation aware of lightweight CAs * cert-request: raise CertificateOperationError if CA disabled * Use Dogtag REST API for certificate requests * Add HTTPRequestError class * Allow Dogtag RestClient to perform requests without logging in * Add ca-disable and ca-enable commands * Track lightweight CAs on replica installation === Jan Cholasta (8) === * test_plugable: update the rest of test_init * dns: re-introduce --raw in dnsrecord-del * client: remove hard dependency on pam_krb5 * cert: fix cert-find --certificate when the cert is not in LDAP * dns: fix crash in interactive mode against old servers * dns: prompt for missing record parts in CLI * dns: normalize record type read interactively in dnsrecord_add * cli: use full name when executing a command === Lenka Doudova (11) === * Tests: Certificate revocation * Tests: Remove invalid certplugin tests * Tests: Remove usage of krb5 ccache from test_ipaserver/test_ldap * Tests: Fix host attributes in ipa-join host test * Tests: Update host test with ipa-join * Tests: Add krb5kdc.service restart to integration trust tests * Tests: Remove SSSD restart from integration tests * Tests: Fix integration sudo tests setup and checks * Tests: Fix failing ldap.backend test * Tests: Add cleanup to integration trust tests * Tests: Fix regex errors in integration trust tests === Martin Babinsky (13) === * disable warnings reported by pylint-1.6.4-1 * mod_nss: use more robust quoting of NSSNickname directive * Move character escaping function to ipautil * Make Continuous installer continuous only during execution phase * use separate exception handlers for executors and validators * ipa passwd: use correct normalizer for user principals * trust-fetch-domains: contact forest DCs when fetching trust domain info * netgroup: avoid extraneous LDAP search when retrieving primary key from DN * ldapupdate: Use proper inheritance in BadSyntax exception * raise ValidationError when deprecated param is passed to command * Always fetch forest info from root DCs when establishing one-way trust * factor out `populate_remote_domain` method into module-level function * Always fetch forest info from root DCs when establishing two-way trust === Martin Basti (17) === * test_text: add test ipa.pot file for tests * Test: dont use global variable for iteration in test_cert_plugin * Use constant for user and group patterns * Fix regexp patterns in parameters to not enforce length * Add check for IP addresses into DNS installer * Fix missing config.ips in promote_check * Abstract procedures for IP address warnings * Catch DNS exceptions during emptyzones named.conf upgrade * Start named during configuration upgrade. * Tests: extend DNS cmdline tests with lowercased record type * Show warning when net/broadcast IP address is used in installer * Allow multicast addresses in A/AAAA records * Allow broadcast ip addresses * Allow network ip addresses * Fix parse errors with link-local addresses * Fix ScriptError to always return string from __str__ * Set zanata project-version fo 4.4 branch === Milan Kub?k (3) === * ipatests: Implement tests with CSRs requesting SAN * ipatests: Fix name property on a service tracker * ipatests: provide context manager for keytab usage in RPC tests === Nathaniel McCallum (1) === * Properly handle LDAP socket closures in ipa-otpd === Oleg Fayans (4) === * Test: disabled wrong client domain tests for domlevel 0 * Changed addressing to the client hosts to be replicas * Several fixes in replica_promotion tests * Removed incorrect check for returncode === Petr Spacek (1) === * Fix compatibility with python-dns 1.15.0 === Pavel Vomacka (5) === * WebUI: hide buttons in certificate widget according to acl * Add 'Restore' option to action dropdown menu * WebUI add support for sub-CAs while revoking certificates * WebUI: Fix showing certificates issued by sub-CA * Add support for additional options taken from table facet === Stanislav Laznicka (5) === * Make installer quit more nicely on external CA installation * Fix test_util.test_assert_deepequal test * Pretty-print structures in assert_deepequal * Remove update_from_dict() method * Updated help/man information about hostname === Tomas Krizek (4) === * Keep NSS trust flags of existing certificates * Update ipa-server-install man page for hostname * Add help info about certificate revocation reasons * Don't show error messages in bash completion -- Petr Vobornik From freeipa-github-notification at redhat.com Thu Oct 13 19:20:22 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 13 Oct 2016 21:20:22 +0200 Subject: [Freeipa-devel] [freeipa PR#161][comment] CI: workaround: wait for dogtag before replica-prepare In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/161 Title: #161: CI: workaround: wait for dogtag before replica-prepare mbasti-rh commented: """ It looks that 30 seconds is not enough, majority of ipa-replica-prepare passed, but I had a few test where it is still failing (randomly) """ See the full comment at https://github.com/freeipa/freeipa/pull/161#issuecomment-253611853 From freeipa-github-notification at redhat.com Fri Oct 14 03:18:30 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 14 Oct 2016 05:18:30 +0200 Subject: [Freeipa-devel] [freeipa PR#127][comment] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension frasertweedale commented: """ I think this change has caused SELinux errors when starting the daemon. (I had to `setenforce 0` to get the installer to complete). """ See the full comment at https://github.com/freeipa/freeipa/pull/127#issuecomment-253699714 From freeipa-github-notification at redhat.com Fri Oct 14 05:03:47 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 14 Oct 2016 07:03:47 +0200 Subject: [Freeipa-devel] [freeipa PR#162][opened] Certificate processing refactoring Message-ID: URL: https://github.com/freeipa/freeipa/pull/162 Author: frasertweedale Title: #162: Certificate processing refactoring Action: opened PR body: """ This PR contains ready-for-review/test commits that: - support converting python-cryptography Name type to DN - avoid the need to parse friendlyName from CSR and remove the code that does that - convert `ipalib.pkcs10` to use python-cryptography instead of NSS for processing CSRs. - eliminate our use of the nss.data_to_hex function - switch `ipalib.x509` to use ASN.1 specifications provided by *pyasn1-modules* library, and remove our hand-rolled definitions. It was discussed to target subteam staging branches for the ongoing refactoring work but it does not seem that these were created yet. I can retarget the PR after the cert refactoring branch gets created. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/162/head:pr162 git checkout pr162 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-162.patch Type: text/x-diff Size: 35044 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 05:05:45 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 14 Oct 2016 07:05:45 +0200 Subject: [Freeipa-devel] [freeipa PR#163][opened] Do not create Object Signing certificate Message-ID: URL: https://github.com/freeipa/freeipa/pull/163 Author: frasertweedale Title: #163: Do not create Object Signing certificate Action: opened PR body: """ The Object Signing certificate created during server installation was used only for signing the (recently removed) Firefox extension, so there's no need to create that certificate any more. Fixes: https://fedorahosted.org/freeipa/ticket/6399 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/163/head:pr163 git checkout pr163 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-163.patch Type: text/x-diff Size: 3997 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 05:31:59 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 14 Oct 2016 07:31:59 +0200 Subject: [Freeipa-devel] [freeipa PR#162][synchronized] Certificate processing refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/162 Author: frasertweedale Title: #162: Certificate processing refactoring Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/162/head:pr162 git checkout pr162 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-162.patch Type: text/x-diff Size: 35043 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 06:10:59 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 14 Oct 2016 08:10:59 +0200 Subject: [Freeipa-devel] [freeipa PR#164][opened] Trust AD cleanup Message-ID: URL: https://github.com/freeipa/freeipa/pull/164 Author: mirielka Title: #164: Trust AD cleanup Action: opened PR body: """ Adding operations that remove test related trust information from AD machines. Package samba-client is necessary for this operation, hence tests are skipped if the package is not installed. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/164/head:pr164 git checkout pr164 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-164.patch Type: text/x-diff Size: 3228 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 06:38:17 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 14 Oct 2016 08:38:17 +0200 Subject: [Freeipa-devel] [freeipa PR#164][synchronized] Trust AD cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/164 Author: mirielka Title: #164: Trust AD cleanup Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/164/head:pr164 git checkout pr164 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-164.patch Type: text/x-diff Size: 3231 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 07:42:25 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 14 Oct 2016 09:42:25 +0200 Subject: [Freeipa-devel] [freeipa PR#164][comment] Trust AD cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/164 Title: #164: Trust AD cleanup martbab commented: """ You can disable the false positive error globally by adding file_exists method as a member of transport object in pylint_plugins.py line 240 """ See the full comment at https://github.com/freeipa/freeipa/pull/164#issuecomment-253731376 From freeipa-github-notification at redhat.com Fri Oct 14 08:07:08 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 14 Oct 2016 10:07:08 +0200 Subject: [Freeipa-devel] [freeipa PR#164][synchronized] Trust AD cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/164 Author: mirielka Title: #164: Trust AD cleanup Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/164/head:pr164 git checkout pr164 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-164.patch Type: text/x-diff Size: 4250 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 08:07:35 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 14 Oct 2016 10:07:35 +0200 Subject: [Freeipa-devel] [freeipa PR#164][comment] Trust AD cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/164 Title: #164: Trust AD cleanup mirielka commented: """ Thanks for suggestion, I added separate commit for this. """ See the full comment at https://github.com/freeipa/freeipa/pull/164#issuecomment-253735992 From freeipa-github-notification at redhat.com Fri Oct 14 09:12:47 2016 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Fri, 14 Oct 2016 11:12:47 +0200 Subject: [Freeipa-devel] [freeipa PR#126][synchronized] Fix ipa migrate-ds when it finds a search reference In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/126 Author: flo-renaud Title: #126: Fix ipa migrate-ds when it finds a search reference Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/126/head:pr126 git checkout pr126 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-126.patch Type: text/x-diff Size: 3828 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 09:29:06 2016 From: freeipa-github-notification at redhat.com (tjaalton) Date: Fri, 14 Oct 2016 11:29:06 +0200 Subject: [Freeipa-devel] [freeipa PR#127][comment] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension tjaalton commented: """ that's possible, I'm unable to find where to fix that though """ See the full comment at https://github.com/freeipa/freeipa/pull/127#issuecomment-253752558 From ofayans at redhat.com Fri Oct 14 09:36:49 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 14 Oct 2016 11:36:49 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <36a2eba5-a03d-131e-0042-46f0d4f0299a@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> <36a2eba5-a03d-131e-0042-46f0d4f0299a@redhat.com> Message-ID: <80d2ccd8-8e1b-52a7-df76-087c72f21a12@redhat.com> Right you are! I am sorry. On 10/13/2016 06:10 PM, Martin Basti wrote: > I think that you forgot to squash commits. Patch 47 doesn't apply > > > On 13.10.2016 14:01, Oleg Fayans wrote: >> Hi Martin, >> >> Thanks for the review. >> With disabling directory server it works as well, thanks for the hint. >> Also I moved the cleanup logic to the test itself for the sake of >> simplicity. Patch-0048 was not changed >> >> On 10/12/2016 02:35 PM, Martin Basti wrote: >>> 1) >>> >>> Can you just turn off dirsrv on replica instead of doing iptables magic? >>> >>> >>> 2) NACK >>> >>> No more eval() ever in code, use 'getattr', 'get' or whatever in the >>> object that can be used. >>> >>> + evalhost = eval("args[0].%s" % host) >>> >>> Martin^2 >>> >>> On 12.10.2016 14:03, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> After extensive discussion with Ludwig, I finally got the clue on how >>>> does this feature work. When we uninstall the replica, the master >>>> cleans the replication agreements with this replica and automatically >>>> cleans all replica's RUVs. >>>> If we clean replica's RUVs on master without uninstalling the replica, >>>> the replica's RUVs get recreated on master (replication works!). So, >>>> the only way to test the clean-ruv subcommand is to turn off the >>>> replica, or block the traffic on it so it gets inaccessible to updates >>>> from master. >>>> The testcases were updated, see [1] and [2] >>>> >>>> The updated versions of the patches are attached >>>> >>>> [1] >>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs >>>> >>>> >>>> >>>> [2] >>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand >>>> >>>> >>>> >>>> On 08/05/2016 06:36 PM, Martin Basti wrote: >>>>> >>>>> >>>>> On 03.08.2016 14:45, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> Thanks for the review! Both patches were updated. >>>>>> >>>>>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Thanks for the review! >>>>>>>> >>>>>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>>>>> before >>>>>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>>>>> feature. >>>>>>>>>> >>>>>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>>>>> One more test was added to the patch-0048 >>>>>>>>>>> >>>>>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>>>>> from >>>>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> IIUC, this will turn off the machine completely, how is cleanup >>>>>>>>> done >>>>>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>>>>> cleanup, so >>>>>>>>> you will not be able to run more tests on the same topology >>>>>>>>> without >>>>>>>>> manual cleanup and manual start. >>>>>>>>> >>>>>>>>> + replica = self.replicas[0] >>>>>>>>> + replica.run_command(['poweroff']) >>>>>>>>> >>>>>>>>> IMO would be better to just call 'ipactl stop' instead of >>>>>>>>> 'poweroff' >>>>>>>> >>>>>>>> Agreed! Fixed. >>>>>>>> >>>>>>>>> >>>>>>>>> Martin^2 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> *Automated ipa-replica-manage del tests* >>>>>>> >>>>>>> 1) >>>>>>> + replica.run_command(['ipactl', 'stop']) >>>>>>> + time.sleep(3) >>>>>>> >>>>>>> Why do you need sleep here? >>>>>> >>>>>> Removed, it was left from the old "poweroff" approach >>>>>> >>>>>>> >>>>>>> >>>>>>> 2) >>>>>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % >>>>>>> replica.hostname) >>>>>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>>>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', 'f', >>>>>>> + '-p', master.config.dirman_password, >>>>>>> + replica_ruvs[0]]) >>>>>>> >>>>>>> Because you are using re.findall(), without any match you will >>>>>>> receive >>>>>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>>>>> >>>>>> Implemented the assert which checks that the output contains enough >>>>>> replica RUVs >>>>>> >>>>>>> >>>>>>> 3) >>>>>>> assert(replica.hostname in result1.stdout_text) >>>>>>> >>>>>>> I think that this is error prone. What if there is just error >>>>>>> 'could not >>>>>>> connect to replica ', or something similar. >>>>>>> instead of >>>>>>> listing/cleaning/whatever operation was executed. I think that it >>>>>>> should >>>>>>> be more specific regexp than just finding a replica name substring >>>>>>> (Yes >>>>>>> In IPA we dont always print error so stderr) >>>>>>> >>>>>>> I'm not sure, but probably there might be cases when non critical >>>>>>> error >>>>>>> happen and exist status is still 0 >>>>>> >>>>>> Agree. Implemented a regex-based search >>>>>> >>>>>>> >>>>>>> 4) >>>>>>> >>>>>>> + replica.run_command(['poweroff']) >>>>>>> + time.sleep(3) >>>>>>> >>>>>>> There should not be poweroff, probably sleep could be removed too. >>>>>> >>>>>> Gone >>>>>> >>>>>>> >>>>>>> >>>>>>> * Automated clean-ruv subcommand test* >>>>>>> >>>>>>> 1) PEP8, 2 new lines expected >>>>>>> ./ipatests/test_integration/test_topology.py:163:1: E302 expected 2 >>>>>>> blank lines, found 0 >>>>>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>>>>> long >>>>>>> (85 > 79 characters) >>>>>> >>>>>> Fixed >>>>>> >>>>>>> >>>>>>> >>>>>>> 2) >>>>>>> I dont like doing assert just with count of occurences of >>>>>>> substring in >>>>>>> STDOUT, would be possible to improve this somehow? >>>>>> >>>>>> Maybe, but frankly, I don't see how. In this case we are making sure >>>>>> that both simple and CA-specific RUVs of a replica are displayed. The >>>>>> format of the output is strict: >>>>>> Replica Update Vectors: >>>>>> replica1_hostname:389: RUV_id >>>>>> replica2_hostname:389: RUV_id >>>>>> Certificate Server Replica Update Vectors: >>>>>> replica1_hostname:389: RUV_id >>>>>> replica2_hostname:389: RUV_id >>>>>> If we do not see 2 occurrences of the replica hostname than >>>>>> definitely >>>>>> something went wrong >>>>>> >>>>>>> >>>>>>> 3) >>>>>>> I'm not sure if clean-ruv is instant operations or there is some >>>>>>> magic >>>>>>> happening in background (we have abort-clean-ruv). Maybe some sleep >>>>>>> should be there, but this needs investigation. >>>>>>> >>>>>>> + assert(replica.hostname in result2.stdout_text), ( >>>>>>> + "The wrong RUV was deleted") >>>>>>> + result3 = master.run_command(['ipa-replica-manage', >>>>>>> 'list-ruv', >>>>>>> + '-p', >>>>>>> master.config.dirman_password]) >>>>>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>>>>> + "CA RUV of the replica is still displayed") >>>>>>> >>>>>> >>>>>> Based on my discussion with Stanislav Laznicka, I understood that by >>>>>> default clean-ruv does not return the shell until the operation is >>>>>> finished. You can force dropping into the shell by pressing >>>>>> CTRL+C, in >>>>>> which case the background job will still be running, but this is not >>>>>> the default behavior >>>>>> >>>>> Test failed: >>>>> result4 = master.run_command(['ipa-replica-manage', >>>>> 'list-ruv', >>>>> '-p', >>>>> master.config.dirman_password]) >>>>>> assert(replica.hostname not in result4.stdout_text), ( >>>>> "replica's RUV is still displayed") >>>>> E AssertionError: replica's RUV is still displayed >>>>> E assert 'replica3.ipa.test' not in 'Replica Update >>>>> V...ipa.test:389: 8\n' >>>>> E 'replica3.ipa.test' is contained here: >>>>> E Replica Update Vectors: >>>>> E \tmaster.ipa.test:389: 4 >>>>> E \treplica3.ipa.test:389: 3 >>>>> E \treplica2.ipa.test:389: 7 >>>>> E Certificate Server Replica Update Vectors: >>>>> E \tmaster.ipa.test:389: 6 >>>>> E \treplica2.ipa.test:389: 8 >>>>> >>>>> >>>>> [root at master ~]# ipa topologysegment-find >>>>> Suffix name: domain >>>>> ------------------ >>>>> 2 segments matched >>>>> ------------------ >>>>> Segment name: master.ipa.test-to-replica2.ipa.test >>>>> Left node: master.ipa.test >>>>> Right node: replica2.ipa.test >>>>> Connectivity: both >>>>> >>>>> Segment name: master.ipa.test-to-replica3.ipa.test >>>>> Left node: master.ipa.test >>>>> Right node: replica3.ipa.test >>>>> Connectivity: both >>>>> ---------------------------- >>>>> Number of entries returned 2 >>>>> ---------------------------- >>>>> [root at master ~]# ipa-replica-manage list-ruv >>>>> Directory Manager password: >>>>> >>>>> Replica Update Vectors: >>>>> master.ipa.test:389: 4 >>>>> replica2.ipa.test:389: 7 >>>>> replica3.ipa.test:389: 3 >>>>> Certificate Server Replica Update Vectors: >>>>> master.ipa.test:389: 6 >>>>> replica2.ipa.test:389: 8 >>>>> [root at master ~]# >>>>> >>>>> Then I tried manually to clean RUV 3, and it behaves somehow odd >>>>> >>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>> 'Secret123' '-f' >>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>> Background task created to clean replication data. This may take a >>>>> while. >>>>> This may be safely interrupted with Ctrl+C >>>>> Cleanup task created >>>>> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >>>>> [root at master ~]# ipa-replica-manage list-ruv >>>>> Directory Manager password: >>>>> >>>>> Replica Update Vectors: >>>>> master.ipa.test:389: 4 >>>>> replica2.ipa.test:389: 7 >>>>> replica3.ipa.test:389: 3 >>>>> Certificate Server Replica Update Vectors: >>>>> master.ipa.test:389: 6 >>>>> replica2.ipa.test:389: 8 >>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>> 'Secret123' '-f' >>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>> CLEANALLRUV task for replica id 3 already exists. >>>>> This may be safely interrupted with Ctrl+C >>>>> Cleanup task created >>>>> >>>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>>> No CLEANALLRUV tasks running >>>>> >>>>> No abort CLEANALLRUV tasks running >>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>> 'Secret123' '-f' >>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>> Background task created to clean replication data. This may take a >>>>> while. >>>>> This may be safely interrupted with Ctrl+C >>>>> Cleanup task created >>>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>>> CLEANALLRUV tasks >>>>> RID 3: Successfully cleaned rid(3). >>>>> >>>>> No abort CLEANALLRUV tasks running >>>>> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >>>>> Replica Update Vectors: >>>>> master.ipa.test:389: 4 >>>>> replica2.ipa.test:389: 7 >>>>> Certificate Server Replica Update Vectors: >>>>> master.ipa.test:389: 6 >>>>> replica2.ipa.test:389: 8 >>>>> >>>>> >>>>> I'm not sure if this behavior is right, Ludwig may know. >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0047.5-Automated-clean-ruv-subcommand-tests.patch Type: text/x-patch Size: 4522 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 09:57:23 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Fri, 14 Oct 2016 11:57:23 +0200 Subject: [Freeipa-devel] [freeipa PR#165][opened] Tests: Verify that cert-find show CA without --all Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Author: mirielka Title: #165: Tests: Verify that cert-find show CA without --all Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6151 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/165/head:pr165 git checkout pr165 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-165.patch Type: text/x-diff Size: 1113 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 10:52:54 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 14 Oct 2016 12:52:54 +0200 Subject: [Freeipa-devel] [freeipa PR#127][comment] Move ipa-otpd to $libexecdir/ipa, purge ffextension In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/127 Title: #127: Move ipa-otpd to $libexecdir/ipa, purge ffextension martbab commented: """ I have opened a bug against selinux-policy for this https://bugzilla.redhat.com/show_bug.cgi?id=1384872 """ See the full comment at https://github.com/freeipa/freeipa/pull/127#issuecomment-253769422 From bind-dyndb-ldap-github-notification at redhat.com Fri Oct 14 11:01:15 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Fri, 14 Oct 2016 13:01:15 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][closed] fix ldif syntax and add idnsTemplateAttribute In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Author: stutiredboy Title: #2: fix ldif syntax and add idnsTemplateAttribute Action: closed To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/2/head:pr2 git checkout pr2 From bind-dyndb-ldap-github-notification at redhat.com Fri Oct 14 11:01:17 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Fri, 14 Oct 2016 13:01:17 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][comment] fix ldif syntax and add idnsTemplateAttribute In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Title: #2: fix ldif syntax and add idnsTemplateAttribute pspacek commented: """ Thanks! I've commited the fix as 17711141882aca3847a5daba2292bcbcc471ec63. """ See the full comment at https://github.com/freeipa/bind-dyndb-ldap/pull/2#issuecomment-253770929 From freeipa-github-notification at redhat.com Fri Oct 14 11:04:45 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Fri, 14 Oct 2016 13:04:45 +0200 Subject: [Freeipa-devel] [freeipa PR#116][synchronized] Added fix for no-hbac-allow option in server install script In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Author: Akasurde Title: #116: Added fix for no-hbac-allow option in server install script Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/116/head:pr116 git checkout pr116 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-116.patch Type: text/x-diff Size: 1818 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 11:05:38 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Fri, 14 Oct 2016 13:05:38 +0200 Subject: [Freeipa-devel] [freeipa PR#116][edited] Add fix for no-hbac-allow option in server install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Author: Akasurde Title: #116: Add fix for no-hbac-allow option in server install Action: edited Changed field: title Original value: """ Added fix for no-hbac-allow option in server install script """ From freeipa-github-notification at redhat.com Fri Oct 14 11:41:02 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 14 Oct 2016 13:41:02 +0200 Subject: [Freeipa-devel] [freeipa PR#145][synchronized] [WIP] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Author: tomaskrizek Title: #145: [WIP] Refactoring: LDAP Connection Management Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/145/head:pr145 git checkout pr145 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-145.patch Type: text/x-diff Size: 124365 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 14 11:47:23 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 14 Oct 2016 13:47:23 +0200 Subject: [Freeipa-devel] [freeipa PR#145][comment] [WIP] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Title: #145: [WIP] Refactoring: LDAP Connection Management tomaskrizek commented: """ I made some changes and removed the connection manager, as discussed with sub-team. The refactoring is not finished, but these changes can be pushed to master if it doesn't break any working tests. Jobs are currently pending in jenkins. """ See the full comment at https://github.com/freeipa/freeipa/pull/145#issuecomment-253778858 From freeipa-github-notification at redhat.com Fri Oct 14 11:47:39 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 14 Oct 2016 13:47:39 +0200 Subject: [Freeipa-devel] [freeipa PR#145][edited] [WIP] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Author: tomaskrizek Title: #145: [WIP] Refactoring: LDAP Connection Management Action: edited Changed field: body Original value: """ PREVIEW, please don't merge yet Design doc: http://www.freeipa.org/page/V4/LDAP_Connection_Management_Refactoring Many changes in current PR are only temporary for easier refactoring, but feedback is welcome. """ From freeipa-github-notification at redhat.com Fri Oct 14 11:47:43 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 14 Oct 2016 13:47:43 +0200 Subject: [Freeipa-devel] [freeipa PR#145][edited] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Author: tomaskrizek Title: #145: Refactoring: LDAP Connection Management Action: edited Changed field: title Original value: """ [WIP] Refactoring: LDAP Connection Management """ From freeipa-github-notification at redhat.com Fri Oct 14 12:24:47 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 14 Oct 2016 14:24:47 +0200 Subject: [Freeipa-devel] [freeipa PR#116][comment] Add fix for no-hbac-allow option in server install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Title: #116: Add fix for no-hbac-allow option in server install tomaskrizek commented: """ LGTM, thanks for the patch! """ See the full comment at https://github.com/freeipa/freeipa/pull/116#issuecomment-253785497 From freeipa-github-notification at redhat.com Fri Oct 14 12:24:50 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 14 Oct 2016 14:24:50 +0200 Subject: [Freeipa-devel] [freeipa PR#116][+ack] Add fix for no-hbac-allow option in server install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Title: #116: Add fix for no-hbac-allow option in server install Label: +ack From freeipa-github-notification at redhat.com Fri Oct 14 13:41:32 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 14 Oct 2016 15:41:32 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all tomaskrizek commented: """ The same check should be also performed for `cert-show`. The patch also added CA to `cert-request` command, but testing it is probably not worth the effort, since it requires a CSR file. """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-253801847 From ofayans at redhat.com Fri Oct 14 13:48:25 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 14 Oct 2016 15:48:25 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: References: <57A07FE4.8000904@redhat.com> <2b0ed7fe-f0bc-7137-bdc1-b0758ffe9cd6@redhat.com> <20160914154119.mkk2ma7tvks55xsu@redhat.com> <97eaa313-e889-cd4a-e900-9e88596577a0@redhat.com> <20160914155320.iowrijrq3z62evoo@redhat.com> <1af52e6c-c24b-d58b-ccf5-a85c5c290e0c@redhat.com> <20160914165348.GE2761@p.Speedport_W_724V_Typ_A_05011603_00_009> <59763ea7-2ab5-bdc2-72c1-489a462f78ef@redhat.com> Message-ID: So, did I understand correctly, that there would be 2 patches: one containing test for basic idoverrides functionality without AD-integration, and the second one - with AD-integration and an sssd check, correct? I guess, the freeipa-ofayans-0050.1-Automated-test-for-certs-in-idoverrides-feature.patch might be a good candidate for the first one, I only have to change the filename to test_idviews.py, right? On 09/15/2016 10:32 AM, Martin Basti wrote: > > > On 15.09.2016 10:10, Oleg Fayans wrote: >> Hi Martin, >> >> The file was renamed. Did I understand correctly that for now we are >> leaving the test as is and are planning to extend it later? > > I would like to have there SSSD check involved, please use what Summit > recommends. No new test cases. > > And this can be done by separate patch, I want to have API/CLI > certificate override tests for non-AD idview (extending current tests I > posted in this thread) > > Martin^2 >> >> On 09/15/2016 09:49 AM, Martin Basti wrote: >>> >>> >>> On 14.09.2016 18:53, Sumit Bose wrote: >>>> On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote: >>>>> >>>>> On 14.09.2016 17:53, Alexander Bokovoy wrote: >>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>> >>>>>>> On 14.09.2016 17:41, Alexander Bokovoy wrote: >>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>> 1) >>>>>>>>> I still don't see the reason why AD trust is needed. Default >>>>>>>>> trust ID view is added just by ipa-adtrust-install, adding >>>>>>>>> trust is not needed for current implementation. You don't >>>>>>>>> need AD for this, IDviews is generic feature not just for >>>>>>>>> AD. Is that user configured on AD side? >>>>>>>> You cannot add non-AD user to 'default trust view', so you will >>>>>>>> not be >>>>>>>> able to set up certificates to ID override which does not exist. >>>>>>>> >>>>>>>> For non-'default trust view' you can add both IPA and AD users, >>>>>>>> so using >>>>>>>> some other view and then assign certificate for a ID override in >>>>>>>> that >>>>>>>> one. >>>>>>>> >>>>>>> Ok then, but anyway I would like to see API/CLI tests for this >>>>>>> feature with proper output validation. >>>>>>> >>>>>>> >>>>>>> How can be this tested with SSSD? >>>>>> You need to log into the system with a certificate... >>>>> Is this possible from test? We are logged remotely as root, is >>>>> there any >>>>> cmdline util which allows us to test certificate against AD user? >>>> >>>> You can use 'sss_ssh_authorizedkeys aduser at ad.domain' which should >>>> return the ssh key derived from the public key in the certificate. This >>>> should work for certificate stored in AD as well as for overrides. >>>> >>>> You can also you the DBus lookup by certificate as described in >>>> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate >>>> . >>>> >>>> HTH >>>> >>>> bye, >>>> Sumit >>> >>> Thank you Alexander and Summit for hints. >>> >>> Oleg I realized we don't have any other idviews integration tests >>> >>> So I propose to rename test file you are adding to test_idviews.py. We >>> can add more testcases for idviews there later >>> >>> Martin^2 >>>>> 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 >>> >> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From mbabinsk at redhat.com Fri Oct 14 13:57:50 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 14 Oct 2016 15:57:50 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: References: <57A07FE4.8000904@redhat.com> <2b0ed7fe-f0bc-7137-bdc1-b0758ffe9cd6@redhat.com> <20160914154119.mkk2ma7tvks55xsu@redhat.com> <97eaa313-e889-cd4a-e900-9e88596577a0@redhat.com> <20160914155320.iowrijrq3z62evoo@redhat.com> <1af52e6c-c24b-d58b-ccf5-a85c5c290e0c@redhat.com> <20160914165348.GE2761@p.Speedport_W_724V_Typ_A_05011603_00_009> <59763ea7-2ab5-bdc2-72c1-489a462f78ef@redhat.com> Message-ID: On 10/14/2016 03:48 PM, Oleg Fayans wrote: > So, did I understand correctly, that there would be 2 patches: one > containing test for basic idoverrides functionality without > AD-integration, and the second one - with AD-integration and an sssd > check, correct? > I guess, the > freeipa-ofayans-0050.1-Automated-test-for-certs-in-idoverrides-feature.patch > might be a good candidate for the first one, I only have to change the > filename to test_idviews.py, right? > Oleg, we already have XMLRPC tests for idoverrides: ipatests/test_xmlrpc/test_idviews_plugin.py Is there any particular reason why not to extend them with add cert/remove cert operations? Even better, you can extend `ipatests/test_xmlrpc/test_add_remove_cert_cmd.py` suite by doing the same set of tests on idoverrideuser objects. Or am I missing something? > On 09/15/2016 10:32 AM, Martin Basti wrote: >> >> >> On 15.09.2016 10:10, Oleg Fayans wrote: >>> Hi Martin, >>> >>> The file was renamed. Did I understand correctly that for now we are >>> leaving the test as is and are planning to extend it later? >> >> I would like to have there SSSD check involved, please use what Summit >> recommends. No new test cases. >> >> And this can be done by separate patch, I want to have API/CLI >> certificate override tests for non-AD idview (extending current tests I >> posted in this thread) >> >> Martin^2 >>> >>> On 09/15/2016 09:49 AM, Martin Basti wrote: >>>> >>>> >>>> On 14.09.2016 18:53, Sumit Bose wrote: >>>>> On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote: >>>>>> >>>>>> On 14.09.2016 17:53, Alexander Bokovoy wrote: >>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>> >>>>>>>> On 14.09.2016 17:41, Alexander Bokovoy wrote: >>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>> 1) >>>>>>>>>> I still don't see the reason why AD trust is needed. Default >>>>>>>>>> trust ID view is added just by ipa-adtrust-install, adding >>>>>>>>>> trust is not needed for current implementation. You don't >>>>>>>>>> need AD for this, IDviews is generic feature not just for >>>>>>>>>> AD. Is that user configured on AD side? >>>>>>>>> You cannot add non-AD user to 'default trust view', so you will >>>>>>>>> not be >>>>>>>>> able to set up certificates to ID override which does not exist. >>>>>>>>> >>>>>>>>> For non-'default trust view' you can add both IPA and AD users, >>>>>>>>> so using >>>>>>>>> some other view and then assign certificate for a ID override in >>>>>>>>> that >>>>>>>>> one. >>>>>>>>> >>>>>>>> Ok then, but anyway I would like to see API/CLI tests for this >>>>>>>> feature with proper output validation. >>>>>>>> >>>>>>>> >>>>>>>> How can be this tested with SSSD? >>>>>>> You need to log into the system with a certificate... >>>>>> Is this possible from test? We are logged remotely as root, is >>>>>> there any >>>>>> cmdline util which allows us to test certificate against AD user? >>>>> >>>>> You can use 'sss_ssh_authorizedkeys aduser at ad.domain' which should >>>>> return the ssh key derived from the public key in the certificate. >>>>> This >>>>> should work for certificate stored in AD as well as for overrides. >>>>> >>>>> You can also you the DBus lookup by certificate as described in >>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate >>>>> . >>>>> >>>>> HTH >>>>> >>>>> bye, >>>>> Sumit >>>> >>>> Thank you Alexander and Summit for hints. >>>> >>>> Oleg I realized we don't have any other idviews integration tests >>>> >>>> So I propose to rename test file you are adding to test_idviews.py. We >>>> can add more testcases for idviews there later >>>> >>>> Martin^2 >>>>>> 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 >>>> >>> >>> >>> >> >> >> > -- Martin^3 Babinsky From freeipa-github-notification at redhat.com Fri Oct 14 14:00:37 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Fri, 14 Oct 2016 16:00:37 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all pvoborni commented: """ that reminds me this regression in cert-show: https://fedorahosted.org/freeipa/ticket/6022#comment:6 """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-253807613 From ofayans at redhat.com Fri Oct 14 14:58:15 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 14 Oct 2016 16:58:15 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: References: <57A07FE4.8000904@redhat.com> <2b0ed7fe-f0bc-7137-bdc1-b0758ffe9cd6@redhat.com> <20160914154119.mkk2ma7tvks55xsu@redhat.com> <97eaa313-e889-cd4a-e900-9e88596577a0@redhat.com> <20160914155320.iowrijrq3z62evoo@redhat.com> <1af52e6c-c24b-d58b-ccf5-a85c5c290e0c@redhat.com> <20160914165348.GE2761@p.Speedport_W_724V_Typ_A_05011603_00_009> <59763ea7-2ab5-bdc2-72c1-489a462f78ef@redhat.com> Message-ID: <1f59e1b6-9985-b7fa-dc71-bcac88991984@redhat.com> Hi, Martin, Right. The point is to have a test that emulates the real-world usecase of this feature. Which is AD integration. No xmlrpc test is able to do so. Of course we can automate testing of CLI options using XMLRPC. But that would not mean we do not need an integration test for the "real" part. So, I'll add the cert manipulation tests to the xmlrpc test. On 10/14/2016 03:57 PM, Martin Babinsky wrote: > On 10/14/2016 03:48 PM, Oleg Fayans wrote: >> So, did I understand correctly, that there would be 2 patches: one >> containing test for basic idoverrides functionality without >> AD-integration, and the second one - with AD-integration and an sssd >> check, correct? >> I guess, the >> freeipa-ofayans-0050.1-Automated-test-for-certs-in-idoverrides-feature.patch >> >> might be a good candidate for the first one, I only have to change the >> filename to test_idviews.py, right? >> > > Oleg, we already have XMLRPC tests for idoverrides: > > ipatests/test_xmlrpc/test_idviews_plugin.py > > Is there any particular reason why not to extend them with add > cert/remove cert operations? > > Even better, you can extend > `ipatests/test_xmlrpc/test_add_remove_cert_cmd.py` suite by doing the > same set of tests on idoverrideuser objects. > > Or am I missing something? > >> On 09/15/2016 10:32 AM, Martin Basti wrote: >>> >>> >>> On 15.09.2016 10:10, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> The file was renamed. Did I understand correctly that for now we are >>>> leaving the test as is and are planning to extend it later? >>> >>> I would like to have there SSSD check involved, please use what Summit >>> recommends. No new test cases. >>> >>> And this can be done by separate patch, I want to have API/CLI >>> certificate override tests for non-AD idview (extending current tests I >>> posted in this thread) >>> >>> Martin^2 >>>> >>>> On 09/15/2016 09:49 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 14.09.2016 18:53, Sumit Bose wrote: >>>>>> On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote: >>>>>>> >>>>>>> On 14.09.2016 17:53, Alexander Bokovoy wrote: >>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 14.09.2016 17:41, Alexander Bokovoy wrote: >>>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>>> 1) >>>>>>>>>>> I still don't see the reason why AD trust is needed. Default >>>>>>>>>>> trust ID view is added just by ipa-adtrust-install, adding >>>>>>>>>>> trust is not needed for current implementation. You don't >>>>>>>>>>> need AD for this, IDviews is generic feature not just for >>>>>>>>>>> AD. Is that user configured on AD side? >>>>>>>>>> You cannot add non-AD user to 'default trust view', so you will >>>>>>>>>> not be >>>>>>>>>> able to set up certificates to ID override which does not exist. >>>>>>>>>> >>>>>>>>>> For non-'default trust view' you can add both IPA and AD users, >>>>>>>>>> so using >>>>>>>>>> some other view and then assign certificate for a ID override in >>>>>>>>>> that >>>>>>>>>> one. >>>>>>>>>> >>>>>>>>> Ok then, but anyway I would like to see API/CLI tests for this >>>>>>>>> feature with proper output validation. >>>>>>>>> >>>>>>>>> >>>>>>>>> How can be this tested with SSSD? >>>>>>>> You need to log into the system with a certificate... >>>>>>> Is this possible from test? We are logged remotely as root, is >>>>>>> there any >>>>>>> cmdline util which allows us to test certificate against AD user? >>>>>> >>>>>> You can use 'sss_ssh_authorizedkeys aduser at ad.domain' which should >>>>>> return the ssh key derived from the public key in the certificate. >>>>>> This >>>>>> should work for certificate stored in AD as well as for overrides. >>>>>> >>>>>> You can also you the DBus lookup by certificate as described in >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate >>>>>> >>>>>> . >>>>>> >>>>>> HTH >>>>>> >>>>>> bye, >>>>>> Sumit >>>>> >>>>> Thank you Alexander and Summit for hints. >>>>> >>>>> Oleg I realized we don't have any other idviews integration tests >>>>> >>>>> So I propose to rename test file you are adding to test_idviews.py. We >>>>> can add more testcases for idviews there later >>>>> >>>>> Martin^2 >>>>>>> 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 >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From freeipa-github-notification at redhat.com Fri Oct 14 16:32:31 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Fri, 14 Oct 2016 18:32:31 +0200 Subject: [Freeipa-devel] [freeipa PR#116][comment] Add fix for no-hbac-allow option in server install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Title: #116: Add fix for no-hbac-allow option in server install Akasurde commented: """ @tomaskrizek @stlaz @jcholast Thanks for review comments. """ See the full comment at https://github.com/freeipa/freeipa/pull/116#issuecomment-253852546 From freeipa-github-notification at redhat.com Fri Oct 14 17:34:47 2016 From: freeipa-github-notification at redhat.com (simo5) Date: Fri, 14 Oct 2016 19:34:47 +0200 Subject: [Freeipa-devel] [freeipa PR#117][comment] Make ipa-replica-install run in interactive mode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/117 Title: #117: Make ipa-replica-install run in interactive mode simo5 commented: """ @stlaz I do not understand the rationale. Ideally the ipa-replica-install command gathers all necessary info and ipa-client-install is always run in unattended mode. """ See the full comment at https://github.com/freeipa/freeipa/pull/117#issuecomment-253868897 From freeipa-github-notification at redhat.com Fri Oct 14 20:44:50 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 14 Oct 2016 22:44:50 +0200 Subject: [Freeipa-devel] [freeipa PR#117][comment] Make ipa-replica-install run in interactive mode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/117 Title: #117: Make ipa-replica-install run in interactive mode stlaz commented: """ @simo5: There is a LOT of checking of various combinations of options in ipa-client-install, not even mentioning IPADiscovery in interactive mode. It does not make sense to copy-paste all/most of it. Note that this patch may be obsoleted by the installers refactoring effort as the ticket was moved to 4.5 release. """ See the full comment at https://github.com/freeipa/freeipa/pull/117#issuecomment-253914584 From jcholast at redhat.com Mon Oct 17 06:16:21 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Oct 2016 08:16:21 +0200 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> <57BF50E1.8030209@redhat.com> <82017bee-a989-cbe5-d5ed-f481441269e6@redhat.com> Message-ID: On 13.10.2016 17:23, Ben Lipton wrote: > Thank you, this was a really helpful clarification of your point. > Comments below. Once again, I'm sorry I missed the email for so long. > > Ben > > On 09/05/2016 06:52 AM, Jan Cholasta wrote: >> On 27.8.2016 22:40, Ben Lipton wrote: >>> On 08/25/2016 04:11 PM, Rob Crittenden wrote: >>>> Ben Lipton wrote: >>>>> On 08/23/2016 03:54 AM, Jan Cholasta wrote: >>>>>> On 8.8.2016 22:23, Ben Lipton wrote: >>>>>>> On 07/25/2016 07:45 AM, Jan Cholasta wrote: >>>>>>>> On 25.7.2016 13:11, Alexander Bokovoy wrote: >>>>>>>>> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>>>>>>> On 20.7.2016 16:05, Ben Lipton wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Thanks very much for the feedback! Some responses below; I hope >>>>>>>>>>> you'll >>>>>>>>>>> let me know what you think of my reasoning. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>>>>>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>>>>>>>>> Hello all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have written up a design proposal for making certificate >>>>>>>>>>>>>> requests >>>>>>>>>>>>>> easier to generate when using alternate certificate profiles: >>>>>>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The use case for this is described in >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be >>>>>>>>>>>>>> working on >>>>>>>>>>>>>> implementing this design over the next couple of months. >>>>>>>>>>>>>> If you >>>>>>>>>>>>>> have >>>>>>>>>>>>>> the time and interest, please take a look and share any >>>>>>>>>>>>>> comments or >>>>>>>>>>>>>> concerns that you have. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ben >>>>>>>>>>>>>> >>>>>>>>>>>>> Just a quick update to say that I've created a new document >>>>>>>>>>>>> that >>>>>>>>>>>>> covers >>>>>>>>>>>>> the proposed schema additions in a more descriptive way (with >>>>>>>>>>>>> diagrams!) >>>>>>>>>>>>> I'm very new to developing with LDAP, so some more experienced >>>>>>>>>>>>> eyes on >>>>>>>>>>>>> the proposal would be very helpful, even if you don't have >>>>>>>>>>>>> time to >>>>>>>>>>>>> absorb the full design. Please take a look at >>>>>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> if you have a chance. >>>>>>>>>>>> >>>>>>>>>>>> I finally had a chance to take a look at this, here are some >>>>>>>>>>>> comments: >>>>>>>>>>>> >>>>>>>>>>>> 1) I don't like how transformation rules are tied to a >>>>>>>>>>>> particular >>>>>>>>>>>> helper and have to be duplicated for each of them. They >>>>>>>>>>>> should be >>>>>>>>>>>> generic and work with any helper, as helpers are just an >>>>>>>>>>>> implementation detail and their resulting data is the same. >>>>>>>>>>>> >>>>>>>>>>>> In fact, I think I would prefer if the CSR was generated using >>>>>>>>>>>> python-cryptography's CertificateSigningRequestBuilder [1] >>>>>>>>>>>> rather >>>>>>>>>>>> than >>>>>>>>>>>> openssl or certutil or any other command line tool. >>>>>>>>>>>> >>>>>>>>>>> There are lots of tools that users might want to use to manage >>>>>>>>>>> their >>>>>>>>>>> private keys, so I don't know if we can assume that whatever >>>>>>>>>>> library we >>>>>>>>>>> prefer will actually be able to access the private key to sign a >>>>>>>>>>> CSR, >>>>>>>>>>> which is why I thought it would be useful to support more than >>>>>>>>>>> one. >>>>>>>>>> >>>>>>>>>> python-cryptography has the notion of backends, which allow it to >>>>>>>>>> support multiple crypto implementations. Upstream it currently >>>>>>>>>> supports only OpenSSL [2], but some work has been done on PKCS#11 >>>>>>>>>> backend [3], which provides support for HSMs and soft-tokens >>>>>>>>>> (like >>>>>>>>>> NSS >>>>>>>>>> databases). >>>>>>>>>> >>>>>>>>>> Alternatively, for NSS databases (and other "simple" cases), you >>>>>>>>>> can >>>>>>>>>> generate the private key with python-cryptography using the >>>>>>>>>> default >>>>>>>>>> backend, export it to a file and import the file to the target >>>>>>>>>> database, so you don't actually need the PKCS#11 backend for >>>>>>>>>> them. >>>>>>>>>> >>>>>>>>>> So, the only thing that's currently lacking is HSM support, but >>>>>>>>>> given >>>>>>>>>> that we don't support HSMs in IPA nor in certmonger, I don't >>>>>>>>>> think >>>>>>>>>> it's an issue for now. >>>>>>>>>> >>>>>>>>>>> The >>>>>>>>>>> purpose of the mapping rule is to tie together the >>>>>>>>>>> transformation >>>>>>>>>>> rules >>>>>>>>>>> that produce the same data into an object that's >>>>>>>>>>> implementation-agnostic, so that profiles referencing those >>>>>>>>>>> rules >>>>>>>>>>> are >>>>>>>>>>> automatically compatible with all the helper options. >>>>>>>>>> >>>>>>>>>> They are implementation-agnostic, as long as you consider >>>>>>>>>> `openssl` >>>>>>>>>> and `certutil` the only implementations :-) But I don't think >>>>>>>>>> this >>>>>>>>>> solution scales well to other possible implementations. >>>>>>>>>> >>>>>>>>>> Anyway, my main grudge is that the transformation rules shouldn't >>>>>>>>>> really be stored on and processed by the server. The server >>>>>>>>>> should >>>>>>>>>> know the *what* (mapping rules), but not the *how* >>>>>>>>>> (transformation >>>>>>>>>> rules). The *how* is an implementation detail and does not >>>>>>>>>> change in >>>>>>>>>> time, so there's no benefit in handling it on the server. It >>>>>>>>>> should be >>>>>>>>>> handled exclusively on the client, which I believe would also >>>>>>>>>> make >>>>>>>>>> the >>>>>>>>>> whole thing more robust (it would not be possible for a bug on >>>>>>>>>> the >>>>>>>>>> server to break all the clients). >>>>>>>>> This is a good point. However, for the scope of Ben's project >>>>>>>>> can we >>>>>>>>> limit it by openssl and certutil support? Otherwise Ben >>>>>>>>> wouldn't be >>>>>>>>> able >>>>>>>>> to complete the project in time. >>>>>>>> >>>>>>>> I'm fine with that, but I don't think it's up to me :-) >>>>>>>> >>>>>>>>> >>>>>>>>>>> This is turning out to be a common (and, I think, reasonable) >>>>>>>>>>> reaction >>>>>>>>>>> to the proposal. It is rather complex, and I worry that it >>>>>>>>>>> will be >>>>>>>>>>> difficult to configure. On the other hand, there is some hidden >>>>>>>>>>> complexity to enabling a simpler config format, as well. One of >>>>>>>>>>> the >>>>>>>>>>> goals of the project as it was presented to me was to allow the >>>>>>>>>>> creation >>>>>>>>>>> of profiles that add certificate extensions *that FreeIPA >>>>>>>>>>> doesn't >>>>>>>>>>> yet >>>>>>>>>>> know about*. With the current proposal, one only has to add a >>>>>>>>>>> rule >>>>>>>>>>> generating text that the helper will understand. >>>>>>>>>> >>>>>>>>>> ... which will be possible only as long as the helper >>>>>>>>>> understands the >>>>>>>>>> extension. Which it might not, thus the current proposal works >>>>>>>>>> only >>>>>>>>>> for *some* extensions that FreeIPA doesn't yet support. >>>>>>>>> We can go ad infinitum here but with any helper implementation, >>>>>>>>> be it >>>>>>>>> python-cryptography or anything else, you will need to have a >>>>>>>>> support >>>>>>>>> there as well. >>>>>>>> >>>>>>>> My point was that the current proposal is not any better than my >>>>>>>> proposal in this regard, as neither of them allows one to use an >>>>>>>> arbitrary extension. >>>>>>>> >>>>>>>>> The idea with unknown extensions was to allow mapping >>>>>>>>> their acceptance to a specific relationship between IPA objects >>>>>>>>> (optionally) and an input from the CSR. A simplest example would >>>>>>>>> be an >>>>>>>>> identity rule that would copy an ASN.1 encoded content from the >>>>>>>>> CSR to >>>>>>>>> the certificate. >>>>>>>>> >>>>>>>>> That's on the mapping side, not on the CSR generation side, but it >>>>>>>>> would >>>>>>>>> go similarly for the CSR if you would be able to enter unknown but >>>>>>>>> otherwise correct ASN.1 stream. There is no difference at which >>>>>>>>> helper >>>>>>>>> type we are talking about because all of them support inserting >>>>>>>>> ASN.1 >>>>>>>>> content. >>>>>>>>> >>>>>>>>>>> With your suggestion, >>>>>>>>>>> if there's a mapping between "san_directoryname" and the >>>>>>>>>>> corresponding >>>>>>>>>>> API calls or configuration lines, we need some way for users to >>>>>>>>>>> augment >>>>>>>>>>> that mapping without changing the code. If there's no >>>>>>>>>>> mapping, and >>>>>>>>>>> it's >>>>>>>>>>> just done with text processing, we need enough in the config >>>>>>>>>>> format to >>>>>>>>>>> be able to generate fairly complex structures: >>>>>>>>>>> >>>>>>>>>>> builder = >>>>>>>>>>> builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>>>>>>>> builder = >>>>>>>>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), >>>>>>>>>>> False) >>>>>>>>>>> >>>>>>>>>>> and we need to do it without it being equivalent to calling >>>>>>>>>>> eval() on >>>>>>>>>>> the config attributes. I'm not sure how to achieve this (is it >>>>>>>>>>> safe to >>>>>>>>>>> call getattr(x509, extensiontype)(value) where extensiontype and >>>>>>>>>>> value >>>>>>>>>>> are user-specified?) and it definitely would have to be tied >>>>>>>>>>> to a >>>>>>>>>>> particular library/tool. >>>>>>>>>> >>>>>>>>>> As I pointed out above, this needs to be figured out for the >>>>>>>>>> generic >>>>>>>>>> case for both the current proposal and my suggestion. >>>>>>> I have a proof of concept[1] for using openssl-based rules to add a >>>>>>> subject alt name extension without using openssl's knowledge of that >>>>>>> extension. It's not extremely pretty, and it took some trial and >>>>>>> error, >>>>>>> but no code changes. So, I think this actually is a difference >>>>>>> between >>>>>>> the two proposals. >>>>>> >>>>>> With the obvious catch being that it works only with OpenSSL, which >>>>>> might not work for everyone, e.g. when using HSMs or SmartCards, due >>>>>> to a limited PKCS#11 support in OpenSSL. >>>>> >>>>> Very true. Even certutil's equivalent feature (--extGeneric) doesn't >>>>> seem like it would work very well in this context, as you are supposed >>>>> to pass in an already-encoded extension, so text-based templating >>>>> wouldn't be able to do much. >>>> >>>> Yeah, I struggled with this myself. I ended up writing a pyasn1 script >>>> to generate the extension I needed, wrote that to a file, and passed >>>> it to certutil using: >>>> >>>> --extGeneric 2.5.29.17:not-critical:/path/to/msupn.der >>>> >>>>>> >>>>>>> >>>>>>> Next we have the easy case, extensions that we as FreeIPA developers >>>>>>> know are important and build support for. For these, the two >>>>>>> proposals >>>>>>> work equivalently well, but yours is simpler to configure because >>>>>>> the >>>>>>> knowledge of how to make a san_rfc822name is built into the library >>>>>>> instead of being stored on the server as a set of rules. >>>>>>> >>>>>>> Finally, we have the case of extensions that are known to the >>>>>>> helper, >>>>>>> but not to FreeIPA. In the existing proposal, new rules can be >>>>>>> written >>>>>>> to support these extensions under a particular helper. Further, >>>>>>> those >>>>>>> rules can be used by reference in many profiles, reducing >>>>>>> duplication of >>>>>>> effort/data/errors. >>>>>>> >>>>>>> As I understand it, the main objections in this thread are that >>>>>>> transformation rules are implementation (i.e. helper) specific data >>>>>>> stored in the IPA server, and that the system has several levels of >>>>>>> schema when it could just embed rules in the profile. But without >>>>>>> helper-specific rules, administrators could not take advantage of >>>>>>> the >>>>>>> additional extensions supported by the helper they are using. >>>>>> >>>>>> There is *no* advantage in forcing the user to choose between helpers >>>>>> which differ only in the set of limitations on the CSR they are able >>>>>> to produce. The user should specify a) where the private key is >>>>>> located and b) what profile to use, and that's it, it should just >>>>>> work. >>>>> Ok, this is a good point about usability. The user creating the CSR >>>>> shouldn't have to care about helpers, and I agree that the current way >>>>> they are exposed is clunky. I do think that an administrator creating >>>>> custom rules might want to take advantage of a helper, so they >>>>> wouldn't >>>>> need to understand the ASN.1 representation of their chosen >>>>> certificate >>>>> extension. Of course, the desired extension might not be supported by >>>>> the helper either. Since I don't know what specific extensions people >>>>> will want to use this for, I don't know how to balance the better >>>>> administrator experience of adding extensions via a helper with the >>>>> limited extension support. >>>>> >>>>> The original reason we arrived at the concept of "helpers" was to >>>>> support different ways of getting at private keys, but perhaps this >>>>> should not be the concern of the CSR data generator. In your opinion, >>>>> would it be sufficient to support just one key format (PKCS#12? PEM?) >>>>> and let the user deal with putting those keys into whatever >>>>> formats/databases they need? If that's ok, maybe we can stop having >>>>> *multiple* helpers, but if we want to replace helpers entirely I'm >>>>> still >>>>> not certain what to replace them with. >>>> >>>> I'd just add an option to specify the output format, e.g PEM, NSS, >>>> Java keystore, PKCS#12, whatever. You can probably get away with the >>>> first two for starters. Different output format is going to mean >>>> different options but that is probably not a big deal. >>> >>> My point was that if we want to get rid of all the helpers but one, or >>> replace helpers with something else entirely like somehow templating >>> ASN1 structures directly, it will get harder to support all those >>> formats (or even both of the first two). For example, if we drop >>> certutil as a helper, how will we sign CSRs with keys stored in NSS >>> databases? >> >> 1. get the public part of the key from the NSS database >> 2. construct a CertificationRequestInfo [1] from the template and the >> public key >> 3. sign the CertificationRequestInfo with NSS using the private key to >> get a CSR >> >> This is purely client side, will work with any crypto library (just >> substitute NSS for something else) and, if done right, using very >> little code. > > Ok, I like this. If an encoded CertificationRequestInfo is something we > can expect to be compatible with any reasonable library (it sounds like > it should be) then the library can be used client-side to do the > key-storage-specific parts. I'm going to try writing this data -> > encoded CertificationRequestInfo -> CSR flow to make sure it works as > well as it sounds. If it does, it will also be useful for the code I'm > working on right now to connect certmonger with the current version of > the CSR autogeneration tool. Note that this will most probably require calling C functions. You might want to look into python-cffi. >> >>>> >>>> Remember that the private key will be at rest for some period of time >>>> while the CSR is being approved. The key needs to be protected at that >>>> time. >>>> >>>> rob >>>> >>>>>> >>>>>>> And >>>>>>> without the separation of profiles from mapping rules in the schema, >>>>>>> rules would need to be copy+pasted among profiles, and grouping >>>>>>> rules >>>>>>> with the same effect under different helpers would be much >>>>>>> uglier. We >>>>>>> can and should discuss whether these are the right tradeoffs, but >>>>>>> this >>>>>>> is where those decisions came from. >>>>>>> >>>>>>>>>> >>>>>>>>>> OTOH, I think we could use GSER encoding of the extension value: >>>>>>>>>> >>>>>>>>>> { rfc822Name:"user at example.com", >>>>>>>>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>>>>>>>> GSER is not really used widely and does not have standardized >>>>>>>>> encoding >>>>>>>>> rules beyond its own definition. If you want to allow >>>>>>>>> transformation >>>>>>>>> rules in GSER that mention existing content in IPA objects, you >>>>>>>>> would >>>>>>>>> need to deal with templating anyway. At this point it becomes >>>>>>>>> irrelevant >>>>>>>>> what you are templating, though. >>>>>>>> >>>>>>>> True, but the goal here is not to avoid templating, but rather to >>>>>>>> avoid implementation-specific bits on the server, and GSER is the >>>>>>>> only >>>>>>>> thing that is textual, implementation-neutral and, as a bonus, >>>>>>>> standardized. >>>>>>>> >>>>>>> As I said elsewhere, we could use GSER as a textual output format >>>>>>> instead of openssl or certutil, but it still needs its own >>>>>>> "helper" to >>>>>>> build the CSR, and unlike the other options, it seems like we might >>>>>>> need >>>>>>> to implement that helper. I'm not sure it's fair to call it >>>>>>> implementation-neutral if no implementation exists yet :) >>>>>> >>>>>> Right. Like I said, using GSER was just a quick idea off the top >>>>>> of my >>>>>> head. I would actually rather use some sort of data structure >>>>>> templating rather than textual templating on top of any kind of >>>>>> textual representation of said data structures. I don't know if there >>>>>> is such a thing, though. >>>>> >>>>> This sounds interesting, can you give an example of what this might >>>>> look >>>>> like? >> >> It would be something like XSLT, but for ASN.1 rather than XML. >> >>>>> >>>>> I learned that there's also an XML encoding for ASN.1, XER, but that's >>>>> still a textual representation and we'd have to insert the data >>>>> textually. >> >> Well, yes and no. While it's true that it's still a textual >> representation, what really makes a difference is that for XML, there >> is a templating mechanism which understands the structure of the data >> (XLST, as mentioned above). >> >> Unforutantely, XER has the same shortcoming as GSER: to be able to >> convert it to DER, you need to know the ASN.1 definition of the data >> structure. If we used XER+XSLT, we would also have to provide means of >> adding custom ASN.1 definitions and run them through ASN.1 compiler to >> convert between XER and DER. > > This is a little disappointing, but it makes sense. I don't think I > realized that we'll need to compile the ASN.1 data definitions for any > extensions we want to use in a cert. That limitation didn't come up when > we were only talking about extensions that were supported by the helper > utility. But providing the ASN.1 spec for unusual extensions an admin > wants to use in their certs is probably a reasonable expectation. Yes, that's what I think as well. It could be a simple IPA object with name, description, extension OID and the ASN.1 definition. >> >>>>> It doesn't seem to be supported by any python libraries, >>>>> either, but it does look like it's supported by the asn1 compiler >>>>> in the >>>>> IPA source distribution.I could imagine an implementation that builds >>>>> an XML representation of the CSR via python templating, then makes a >>>>> signed CSR out of it in C. I'm a little concerned about it because it >>>>> would have to implement the whole CSR structure from scratch, but is >>>>> this a prototype that you'd be interested in seeing? >> >> I can imagine something like this might work: >> >> 1. (client) generate a key pair >> 2. (client) get SubjectPublicKeyInfo [2] for the public key >> 3. (client) encode the SubjectPublicKeyInfo as XER using asn1c and >> python-cffi in API mode [3] >> 4. (client) call server to construct CertificationRequestInfo for >> specified subject from a specified template and the SubjectPublicKeyInfo >> 5. (server) get the subject's LDAP entry >> 6. (server) create a XML document which contains the subject's LDAP >> attributes and the SubjectPublicKeyInfo >> 7. (server) use XSLT to transform the XML document to >> CertificationRequestInfo using the specified template >> 8. (server) return the CertificationRequestInfo to the client >> 9. (client) convert the CertificationRequestInfo from XER to DER using >> asn1c and python-cffi in API mode >> 10. (client) sign the CertificationRequestInfo using the private key >> to get a CSR >> >> It would be better if the XER-DER conversion was done on the server, >> but I don't think that compiling and running code on the fly on the >> server is a particularly good idea. Apparently there is a ASN.1 >> compiler available for PyASN1 [4], maybe that could be used instead, >> but we would have to write a XER codec for PyASN1 ourselves (which >> shouldn't be too hard IMO). > > Yeah, running programs compiled from arbitrary ASN.1 seems like a risk. > Maybe a little better because the ASN.1 is provided by an administrator, > but we'd still be depending a lot on the security of the generated code. > On the other hand, if we compile on the client, the CSR generation > feature is limited to platforms where asn1c can be installed. I wish I > could think of a way to do the compilation once when the profile is > created, but run it on the client. That seems like asking for > compatibility problems, though... It seems you missed the most important thing in the above paragraph :-) - that is asn1ate, the PyASN1-based compiler. The nice thing about it is that it compiles the ASN.1 definition into a PyASN1 type object, which means you can compile the definition and use it to (un)parse data in the same Python program. If we used it, we could JIT-compile the ASN.1 definitions on the server, without the security risk of executing native code and without the compatibility issues of compilation on the client. I did a little research since my last email, and there is also another library which allows you to compile and use ASN.1 definitions on the fly - libtasn1 [5]. Compared to asn1ate, it seems to be pretty stable (asn1ate is currently in alpha) and is written in C, so it makes it possible to use the administrator-defined extensions outside of IPA (specifically, it could be useful for certificate matching and mapping [6] in SSSD). > >> >>>>> >>> On further investigation, it turns out the version of >>> python-cryptography in F24 includes a feature allowing arbitrary >>> extensions to be added by adding an UnrecognizedExtension to the >>> CertificateSigningRequestBuilder. This makes me feel somewhat better >>> both about python-cryptography as a tool for this task and about the >>> solution I just proposed. But I still don't have a clear idea that >>> answers 1) how to make templates that we can turn into encoded >>> extensions, and 2) how to deal with all the desired key formats. >> >> I hope the above clarifies these a little bit. >> >> [1] >> [2] >> [3] >> [4] [5] [6] -- Jan Cholasta From pspacek at redhat.com Mon Oct 17 07:02:23 2016 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 17 Oct 2016 09:02:23 +0200 Subject: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server? In-Reply-To: <20160927123134.GA32730@redhat.com> References: <20160921100144.GA7371@redhat.com> <20160927123134.GA32730@redhat.com> Message-ID: <02227e30-dfcf-30c1-8a26-5a356e2f0f87@redhat.com> On 27.9.2016 14:31, Jan Pazdziora wrote: > On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote: >> >> I've recently hit again the situation of IPA installer not happy >> about the provided IP address not being local to it, this time in >> containerized environment: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1377973 >> >> During the discussion, we came to an interesting question: >> >> What would break if loopback addresses were allowed for IPA >> server? >> >> Of course, the idea is that it would only be used for installation and >> then IPA would change its IP address in DNS to whatever is the real IP >> address under which it is accessible. >> >> Where does the allow_loopback=False requirement in the installer come >> from and what would break if it was removed altogether? > > I also see messages like > > Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file > > in some cases. Actually, it's > > 10.11.12.13 ipa.example.com ipa > > which gets added so the message is not accurate. > > Modification of /etc/hosts itself seems unfortunate. Should the IP > address change in the future, there will be one more place where > the IP address stays hardcoded. > > I wonder why > > hosts: files dns myhostname > > isn't enough, and whether > > hosts: files myhostname dns > > might actually be better order. Theoretically yes. Practically it will break Dogtag and other components which are not able to cope up with link-local addresses returned from myhostname module. > When the value is not in /etc/hosts, > I see weird startup issues, presumably because individual components > time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps > it has something to do with named being up at that point, rather than > unreachable, just not resolving anything yet. Chicken and egg. > > I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried > that and have seen > > named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic > failure: GSSAPI Error: Unspecified GSS failure. Minor code > may provide more information (Server > ldap/localhost at EXAMPLE.TEST not found in Kerberos database): > bind to LDAP server failed > > which suggests something derives the hostname and thus the principal > from the IP address used. Why is not $HOSTNAME used everywhere? What > part of the system cares about the IP address (and the reverse > resolution)? AFAIK FQDN is used everywhere. The "localhost" name might be coming from Kerberos name canonicalization, which works like this: FQDN (name resolution) record-> IP address (IP address resolution)->new name. You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It should be default anyway, but why not try it explicitly. Also, I would try if dns_canonicalize_hostname=false makes any difference or not. > If overloading 127.0.0.1 with the $HOSTNAME does not work, could > 127.0.0.2 do the trick? It seems to work for subsequent starts (did > not try it during ipa-server-install) in containers. It will likely suffer with very similar problems. It if works, it works just accidentally and might break at any time in future. Before we touch IP address/domain name logic, we need to agree how it should behave. What is the purpose of --ip-address option? a) Specify IP addresses used in DNS. ab) What checks should be performed on it? b) To bind deamons only to specific IP addresses instead of all interfaces? I have seen requests for both. We need to decide what is the intended behavior and design it before making further changes. The spaghetti code is too intertwined for making any non-systematic changes. -- Petr^2 Spacek From jcholast at redhat.com Mon Oct 17 07:50:57 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 17 Oct 2016 09:50:57 +0200 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> Hi, On 13.10.2016 18:52, Sumit Bose wrote: > On Tue, Oct 11, 2016 at 01:37:09PM +0200, Sumit Bose wrote: >> On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote: >>> Hi, >>> >>> I've started to write a SSSD design page about enhancing the current >>> mapping of certificates to users and how to select/match a suitable >>> certificate if multiple certificates are on a Smartcard. >>> >>> My currently thoughts and idea and be found at >>> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates >>> and for your convenience below as well. >>> >>> Comments and suggestions are welcome. Please let me know about concerns, >>> alternatives and missing use-cases/user-stories. >>> >>> bye, >>> Sumit >>> >> >> Hi, >> >> Rob, Fraser, Alexander, thank you for your comments. I think both the >> issuer specific matching and the OID in the SUBJECT matching are good >> ideas. I updated the design page accordingly. The changes can be shown >> with >> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff&version=9&old_version=6 >> >> The updated version can be found below as well. Of course more comments and >> suggestions are still very welcome. >> > > I did another update. A "Compatibility with Active Director" section is > added which made me realize that there are use-cases for using the > issuer in the mapping as well and the sub-strings in LDAP search filters > might be useful as well. > > The changes can be seen with > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff&version=10&old_version=9 > > Please let me know your comments and suggestions. > > bye, > Sumit > > = Matching and Mapping Certificates = > > Related ticket(s): > * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping > > === Problem statement === > ==== Mapping ==== > Currently it is required that a certificate used for authentication is either stored in the LDAP user entry or in a matching override. This might not always be applicable and other ways are needed to relate a user with a certificate. > > ==== Matching ==== > Even if SSSD will support multiple certificates on a Smartcard in the context of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict (or relax) the current certificate selection in certain environments. > > === Use cases === > ==== Mapping ==== > In some environments it might not be possible or would cause unwanted effort to add certificates to the LDAP entry of the users to allow Smartcard based authentication. Reasons might be: > * Certificates/Smartcards are issued externally > * LDAP schema extension is not possible or not allowed > > ==== Matching ==== > A user might have multiple certificate on a Smartcard which are suitable for authentication. But on some host in the environment only certificates from a specific CA (while all other CAs are trusted as well) or with some special extension should be valid for login. > > === Overview of the solution === > To match a certificate a language/syntax has to be defined which allows to reference items from the certificate and compare the values with the expected data. To map the certificates to a user the language/syntax should allow to relate certificate items with LDAP attributes so that the value(s) from the certificate item can be used in a LDAP search filter. Note that in some cases it might be possible to map a certificate to a user without having to do an extra LDAP search, for example when the certificate contains the principal name of the user. Does the design allow this? Or is there no extra LDAP search? > > > === Implementation details === > ==== Matching ==== > The pkinit plugin of MIT Kerberos must find a suitable certificate from a Smartcard as well and has defined the following syntax (see the pkinit_cert_match section of the krb5.conf man page or http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for details). The main components are > > * regular-expression > * regular-expression > * regular-expression > * extended-key-usage-list > * key-usage-list > > and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator ('&&' is the default). If multiple rules are given they are iterated with the order in the config file as long as a rule matches exactly one certificate. > > '''Question: MIT Kerberos use case-sensitive matching and POSIX Extended Regular Expression syntax, shall we do the same?''' > > While and are (imo) already quite flexible I can see some potential extensions for the other components. I don't think regular expressions are a particularly good choice for DN matching. It is difficult to express assertions which are quite natural for DNs (matching multi-attribute RDNs, matching the same attribute type by different identifiers, respecting the defined matching rules of attribute types) and at the same time it is easy to express assertions which do not make much sense for DNs (matching substrings in attribute names, matching accross multiple syntactical elements, etc.). That said, does the design have to be based on the MIT pkinit matching? To me it looks like something quickly hacked together rather than thoughtfully designed. I would personally base the design on the concepts of CertificateMatch, which is the standard way of matching certificates, defined in X.509, rather than reinvent the wheel. > > and in MIT Kerberos only accept certain string values related to some allowed values in those field as defined in https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by what is supported on server side of the pkinit plugin of MIT Kerberos. Since we plan to extend pkinit and support local authentication without pkinit as well I would suggest to allow OID strings for those components as well (the comparison is done on the OID level nonetheless). > > The component in MIT Kerberos only checks the otherName SAN component for the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the szOID_NT_PRINCIPAL_NAME OID as mentioned in https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the default pkinit user case of MIT Kerberos I would suggest to extend this component by allowing to specific an OID with > > ===== Issuer specific matching ===== > Although the MIT Kerberos rules allow to select the issuer of a certificate there are use cases where a more specific selection is needed. E.g. if there are some default matching rules for all issuers and some other issuer specific rules where the default rules should not apply. To make this possible with the above scheme the default rules must have an clause which matches all but the issuer with the specific rules. Writing regular-expressions to not match a specific string or a list of strings is at least error-prone if not impossible. > > To make it easier to define issuer specific rules and default rules at the same time and optional issuer string can be added to the rule to indicate that for the given issuer only those rules should be considered. Given the use-case I think it is acceptable to require that the full issuer must be specified here in LDAP order (see below) and case-sensitive matching is used. This could also be solved by adding priority to rules - if two rules match, the one with higher priority (the issuer specific rule) is preferred over the one with lower priority (the default rule). IMO this is better than an optional issuer string as it offers greater flexibility. > > How the issuer string is linked to the matching rules depends on the storage (LDAP or sssd.conf, see below for details). > ==== Mapping ==== > Since different certificates, e.g. issued by different CAs, might have different mapping rule, a matching rule must be added if there are more than 1 mapping rule. A single mapping rule without a matching rule might be used as default/catch-all rule in this case. > > If multiple rules matches the derived LDAP filter components can be grouped with the or-operator "|". > > A mapping rule can use a similar syntax like the matching rule where the LDAP attribute can be added with a ':', e.g. > * > * > * > > where O.I.D. is either the OID or name of a RDN type or the OID or some well-known-name of the SAN component respectively. Since the SUBJECT might contain multiple RDNs of the same type always the "most specific" is selected because in general this will be the most suited one to map the certificate to a specific user. "most specific" means the last in X.500 order and the first in LDAP order (see discussion below for details). > > If the O.I.D. is missing the full SUBJECT/ISSUER is used for mapping. If 'DN' is used as ldapAttributeName SUBJECT is expected to be the DN of the user. If the O.I.D. is missing in the SAN case the same default as with matching (id-pkinit-san and szOID_NT_PRINCIPAL_NAME OID) is used. If both SAN values can be found in the certificate and are different the LDAP search filter will combine both with the or-operator. > > The optional '*' in the end indicates that a sub-string search (ldapAttributeName=*value*) should be used and not an exact match (ldapAttributeName=value). Please note that it depends on the server-side definition of the LDAP attribute if case-sensitive or case-insensitve matching is used. This seems like a rather quirky way to write down an LDAP filter. IMHO a better way would be to use a single attribute containing a filter template, e.g.: (&(someAttr={issuer})(someOtherAttr=*{subject:O.I.D}*)) > > Currently I see no usage for and in mapping rules because they do not contain any user-specific data. If at some point we will have personal CAs we might consider to add based mappings. > > ===== Future consideration ===== > Most of the interesting values from the SAN should be directly map-able to LDAP attributes. And processing the string representation of might be tricky as discussed below. Nevertheless it might be possible to add to following in a future release if more complex operations on the values are needed: > > * /regexp/replacement/ > * /regexp/replacement/ > > where "/regexp/replacement/" stands for optional sed-like substitution rules. E.g. a rule like > {{{ > /^CN=\([^,]*\).*$/\1/ > }}} > would take the subject string 'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and generate a LDAP search filter component '(samAccountName=Certuser)' which can be included in a LDAP search filter which includes additional components like e.g. an objectClass. > > The search-and-replace does not has to be sed-like because afaik there is not library which offers this and I would like to avoid implementing it. GLib e.g. has [https://developer.gnome.org/glib/stable/glib-Perl-compatible-regular-expressions.html#g-regex-replace g_regex_replace]. Since we already have a GLib dependency in SSSD due to soem utf8 helper functions using might be acceptable as well. Nevertheless it would be nice to hear if there are alternative libraries available as well. > > Maybe even search-and-replace are not sufficient for all cases and something like embedded lua scripts are needed. But since certificate mapping is about access control and authorization it should be always considered if adding a new attribute to the users LDAP entry which makes mapping easy and straight-forward wouldn't be the better solution. > > ===== Some notes about DNs ===== > The X.500 family of standards define names as "SEQUENCE OF RelativeDistinguishedName" where the sequence is "starting with the root and ending with the object being named" (see X.501 section 9.2 for details). On the other hand RFC4514 section 2.1 says "Otherwise, the output consists of the string encoding of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first." This means that the ASN.1 encoded issuer and subject DN from the X.509 certificate can be either displayed as string in the > * X.500 order: DC=com,DC=example,CN=users,CN=Certuser > or in the > * LDAP order: CN=Certuser,CN=Users,DC=example,DC=com > > As a consequence different tools will use a different order when printing the issuer and subject DN. While NSS's certutil will use the LDAP order, 'openssl x509' and gnutls's certtool will use the X.500 order (the latter might change due to https://gitlab.com/gnutls/gnutls/issues/111). > > This makes it important to specific the order which is used by SSSD for mapping and matching. I would prefer the LDAP order here. E.g. by default the AD CA uses the DN of the users entry in AD as subject in the issues certificate. So a matching rule like '' could tell SSSD to directly search the user based on its DN (which btw is the original intention of the subject field in the certificate, only that the DN should be looked up in a more general DAP as defined by X.500 and not in the lightweight version called LDAP) > > Another issue is the limited set of attribute names/types required by the RFCs (see section 4.1.2.4 of RFC 3280 and section 3 of RFC 4514). If e.g. the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] is used all tools are able to identify it as an email address but OpenSSL displays it as 'emailAddress=user at example.com', certtool as 'EMAIL=user at example.com' and certutil as 'E=user at example.com'. So matching rules should try to avoid attribute names or only the ones from [https://www.ietf.org/rfc/rfc4514.txt RFC 4514]: > * CN commonName (2.5.4.3) > * L localityName (2.5.4.7) > * ST stateOrProvinceName (2.5.4.8) > * O organizationName (2.5.4.10) > * OU organizationalUnitName (2.5.4.11) > * C countryName (2.5.4.6) > * STREET streetAddress (2.5.4.9) > * DC domainComponent (0.9.2342.19200300.100.1.25) > * UID userId (0.9.2342.19200300.100.1.1) > > ==== About restricting or enforcing the mapping an matching any further ==== > The goal of the matching rules in MIT Kerberos is to select a single certificate from a Smartcard which will then be used for PKINIT. Since we already plan to enhance SSSD to support multiple certificates on a Smartcard and if needed prompt the user which one to use for login we should not enforce that the matching rules should return only a single certificate or nothing. > > Similar we plan to enhance SSSD to use the same certificate to log in with different user identities, e.g. as a user with standard privileges or as a user with administrator privileges. So it can make sense that multiple mapping rules apply to the same certificate and the related LDAP search filter components are or-ed together. > > In many cases the login program will first ask for a user name which will help to restrict the number of suitable certificates even further and the mapping rules are only needed to check if the certificate belongs to the user trying to log in. > > But gdm has a feature where gdm will detect when a Smartcard is inserted and call PAM without a user name. In this case SSSD has to determine the user name based on the certificates found on the Smartcard. If in this case multiple valid certificates are on the card and the mapping rules will return multiple users for each certificate gdm has to display a quite long selection of certificate-user pairs the user has to choose from. > > So it should be underlined in the documentation that the matching and mapping rules should be detailed and specific so that for the given environment they help to avoid cases where the user is prompted to select a certificate (or user name in the gdm case) when trying to log in. > > ==== Storing matching and mapping configuration ==== > On the IPA server a new objectclass can be created to store an matching-mapping rule pair together with a specific issuer. All attributes are optional because a missing mapping rule would mean that the user entry will be search with the whole certificate. A missing matching rule will indicate catch-all rule with a default mapping. If only a specific issuer is given certificates from this issuer must be stored in the LDAP entry of the user to make authentication possible. > > Specifying matching-mapping rules in sssd.conf is a bit more complicated because SSSD does not respect multiple entries with the same keyword, only the last one is used. So all rules have to be added to a single line. To give it a little bit of structure the rules can be enclosed by curly-braces '{}{}{}' and each rule pair is separated by a comma ','. A single rule in curly braces indicates a matching rule and the mapping will be done with the whole certificate. A default/catch-all mapping rule will start with an empty pair of curly braces followed by a pair containing the mapping rule. Issuer specific rules will have three pairs of curly braces where the first pair must contain an issuer string. > > ===== Future considerations ===== > If it turns out that this option is used quite often and it gets complicated to manage a larger set of rules with it and storing the rules in LDAP/IPA/AD is not an option we might add support to read the rules from a separate file (certificate_rules = FILE:///etc/sssd/cert_rules) with a more suitable format, e.g. ini where a list can be defined by given the same option multiple times. > > ===== Examples ===== > * '''certificate_rules = {msScLogin}''': only allow certificates with have the Microsoft OID for Smartcard logon 1.3.6.1.4.1.311.20.2.2 set. use the whole certificate to look-up the user. The same result can be achieved with > * '''certificate_rules = {1.3.6.1.4.1.311.20.2.2}''': see above > * '''certificate_rules = {*my-company**@my-company.com$}{}''': only allow certificates form the 'my-company' issuer which have an email address from the 'my-company.com' domain in the rfc882Name SAN attribute. Use the email address in a LDAP search filter '(mail=email-address)' to find the matching user. > > ==== Compatibility with Active Directory ==== > Active Directory uses a per-user LDAP attribute [https://msdn.microsoft.com/en-us/library/cc220106.aspx altSecurityIdentities] to allow arbitrary user-certificate mappings is there is no suitable user-principal-name entry in the SAN of the certificate. > > Unfortunately it is more or less undocumented how AD use the values of this attribute. The best overview I found is in https://blogs.msdn.microsoft.com/spatdsg/2010/06/18/howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute/. > > It looks like the most important variant is the issuer-subject pair. This one is e.g. created when a certificate is added via the 'Name Mappings' context menu entry in AD's 'Users and Computers' utility ('Advanced Features' must be activated in the 'View' menu). The attribute value might look like > {{{ > altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate AuthorityDC > =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co > m,CN=Sumit Bose Sumit Bose > }}} > First it can be seen that X.500 ordering is used. Second, if RDN types not explicitly mentioned in the RFCs are used, you are on your own. As can be seen AD can translate the deprecated OID [http://www.oid-info.com/get/1.2.840.113549.1.9.1 1.2.840.113549.1.9.1] and uses 'E' as NSS. But the OID [http://www.oid-info.com/get/0.9.2342.19200300.100.1.1 0.9.2342.19200300.100.1.1] which is explicitly mentioned in RFC4514 is not translated as UID but the plain OID syntax is used (my guess it that Microsoft tries to be compatible with "older" versions because the UID was added in RFC2253 from 1997 but was not present in the RFC1779 from 1995 and RFC1485 from 1993). > > Nevertheless with the mapping rules described above a rule like > {{{ > > }}} > would product a LDAP search filter like > {{{ > (&(altSecurityIdentities=*Red Hat*)(altSecurityIdentities=*Sumit Bose Sumit Bose*)) > }}} > which should quite reliable find the right LDAP entry. > > As an alternative it would be possible to add special mapping rules like which would try in a best effort to produce the exact attribute value AD is using. This should work reliable with standard RDN types (see above). I think an optional 'ldapAttributeName' is useful here so that the same mapping rule can be used with different LDAP servers (e.g. IPA) where user-specific mapping attributes are used with the same content but a different attribute name. > > According to the blob post describing altSecurityIdentities some other additional mapping rules might be useful too. This will give us > * > * > * > * > * > * > > So far I didn't found a AD tool which creates to other mappings, if you know one, please let me know. > === Configuration changes === > Does your feature involve changes to configuration, like new options or options changing values? Summarize them here. There's no need to go into too many details, that's what man pages are for. > > === How To Test === > This section should explain to a person with admin-level of SSSD understanding how this change affects run time behaviour of SSSD and how can an SSSD user test this change. If the feature is internal-only, please list what areas of SSSD are affected so that testers know where to focus. > > === How To Debug === > Explain how to debug this feature if something goes wrong. This section might include examples of additional commands the user might run (such as keytab or certificate sanity checks) or explain what message to look for. > > === Authors === > Give credit to authors of the design in this section. > Honza -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Oct 17 09:22:38 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 17 Oct 2016 11:22:38 +0200 Subject: [Freeipa-devel] [freeipa PR#165][synchronized] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Author: mirielka Title: #165: Tests: Verify that cert-find show CA without --all Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/165/head:pr165 git checkout pr165 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-165.patch Type: text/x-diff Size: 1872 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 17 09:24:13 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 17 Oct 2016 11:24:13 +0200 Subject: [Freeipa-devel] [freeipa PR#165][synchronized] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Author: mirielka Title: #165: Tests: Verify that cert-find show CA without --all Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/165/head:pr165 git checkout pr165 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-165.patch Type: text/x-diff Size: 1913 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 17 09:26:03 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 17 Oct 2016 11:26:03 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all mirielka commented: """ I added check for cert-show and cert-request (it was quite easy to add it to existing test). I'd prefer to add test for #6022 separately when bugfix is provided. """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-254157384 From freeipa-github-notification at redhat.com Mon Oct 17 10:03:57 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 17 Oct 2016 12:03:57 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all pvoborni commented: """ Right, I only wanted to highlight the issue in #6022. It should be a separate patch. """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-254165884 From freeipa-github-notification at redhat.com Mon Oct 17 12:50:37 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Mon, 17 Oct 2016 14:50:37 +0200 Subject: [Freeipa-devel] [freeipa PR#166][opened] WebUI: services without canonical name are shown correctly Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Author: pvomacka Title: #166: WebUI: services without canonical name are shown correctly Action: opened PR body: """ There is a change introduced in 4.4 that new services have canonical name. The old ones didn't have it, therefore these services were not correctly displayed in WebUI. This patch adds support for this type of services. Service name is taken from 'krbprincipalname' attribute in case that 'krbcanonicalname' attribute is not present in server response. https://fedorahosted.org/freeipa/ticket/6397 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/166/head:pr166 git checkout pr166 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-166.patch Type: text/x-diff Size: 5120 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 17 13:30:55 2016 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 17 Oct 2016 15:30:55 +0200 Subject: [Freeipa-devel] [freeipa PR#117][comment] Make ipa-replica-install run in interactive mode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/117 Title: #117: Make ipa-replica-install run in interactive mode simo5 commented: """ @stlaz, sure, what I meant is that the checking code should be made common and run in ipa-repliuca-install, certainly I was not suggesting to just duplicate all that code. Perhaps refactoring will just do that. """ See the full comment at https://github.com/freeipa/freeipa/pull/117#issuecomment-254207783 From freeipa-github-notification at redhat.com Mon Oct 17 14:02:29 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 17 Oct 2016 16:02:29 +0200 Subject: [Freeipa-devel] [freeipa PR#167][opened] Move ipa.1 man file Message-ID: URL: https://github.com/freeipa/freeipa/pull/167 Author: tiran Title: #167: Move ipa.1 man file Action: opened PR body: """ setuptools does not support data_files any more. The ipa(1) man page is now handled like the remaining man pages. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/167/head:pr167 git checkout pr167 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-167.patch Type: text/x-diff Size: 24108 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 17 14:28:23 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 17 Oct 2016 16:28:23 +0200 Subject: [Freeipa-devel] [freeipa PR#143][synchronized] Issue6386 nss dir In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/143 Author: tiran Title: #143: Issue6386 nss dir Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/143/head:pr143 git checkout pr143 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-143.patch Type: text/x-diff Size: 4585 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 17 14:33:22 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Mon, 17 Oct 2016 16:33:22 +0200 Subject: [Freeipa-devel] [freeipa PR#167][+ack] Move ipa.1 man file In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/167 Title: #167: Move ipa.1 man file Label: +ack From freeipa-github-notification at redhat.com Mon Oct 17 14:38:33 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 17 Oct 2016 16:38:33 +0200 Subject: [Freeipa-devel] [freeipa PR#143][comment] Issue6386 nss dir In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/143 Title: #143: Issue6386 nss dir jcholast commented: """ NACK, see inline comments. """ See the full comment at https://github.com/freeipa/freeipa/pull/143#issuecomment-254226440 From rcritten at redhat.com Mon Oct 17 14:50:54 2016 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 17 Oct 2016 10:50:54 -0400 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> Message-ID: <5804E54E.4050707@redhat.com> Jan Cholasta wrote: > Hi, > > On 13.10.2016 18:52, Sumit Bose wrote: >> ===== Issuer specific matching ===== >> Although the MIT Kerberos rules allow to select the issuer of a >> certificate there are use cases where a more specific selection is >> needed. E.g. if there are some default matching rules for all issuers >> and some other issuer specific rules where the default rules should >> not apply. To make this possible with the above scheme the default >> rules must have an clause which matches all but the issuer >> with the specific rules. Writing regular-expressions to not match a >> specific string or a list of strings is at least error-prone if not >> impossible. >> >> To make it easier to define issuer specific rules and default rules at >> the same time and optional issuer string can be added to the rule to >> indicate that for the given issuer only those rules should be >> considered. Given the use-case I think it is acceptable to require >> that the full issuer must be specified here in LDAP order (see below) >> and case-sensitive matching is used. > > This could also be solved by adding priority to rules - if two rules > match, the one with higher priority (the issuer specific rule) is > preferred over the one with lower priority (the default rule). IMO this > is better than an optional issuer string as it offers greater flexibility. The use cases I've seen haven't had to do with priority, though that would be a nice enhancement, but with only allowing certificates issued by a specific CA to be allowed (this is pretty common in web servers). Being able to say "only do the matching on certificates issued by foo" is valuable. rob From freeipa-github-notification at redhat.com Mon Oct 17 14:55:34 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 17 Oct 2016 16:55:34 +0200 Subject: [Freeipa-devel] [freeipa PR#143][synchronized] Issue6386 nss dir In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/143 Author: tiran Title: #143: Issue6386 nss dir Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/143/head:pr143 git checkout pr143 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-143.patch Type: text/x-diff Size: 3180 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 17 15:22:09 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 17 Oct 2016 17:22:09 +0200 Subject: [Freeipa-devel] [freeipa PR#167][+pushed] Move ipa.1 man file In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/167 Title: #167: Move ipa.1 man file Label: +pushed From freeipa-github-notification at redhat.com Mon Oct 17 15:22:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 17 Oct 2016 17:22:11 +0200 Subject: [Freeipa-devel] [freeipa PR#167][comment] Move ipa.1 man file In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/167 Title: #167: Move ipa.1 man file mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/b9d68b5c3503bb708f637be6bb173a742b4105b4 """ See the full comment at https://github.com/freeipa/freeipa/pull/167#issuecomment-254239607 From freeipa-github-notification at redhat.com Mon Oct 17 15:22:13 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 17 Oct 2016 17:22:13 +0200 Subject: [Freeipa-devel] [freeipa PR#167][closed] Move ipa.1 man file In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/167 Author: tiran Title: #167: Move ipa.1 man file Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/167/head:pr167 git checkout pr167 From freeipa-github-notification at redhat.com Mon Oct 17 15:25:13 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 17 Oct 2016 17:25:13 +0200 Subject: [Freeipa-devel] [freeipa PR#155][comment] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Title: #155: Build system cleanup mbasti-rh commented: """ Needs rebase """ See the full comment at https://github.com/freeipa/freeipa/pull/155#issuecomment-254240565 From freeipa-github-notification at redhat.com Mon Oct 17 15:33:00 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 17 Oct 2016 17:33:00 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template mbasti-rh commented: """ I disagree here with Honza, I liked those comments more at bottom. Why do we even need that comments? git commit command with vim set as editor is doing that automatically. """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-254242928 From simo at redhat.com Mon Oct 17 15:50:32 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Oct 2016 11:50:32 -0400 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> Message-ID: <1476719432.3607.32.camel@redhat.com> On Thu, 2016-10-13 at 18:52 +0200, Sumit Bose wrote: > ==== Compatibility with Active Directory ==== > Active Directory uses a per-user LDAP attribute > [https://msdn.microsoft.com/en-us/library/cc220106.aspx altSecurityIdentities] to allow arbitrary user-certificate mappings is there is no suitable user-principal-name entry in the SAN of the certificate. > > Unfortunately it is more or less undocumented how AD use the values of > this attribute. The best overview I found is in > https://blogs.msdn.microsoft.com/spatdsg/2010/06/18/howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute/. A few more pointers Sumit: - This describes what is allowed for users: https://msdn.microsoft.com/en-us/library/ms677943%28v=vs.85%29.aspx - This describes a use for devices: https://msdn.microsoft.com/en-us/library/dn408946.aspx - additional description specific for PKINIT: https://msdn.microsoft.com/en-us/library/hh536384.aspx - This is a good detailed overview of the Smart Card logon workflow in windows, it describes Vista but I do not think it changed in fundamental ways in following releases: https://msdn.microsoft.com/en-us/library/bb905527.aspx NOTE: Please look at the small paragraph named "Smart card logon across forests", we definitely want to think about this problem as well from the get-go and not try to retrofit something later on. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Oct 17 15:55:20 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Oct 2016 11:55:20 -0400 Subject: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server? In-Reply-To: <02227e30-dfcf-30c1-8a26-5a356e2f0f87@redhat.com> References: <20160921100144.GA7371@redhat.com> <20160927123134.GA32730@redhat.com> <02227e30-dfcf-30c1-8a26-5a356e2f0f87@redhat.com> Message-ID: <1476719720.3607.33.camel@redhat.com> On Mon, 2016-10-17 at 09:02 +0200, Petr Spacek wrote: > On 27.9.2016 14:31, Jan Pazdziora wrote: > > On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote: > >> > >> I've recently hit again the situation of IPA installer not happy > >> about the provided IP address not being local to it, this time in > >> containerized environment: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1377973 > >> > >> During the discussion, we came to an interesting question: > >> > >> What would break if loopback addresses were allowed for IPA > >> server? > >> > >> Of course, the idea is that it would only be used for installation and > >> then IPA would change its IP address in DNS to whatever is the real IP > >> address under which it is accessible. > >> > >> Where does the allow_loopback=False requirement in the installer come > >> from and what would break if it was removed altogether? > > > > I also see messages like > > > > Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file > > > > in some cases. Actually, it's > > > > 10.11.12.13 ipa.example.com ipa > > > > which gets added so the message is not accurate. > > > > Modification of /etc/hosts itself seems unfortunate. Should the IP > > address change in the future, there will be one more place where > > the IP address stays hardcoded. > > > > I wonder why > > > > hosts: files dns myhostname > > > > isn't enough, and whether > > > > hosts: files myhostname dns > > > > might actually be better order. > > Theoretically yes. Practically it will break Dogtag and other components which > are not able to cope up with link-local addresses returned from myhostname module. > > > > When the value is not in /etc/hosts, > > I see weird startup issues, presumably because individual components > > time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps > > it has something to do with named being up at that point, rather than > > unreachable, just not resolving anything yet. Chicken and egg. > > > > I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried > > that and have seen > > > > named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic > > failure: GSSAPI Error: Unspecified GSS failure. Minor code > > may provide more information (Server > > ldap/localhost at EXAMPLE.TEST not found in Kerberos database): > > bind to LDAP server failed > > > > which suggests something derives the hostname and thus the principal > > from the IP address used. Why is not $HOSTNAME used everywhere? What > > part of the system cares about the IP address (and the reverse > > resolution)? > > AFAIK FQDN is used everywhere. The "localhost" name might be coming from > Kerberos name canonicalization, which works like this: > FQDN (name resolution) record-> IP address (IP address resolution)->new name. > > You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It > should be default anyway, but why not try it explicitly. > > Also, I would try if dns_canonicalize_hostname=false makes any difference or not. Btw this attribute came up also elsewhere, I think we should consider changing ipa-client-install (or SSSD) to make dns_canonicalize_hostname=false the default in IPa installs. Should we open a ticket for that? Simo. > > > If overloading 127.0.0.1 with the $HOSTNAME does not work, could > > 127.0.0.2 do the trick? It seems to work for subsequent starts (did > > not try it during ipa-server-install) in containers. > > It will likely suffer with very similar problems. It if works, it works just > accidentally and might break at any time in future. > > Before we touch IP address/domain name logic, we need to agree how it should > behave. > > What is the purpose of --ip-address option? > a) Specify IP addresses used in DNS. > ab) What checks should be performed on it? > b) To bind deamons only to specific IP addresses instead of all interfaces? > > I have seen requests for both. We need to decide what is the intended behavior > and design it before making further changes. The spaghetti code is too > intertwined for making any non-systematic changes. > > -- > Petr^2 Spacek > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Oct 17 15:59:44 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 17 Oct 2016 11:59:44 -0400 Subject: [Freeipa-devel] Feature branches for sub-team efforts In-Reply-To: <4103ebfc-8319-0226-9567-e43bb7f36b02@redhat.com> References: <20161011135050.crkf25psdffdnws4@redhat.com> <4103ebfc-8319-0226-9567-e43bb7f36b02@redhat.com> Message-ID: <1476719984.3607.35.camel@redhat.com> On Tue, 2016-10-11 at 16:19 +0200, Petr Vobornik wrote: > On 10/11/2016 03:50 PM, Alexander Bokovoy wrote: > > On ti, 11 loka 2016, Petr Vobornik wrote: > >> Hi List, > >> > >> we discussed locally a proposal about creating a feature branch for each > >> sub-team effort in our main git. Currently it would be for the 4 ongoing > >> refactoring efforts + Simo's work > >> > >> Why? > >> It will allow each developer to create a pull request against the > >> feature branch and thus it will enable iterative development by multiple > >> devs without affecting other sub-teams. When the feature(refactoring) is > >> finished, the branch would be rebased on master and merged there. Note: > >> rebases can be done as needed - e.g. when other subteam finishes its > >> work. > >> > >> Concerns: > >> 1. Upstream git repo would be full of such branches. > >> - This can be mitigated by deleting the feature branches when their are > >> released or merged(up to discussion) > > Don't put them in the upstream git repo. Let people decide where they > > want to have them -- all Fedora contributors have access to > > fedorapeople.org git hosting and there is github one button click > > ('Clone') away from the github mirror. > > > > It is not a problem to keep a separate git branch published this way. > > > > It is not a matter of making the code public. That can be done easily as > you write. Other alternative is own branch in GitHub fork. Please go with this. I see no point in having these branches in the main repo, it is just clutter. > > May be I misunderstand you -- if you just want people to propose merge > > requests on github with pre-defined names, then that's just fine. > > > > Basically it's all about review. > > Example use case: More than 1 devs are working on a same big effort. > This effort will probably consists of 10s of commits. The big effort is > divided into smaller ones which can be implemented and reviewed > separately. In our previous mode, the sub task would be merged to master > it is reviewed and ACKed. But now we cannot do that. We want to merge > the whole big task at once when it is finishes and tested. > > One dev could probably have a branch on personal fork of FreeIPA on > GitHub which would work as the feature branch. Other team members would > create pull requests against it. Exactly. > In such case we would loose mail notifications and would have to extend > our tooling because ipatool can use only one upstream on push. Why would you need ipatool for a working branch ? > Pre-defined names for PRs is a good idea - we could easily see what > effort the pull request is related to. Predefined how ? Simo. -- Simo Sorce * Red Hat, Inc * New York From freeipa-github-notification at redhat.com Mon Oct 17 16:02:12 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 17 Oct 2016 18:02:12 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 30992 bytes Desc: not available URL: From mbasti at redhat.com Mon Oct 17 17:05:04 2016 From: mbasti at redhat.com (Martin Basti) Date: Mon, 17 Oct 2016 19:05:04 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <80d2ccd8-8e1b-52a7-df76-087c72f21a12@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> <36a2eba5-a03d-131e-0042-46f0d4f0299a@redhat.com> <80d2ccd8-8e1b-52a7-df76-087c72f21a12@redhat.com> Message-ID: <8caa3b3a-54a6-e168-6304-09ce8fb60a7f@redhat.com> 1) you don't need to disable/enable dirsrv, just stop/start. Please remove disable/enable parts 2) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> traceback >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> self = def test_delete_ruvs(self): """ http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/ Test_Plan#Test_case:_clean-ruv_subcommand """ replica = self.replicas[0] master = self.master res1 = master.run_command(['ipa-replica-manage', 'list-ruv', '-p', master.config.dirman_password]) > assert(res1.stdout_text.count(replica.hostname) == 2 and "Certificate Server Replica Update Vectors" in res1), ( "CA-specific RUVs are not displayed") E TypeError: argument of type 'SSHCommand' is not iterable test_integration/test_topology.py:215: TypeError >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entering PDB >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > /usr/lib/python2.7/site-packages/ipatests/test_integration/test_topology.py(215)test_delete_ruvs() -> assert(res1.stdout_text.count(replica.hostname) == 2 and On 14.10.2016 11:36, Oleg Fayans wrote: > Right you are! I am sorry. > > On 10/13/2016 06:10 PM, Martin Basti wrote: >> I think that you forgot to squash commits. Patch 47 doesn't apply >> >> >> On 13.10.2016 14:01, Oleg Fayans wrote: >>> Hi Martin, >>> >>> Thanks for the review. >>> With disabling directory server it works as well, thanks for the hint. >>> Also I moved the cleanup logic to the test itself for the sake of >>> simplicity. Patch-0048 was not changed >>> >>> On 10/12/2016 02:35 PM, Martin Basti wrote: >>>> 1) >>>> >>>> Can you just turn off dirsrv on replica instead of doing iptables >>>> magic? >>>> >>>> >>>> 2) NACK >>>> >>>> No more eval() ever in code, use 'getattr', 'get' or whatever in the >>>> object that can be used. >>>> >>>> + evalhost = eval("args[0].%s" % host) >>>> >>>> Martin^2 >>>> >>>> On 12.10.2016 14:03, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> After extensive discussion with Ludwig, I finally got the clue on how >>>>> does this feature work. When we uninstall the replica, the master >>>>> cleans the replication agreements with this replica and automatically >>>>> cleans all replica's RUVs. >>>>> If we clean replica's RUVs on master without uninstalling the >>>>> replica, >>>>> the replica's RUVs get recreated on master (replication works!). So, >>>>> the only way to test the clean-ruv subcommand is to turn off the >>>>> replica, or block the traffic on it so it gets inaccessible to >>>>> updates >>>>> from master. >>>>> The testcases were updated, see [1] and [2] >>>>> >>>>> The updated versions of the patches are attached >>>>> >>>>> [1] >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs >>>>> >>>>> >>>>> >>>>> >>>>> [2] >>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand >>>>> >>>>> >>>>> >>>>> >>>>> On 08/05/2016 06:36 PM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 03.08.2016 14:45, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> Thanks for the review! Both patches were updated. >>>>>>> >>>>>>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> Thanks for the review! >>>>>>>>> >>>>>>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>>>>>> before >>>>>>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>>>>>> feature. >>>>>>>>>>> >>>>>>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>>>>>> One more test was added to the patch-0048 >>>>>>>>>>>> >>>>>>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>>>>>> from >>>>>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> IIUC, this will turn off the machine completely, how is cleanup >>>>>>>>>> done >>>>>>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>>>>>> cleanup, so >>>>>>>>>> you will not be able to run more tests on the same topology >>>>>>>>>> without >>>>>>>>>> manual cleanup and manual start. >>>>>>>>>> >>>>>>>>>> + replica = self.replicas[0] >>>>>>>>>> + replica.run_command(['poweroff']) >>>>>>>>>> >>>>>>>>>> IMO would be better to just call 'ipactl stop' instead of >>>>>>>>>> 'poweroff' >>>>>>>>> >>>>>>>>> Agreed! Fixed. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Martin^2 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> *Automated ipa-replica-manage del tests* >>>>>>>> >>>>>>>> 1) >>>>>>>> + replica.run_command(['ipactl', 'stop']) >>>>>>>> + time.sleep(3) >>>>>>>> >>>>>>>> Why do you need sleep here? >>>>>>> >>>>>>> Removed, it was left from the old "poweroff" approach >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2) >>>>>>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % >>>>>>>> replica.hostname) >>>>>>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>>>>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', >>>>>>>> 'f', >>>>>>>> + '-p', master.config.dirman_password, >>>>>>>> + replica_ruvs[0]]) >>>>>>>> >>>>>>>> Because you are using re.findall(), without any match you will >>>>>>>> receive >>>>>>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>>>>>> >>>>>>> Implemented the assert which checks that the output contains enough >>>>>>> replica RUVs >>>>>>> >>>>>>>> >>>>>>>> 3) >>>>>>>> assert(replica.hostname in result1.stdout_text) >>>>>>>> >>>>>>>> I think that this is error prone. What if there is just error >>>>>>>> 'could not >>>>>>>> connect to replica ', or something similar. >>>>>>>> instead of >>>>>>>> listing/cleaning/whatever operation was executed. I think that it >>>>>>>> should >>>>>>>> be more specific regexp than just finding a replica name substring >>>>>>>> (Yes >>>>>>>> In IPA we dont always print error so stderr) >>>>>>>> >>>>>>>> I'm not sure, but probably there might be cases when non critical >>>>>>>> error >>>>>>>> happen and exist status is still 0 >>>>>>> >>>>>>> Agree. Implemented a regex-based search >>>>>>> >>>>>>>> >>>>>>>> 4) >>>>>>>> >>>>>>>> + replica.run_command(['poweroff']) >>>>>>>> + time.sleep(3) >>>>>>>> >>>>>>>> There should not be poweroff, probably sleep could be removed too. >>>>>>> >>>>>>> Gone >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * Automated clean-ruv subcommand test* >>>>>>>> >>>>>>>> 1) PEP8, 2 new lines expected >>>>>>>> ./ipatests/test_integration/test_topology.py:163:1: E302 >>>>>>>> expected 2 >>>>>>>> blank lines, found 0 >>>>>>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>>>>>> long >>>>>>>> (85 > 79 characters) >>>>>>> >>>>>>> Fixed >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2) >>>>>>>> I dont like doing assert just with count of occurences of >>>>>>>> substring in >>>>>>>> STDOUT, would be possible to improve this somehow? >>>>>>> >>>>>>> Maybe, but frankly, I don't see how. In this case we are making >>>>>>> sure >>>>>>> that both simple and CA-specific RUVs of a replica are >>>>>>> displayed. The >>>>>>> format of the output is strict: >>>>>>> Replica Update Vectors: >>>>>>> replica1_hostname:389: RUV_id >>>>>>> replica2_hostname:389: RUV_id >>>>>>> Certificate Server Replica Update Vectors: >>>>>>> replica1_hostname:389: RUV_id >>>>>>> replica2_hostname:389: RUV_id >>>>>>> If we do not see 2 occurrences of the replica hostname than >>>>>>> definitely >>>>>>> something went wrong >>>>>>> >>>>>>>> >>>>>>>> 3) >>>>>>>> I'm not sure if clean-ruv is instant operations or there is some >>>>>>>> magic >>>>>>>> happening in background (we have abort-clean-ruv). Maybe some >>>>>>>> sleep >>>>>>>> should be there, but this needs investigation. >>>>>>>> >>>>>>>> + assert(replica.hostname in result2.stdout_text), ( >>>>>>>> + "The wrong RUV was deleted") >>>>>>>> + result3 = master.run_command(['ipa-replica-manage', >>>>>>>> 'list-ruv', >>>>>>>> + '-p', >>>>>>>> master.config.dirman_password]) >>>>>>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>>>>>> + "CA RUV of the replica is still displayed") >>>>>>>> >>>>>>> >>>>>>> Based on my discussion with Stanislav Laznicka, I understood >>>>>>> that by >>>>>>> default clean-ruv does not return the shell until the operation is >>>>>>> finished. You can force dropping into the shell by pressing >>>>>>> CTRL+C, in >>>>>>> which case the background job will still be running, but this is >>>>>>> not >>>>>>> the default behavior >>>>>>> >>>>>> Test failed: >>>>>> result4 = master.run_command(['ipa-replica-manage', >>>>>> 'list-ruv', >>>>>> '-p', >>>>>> master.config.dirman_password]) >>>>>>> assert(replica.hostname not in result4.stdout_text), ( >>>>>> "replica's RUV is still displayed") >>>>>> E AssertionError: replica's RUV is still displayed >>>>>> E assert 'replica3.ipa.test' not in 'Replica Update >>>>>> V...ipa.test:389: 8\n' >>>>>> E 'replica3.ipa.test' is contained here: >>>>>> E Replica Update Vectors: >>>>>> E \tmaster.ipa.test:389: 4 >>>>>> E \treplica3.ipa.test:389: 3 >>>>>> E \treplica2.ipa.test:389: 7 >>>>>> E Certificate Server Replica Update Vectors: >>>>>> E \tmaster.ipa.test:389: 6 >>>>>> E \treplica2.ipa.test:389: 8 >>>>>> >>>>>> >>>>>> [root at master ~]# ipa topologysegment-find >>>>>> Suffix name: domain >>>>>> ------------------ >>>>>> 2 segments matched >>>>>> ------------------ >>>>>> Segment name: master.ipa.test-to-replica2.ipa.test >>>>>> Left node: master.ipa.test >>>>>> Right node: replica2.ipa.test >>>>>> Connectivity: both >>>>>> >>>>>> Segment name: master.ipa.test-to-replica3.ipa.test >>>>>> Left node: master.ipa.test >>>>>> Right node: replica3.ipa.test >>>>>> Connectivity: both >>>>>> ---------------------------- >>>>>> Number of entries returned 2 >>>>>> ---------------------------- >>>>>> [root at master ~]# ipa-replica-manage list-ruv >>>>>> Directory Manager password: >>>>>> >>>>>> Replica Update Vectors: >>>>>> master.ipa.test:389: 4 >>>>>> replica2.ipa.test:389: 7 >>>>>> replica3.ipa.test:389: 3 >>>>>> Certificate Server Replica Update Vectors: >>>>>> master.ipa.test:389: 6 >>>>>> replica2.ipa.test:389: 8 >>>>>> [root at master ~]# >>>>>> >>>>>> Then I tried manually to clean RUV 3, and it behaves somehow odd >>>>>> >>>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>>> 'Secret123' '-f' >>>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>>> Background task created to clean replication data. This may take a >>>>>> while. >>>>>> This may be safely interrupted with Ctrl+C >>>>>> Cleanup task created >>>>>> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >>>>>> [root at master ~]# ipa-replica-manage list-ruv >>>>>> Directory Manager password: >>>>>> >>>>>> Replica Update Vectors: >>>>>> master.ipa.test:389: 4 >>>>>> replica2.ipa.test:389: 7 >>>>>> replica3.ipa.test:389: 3 >>>>>> Certificate Server Replica Update Vectors: >>>>>> master.ipa.test:389: 6 >>>>>> replica2.ipa.test:389: 8 >>>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>>> 'Secret123' '-f' >>>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>>> CLEANALLRUV task for replica id 3 already exists. >>>>>> This may be safely interrupted with Ctrl+C >>>>>> Cleanup task created >>>>>> >>>>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>>>> No CLEANALLRUV tasks running >>>>>> >>>>>> No abort CLEANALLRUV tasks running >>>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>>> 'Secret123' '-f' >>>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>>> Background task created to clean replication data. This may take a >>>>>> while. >>>>>> This may be safely interrupted with Ctrl+C >>>>>> Cleanup task created >>>>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>>>> CLEANALLRUV tasks >>>>>> RID 3: Successfully cleaned rid(3). >>>>>> >>>>>> No abort CLEANALLRUV tasks running >>>>>> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >>>>>> Replica Update Vectors: >>>>>> master.ipa.test:389: 4 >>>>>> replica2.ipa.test:389: 7 >>>>>> Certificate Server Replica Update Vectors: >>>>>> master.ipa.test:389: 6 >>>>>> replica2.ipa.test:389: 8 >>>>>> >>>>>> >>>>>> I'm not sure if this behavior is right, Ludwig may know. >>>>> >>>> >>> >> > From freeipa-github-notification at redhat.com Mon Oct 17 17:10:07 2016 From: freeipa-github-notification at redhat.com (Garont) Date: Mon, 17 Oct 2016 19:10:07 +0200 Subject: [Freeipa-devel] [freeipa PR#168][opened] Update cli.py Message-ID: URL: https://github.com/freeipa/freeipa/pull/168 Author: Garont Title: #168: Update cli.py Action: opened PR body: """ fix for ipa host-find ipa: ERROR: UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-26: ordinal not in range(128) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1339, in run sys.exit(api.Backend.cli.run(argv)) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1104, in run rv = cmd.output_for_cli(self.api.Backend.textui, result, *args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1029, in output_for_cli textui.print_entries(result, order, labels, flags, print_all) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 354, in print_entries self.print_entry(entry, order, labels, flags, print_all, format, indent) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 394, in print_entry label, value, format, indent, one_value_per_line File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 317, in print_attribute self.print_indented(format % (attr, text[0]), indent) File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 240, in print_indented print (CLI_TAB * indent + text) UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-26: ordinal not in range(128) ipa: ERROR: an internal error has occurred """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/168/head:pr168 git checkout pr168 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-168.patch Type: text/x-diff Size: 1994 bytes Desc: not available URL: From zhenglei at kylinos.cn Tue Oct 18 01:28:30 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Tue, 18 Oct 2016 09:28:30 +0800 Subject: [Freeipa-devel] [help] Message-ID: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhenglei at kylinos.cn Tue Oct 18 01:28:30 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Tue, 18 Oct 2016 09:28:30 +0800 Subject: [Freeipa-devel] [help] Message-ID: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Tue Oct 18 05:34:48 2016 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 18 Oct 2016 07:34:48 +0200 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <5804E54E.4050707@redhat.com> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> <5804E54E.4050707@redhat.com> Message-ID: On 17.10.2016 16:50, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> On 13.10.2016 18:52, Sumit Bose wrote: >>> ===== Issuer specific matching ===== >>> Although the MIT Kerberos rules allow to select the issuer of a >>> certificate there are use cases where a more specific selection is >>> needed. E.g. if there are some default matching rules for all issuers >>> and some other issuer specific rules where the default rules should >>> not apply. To make this possible with the above scheme the default >>> rules must have an clause which matches all but the issuer >>> with the specific rules. Writing regular-expressions to not match a >>> specific string or a list of strings is at least error-prone if not >>> impossible. >>> >>> To make it easier to define issuer specific rules and default rules at >>> the same time and optional issuer string can be added to the rule to >>> indicate that for the given issuer only those rules should be >>> considered. Given the use-case I think it is acceptable to require >>> that the full issuer must be specified here in LDAP order (see below) >>> and case-sensitive matching is used. >> >> This could also be solved by adding priority to rules - if two rules >> match, the one with higher priority (the issuer specific rule) is >> preferred over the one with lower priority (the default rule). IMO this >> is better than an optional issuer string as it offers greater >> flexibility. > > The use cases I've seen haven't had to do with priority, though that > would be a nice enhancement, but with only allowing certificates issued > by a specific CA to be allowed (this is pretty common in web servers). > Being able to say "only do the matching on certificates issued by foo" > is valuable. Sure, I'm not suggesting that matching by issuer should be removed, only that rule precedence should not be determined by the issuer field setting. -- Jan Cholasta From pspacek at redhat.com Tue Oct 18 06:48:30 2016 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 18 Oct 2016 08:48:30 +0200 Subject: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server? In-Reply-To: <1476719720.3607.33.camel@redhat.com> References: <20160921100144.GA7371@redhat.com> <20160927123134.GA32730@redhat.com> <02227e30-dfcf-30c1-8a26-5a356e2f0f87@redhat.com> <1476719720.3607.33.camel@redhat.com> Message-ID: On 17.10.2016 17:55, Simo Sorce wrote: > On Mon, 2016-10-17 at 09:02 +0200, Petr Spacek wrote: >> On 27.9.2016 14:31, Jan Pazdziora wrote: >>> On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote: >>>> >>>> I've recently hit again the situation of IPA installer not happy >>>> about the provided IP address not being local to it, this time in >>>> containerized environment: >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1377973 >>>> >>>> During the discussion, we came to an interesting question: >>>> >>>> What would break if loopback addresses were allowed for IPA >>>> server? >>>> >>>> Of course, the idea is that it would only be used for installation and >>>> then IPA would change its IP address in DNS to whatever is the real IP >>>> address under which it is accessible. >>>> >>>> Where does the allow_loopback=False requirement in the installer come >>>> from and what would break if it was removed altogether? >>> >>> I also see messages like >>> >>> Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file >>> >>> in some cases. Actually, it's >>> >>> 10.11.12.13 ipa.example.com ipa >>> >>> which gets added so the message is not accurate. >>> >>> Modification of /etc/hosts itself seems unfortunate. Should the IP >>> address change in the future, there will be one more place where >>> the IP address stays hardcoded. >>> >>> I wonder why >>> >>> hosts: files dns myhostname >>> >>> isn't enough, and whether >>> >>> hosts: files myhostname dns >>> >>> might actually be better order. >> >> Theoretically yes. Practically it will break Dogtag and other components which >> are not able to cope up with link-local addresses returned from myhostname module. >> >> >>> When the value is not in /etc/hosts, >>> I see weird startup issues, presumably because individual components >>> time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps >>> it has something to do with named being up at that point, rather than >>> unreachable, just not resolving anything yet. Chicken and egg. >>> >>> I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried >>> that and have seen >>> >>> named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic >>> failure: GSSAPI Error: Unspecified GSS failure. Minor code >>> may provide more information (Server >>> ldap/localhost at EXAMPLE.TEST not found in Kerberos database): >>> bind to LDAP server failed >>> >>> which suggests something derives the hostname and thus the principal >>> from the IP address used. Why is not $HOSTNAME used everywhere? What >>> part of the system cares about the IP address (and the reverse >>> resolution)? >> >> AFAIK FQDN is used everywhere. The "localhost" name might be coming from >> Kerberos name canonicalization, which works like this: >> FQDN (name resolution) record-> IP address (IP address resolution)->new name. >> >> You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It >> should be default anyway, but why not try it explicitly. >> >> Also, I would try if dns_canonicalize_hostname=false makes any difference or not. > > Btw this attribute came up also elsewhere, I think we should consider > changing ipa-client-install (or SSSD) to make > dns_canonicalize_hostname=false the default in IPa installs. > > Should we open a ticket for that? I would leave it for Jan so we know that it has desired effect in his setup. Petr^2 Spacek >>> If overloading 127.0.0.1 with the $HOSTNAME does not work, could >>> 127.0.0.2 do the trick? It seems to work for subsequent starts (did >>> not try it during ipa-server-install) in containers. >> >> It will likely suffer with very similar problems. It if works, it works just >> accidentally and might break at any time in future. >> >> Before we touch IP address/domain name logic, we need to agree how it should >> behave. >> >> What is the purpose of --ip-address option? >> a) Specify IP addresses used in DNS. >> ab) What checks should be performed on it? >> b) To bind deamons only to specific IP addresses instead of all interfaces? >> >> I have seen requests for both. We need to decide what is the intended behavior >> and design it before making further changes. The spaghetti code is too >> intertwined for making any non-systematic changes. >> >> -- >> Petr^2 Spacek From freeipa-github-notification at redhat.com Tue Oct 18 06:55:35 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 08:55:35 +0200 Subject: [Freeipa-devel] [freeipa PR#155][synchronized] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Author: pspacek Title: #155: Build system cleanup Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/155/head:pr155 git checkout pr155 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-155.patch Type: text/x-diff Size: 12740 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 07:17:29 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 18 Oct 2016 09:17:29 +0200 Subject: [Freeipa-devel] [freeipa PR#169][opened] Replace ipaplatform's symlinks with a meta importer Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with a meta importer Action: opened PR body: """ Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/169/head:pr169 git checkout pr169 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-169.patch Type: text/x-diff Size: 4918 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 07:17:47 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 18 Oct 2016 09:17:47 +0200 Subject: [Freeipa-devel] [freeipa PR#155][comment] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Title: #155: Build system cleanup abbra commented: """ I think all these fix commits are just fine. """ See the full comment at https://github.com/freeipa/freeipa/pull/155#issuecomment-254426527 From freeipa-github-notification at redhat.com Tue Oct 18 07:21:21 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 09:21:21 +0200 Subject: [Freeipa-devel] [freeipa PR#169][comment] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Title: #169: Replace ipaplatform's symlinks with a meta importer pspacek commented: """ Uh, it is quite a lot of code to get rid of few symlinks. Is it worth? @jcholast @mbasti-rh @martbab @tomaskrizek and others? """ See the full comment at https://github.com/freeipa/freeipa/pull/169#issuecomment-254427160 From freeipa-github-notification at redhat.com Tue Oct 18 07:22:39 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 18 Oct 2016 09:22:39 +0200 Subject: [Freeipa-devel] [freeipa PR#170][opened] Mark all phony Makefile targets as .PHONY Message-ID: URL: https://github.com/freeipa/freeipa/pull/170 Author: tiran Title: #170: Mark all phony Makefile targets as .PHONY Action: opened PR body: """ https://www.gnu.org/software/make/manual/make.html#Phony-Targets A phony target is one that is not really the name of a file; rather it is just a name for a recipe to be executed when you make an explicit request. There are two reasons to use a phony target: to avoid a conflict with a file of the same name, and to improve performance. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/170/head:pr170 git checkout pr170 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-170.patch Type: text/x-diff Size: 7689 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 07:26:43 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 18 Oct 2016 09:26:43 +0200 Subject: [Freeipa-devel] [freeipa PR#169][comment] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Title: #169: Replace ipaplatform's symlinks with a meta importer tiran commented: """ I can also make the ```__init__.py.in``` go away and let everything be handled by auto-detecting the current distribution with Python's platform module. """ See the full comment at https://github.com/freeipa/freeipa/pull/169#issuecomment-254428189 From freeipa-github-notification at redhat.com Tue Oct 18 07:39:02 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 18 Oct 2016 09:39:02 +0200 Subject: [Freeipa-devel] [freeipa PR#163][comment] Do not create Object Signing certificate In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/163 Title: #163: Do not create Object Signing certificate jcholast commented: """ LGTM. """ See the full comment at https://github.com/freeipa/freeipa/pull/163#issuecomment-254430550 From freeipa-github-notification at redhat.com Tue Oct 18 08:05:50 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 18 Oct 2016 10:05:50 +0200 Subject: [Freeipa-devel] [freeipa PR#169][synchronized] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with a meta importer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/169/head:pr169 git checkout pr169 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-169.patch Type: text/x-diff Size: 5474 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 08:10:33 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 18 Oct 2016 10:10:33 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Draft for a new setup.py (WIP) tiran commented: """ @mbasti-rh I can't reproduce your problem. dnf reinstall works for me. I tested both upgrades from 4.4.2 and reinstall of my RPMs. """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-254437246 From freeipa-github-notification at redhat.com Tue Oct 18 08:48:30 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 10:48:30 +0200 Subject: [Freeipa-devel] [freeipa PR#155][comment] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Title: #155: Build system cleanup mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/152ed75ff6e55489e27c201b27ee6eb5c4db0480 https://fedorahosted.org/freeipa/changeset/651f1acac8212346fb579ff8911b43a3faf3867b https://fedorahosted.org/freeipa/changeset/7b801682a64b2ba132ba9892831f8c3f5a51caf8 https://fedorahosted.org/freeipa/changeset/01072fc8f2833e9316f534875c75714803384377 https://fedorahosted.org/freeipa/changeset/2ea66483791ef060c54f525786fbac2730813bbc https://fedorahosted.org/freeipa/changeset/8b458ce4de9cb0e072849c4fbd9257377cd4a654 https://fedorahosted.org/freeipa/changeset/7de597425f8fb6d8c5cadc8fc039729368c43ddf """ See the full comment at https://github.com/freeipa/freeipa/pull/155#issuecomment-254445717 From freeipa-github-notification at redhat.com Tue Oct 18 08:48:32 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 10:48:32 +0200 Subject: [Freeipa-devel] [freeipa PR#155][+pushed] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Title: #155: Build system cleanup Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 18 08:48:34 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 10:48:34 +0200 Subject: [Freeipa-devel] [freeipa PR#155][closed] Build system cleanup In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/155 Author: pspacek Title: #155: Build system cleanup Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/155/head:pr155 git checkout pr155 From freeipa-github-notification at redhat.com Tue Oct 18 10:03:56 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 12:03:56 +0200 Subject: [Freeipa-devel] [freeipa PR#170][comment] Mark all phony Makefile targets as .PHONY In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/170 Title: #170: Mark all phony Makefile targets as .PHONY pspacek commented: """ Hand-made Makefile is completely going away and will be auto-generated, so we do not need to spend more time on this version. """ See the full comment at https://github.com/freeipa/freeipa/pull/170#issuecomment-254463481 From freeipa-github-notification at redhat.com Tue Oct 18 10:03:57 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 12:03:57 +0200 Subject: [Freeipa-devel] [freeipa PR#170][closed] Mark all phony Makefile targets as .PHONY In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/170 Author: tiran Title: #170: Mark all phony Makefile targets as .PHONY Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/170/head:pr170 git checkout pr170 From freeipa-github-notification at redhat.com Tue Oct 18 10:04:08 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 12:04:08 +0200 Subject: [Freeipa-devel] [freeipa PR#170][+rejected] Mark all phony Makefile targets as .PHONY In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/170 Title: #170: Mark all phony Makefile targets as .PHONY Label: +rejected From freeipa-github-notification at redhat.com Tue Oct 18 10:19:20 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 12:19:20 +0200 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap mbasti-rh commented: """ works for me """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-254466745 From freeipa-github-notification at redhat.com Tue Oct 18 10:16:56 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 12:16:56 +0200 Subject: [Freeipa-devel] [freeipa PR#171][opened] Build system cleanup phase 2 Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Author: pspacek Title: #171: Build system cleanup phase 2 Action: opened PR body: """ This merges all the configure scripts into one modern, including client. The end state will be one configure script with appropriate options which will allow to build only client as necessary. Client-only build does not work right now so it broke ONLY_CLIENT option in SPEC file. I'm sending it early so we can get review and merge it sooner rather than later. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/171/head:pr171 git checkout pr171 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-171.patch Type: text/x-diff Size: 8190906 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 10:40:55 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 18 Oct 2016 12:40:55 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template jcholast commented: """ Not everyone uses vim. I'd like the comments visually close to the relevant commit message part, otherwise the visual guides in them do not seem very useful to me. I'd be fine with having no comments altogether too. """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-254471065 From mbasti at redhat.com Tue Oct 18 10:50:19 2016 From: mbasti at redhat.com (Martin Basti) Date: Tue, 18 Oct 2016 12:50:19 +0200 Subject: [Freeipa-devel] [help] In-Reply-To: References: Message-ID: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> On 18.10.2016 03:28, ?? wrote: > Hello everyone, > I'm using freeipa, and having a test and research with the > function of freeipa. At the same time, I have carried on the Chinese > translation to the web interface, also added own log module in web > interface, referring to the following screenshots. However, for these > changes I don't know how to interact with the community. Is there a > administrator to review these changes? Who should I send mail to? > Please help me. Thank you very much! > > > Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Tue Oct 18 10:54:47 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 12:54:47 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template mbasti-rh commented: """ +1 for not having comments there """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-254473740 From freeipa-github-notification at redhat.com Tue Oct 18 11:02:02 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Tue, 18 Oct 2016 13:02:02 +0200 Subject: [Freeipa-devel] [freeipa PR#157][synchronized] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Author: mzidek-rh Title: #157: git: Add commit template Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/157/head:pr157 git checkout pr157 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-157.patch Type: text/x-diff Size: 674 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 11:03:27 2016 From: freeipa-github-notification at redhat.com (mzidek-rh) Date: Tue, 18 Oct 2016 13:03:27 +0200 Subject: [Freeipa-devel] [freeipa PR#157][comment] git: Add commit template In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/157 Title: #157: git: Add commit template mzidek-rh commented: """ Comments deleted. """ See the full comment at https://github.com/freeipa/freeipa/pull/157#issuecomment-254475465 From freeipa-github-notification at redhat.com Tue Oct 18 10:28:19 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 18 Oct 2016 12:28:19 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 8234025 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 12:04:54 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 14:04:54 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ - python2-dateutil and python2-sss-murmur packages are missing in with_lint condition. - the message from import error was confusing to me: > ipaserver/plugins/dogtag.py:244: No module named backports_abc > ipaserver/plugins/dogtag.py:244: No module named backports_abc In person, we were talking about some changes in the message. I would try something like this: > argv[0]: ipaserver/plugins/dogtag.py:244: No module named backports_abc. Ignoring missing module. It might be required only for lint or only conditionally. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254487503 From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 18 12:12:56 2016 From: bind-dyndb-ldap-github-notification at redhat.com (sgallagher) Date: Tue, 18 Oct 2016 14:12:56 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#3][opened] spec: Add libuuid-devel to BuildRequires Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/3 Author: sgallagher Title: #3: spec: Add libuuid-devel to BuildRequires Action: opened PR body: """ Signed-off-by: Stephen Gallagher """ To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/3/head:pr3 git checkout pr3 -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pr-3.patch Type: text/x-diff Size: 853 bytes Desc: not available URL: From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 18 12:33:05 2016 From: bind-dyndb-ldap-github-notification at redhat.com (sgallagher) Date: Tue, 18 Oct 2016 14:33:05 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#3][closed] spec: Add libuuid-devel to BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/3 Author: sgallagher Title: #3: spec: Add libuuid-devel to BuildRequires Action: closed To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/3/head:pr3 git checkout pr3 From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 18 12:33:30 2016 From: bind-dyndb-ldap-github-notification at redhat.com (sgallagher) Date: Tue, 18 Oct 2016 14:33:30 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#4][opened] spec: Re-sync spec to Fedora Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/4 Author: sgallagher Title: #4: spec: Re-sync spec to Fedora Action: opened PR body: """ Signed-off-by: Stephen Gallagher """ To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/4/head:pr4 git checkout pr4 From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 18 12:57:50 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 14:57:50 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#3][reopened] spec: Add libuuid-devel to BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/3 Author: sgallagher Title: #3: spec: Add libuuid-devel to BuildRequires Action: reopened To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/3/head:pr3 git checkout pr3 From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 18 12:58:24 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 14:58:24 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#3][+ack] spec: Add libuuid-devel to BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/3 Title: #3: spec: Add libuuid-devel to BuildRequires Label: +ack From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 18 13:02:11 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 15:02:11 +0200 Subject: [Freeipa-devel] =?utf-8?q?WARNING=3A_MERGED_=5Bbind-dyndb-ldap_PR?= =?utf-8?q?=233=5D=5Bclosed=5D_spec=3A_Add_libuuid-devel_to_BuildRequires?= In-Reply-To: References: Message-ID: *WARNING: this pull request has been merged!* This is only mirrored repo thus any changes will be erased. Please push commit(s) to authoritative repository. URL: https://github.com/freeipa/bind-dyndb-ldap/pull/3 Author: sgallagher Title: #3: spec: Add libuuid-devel to BuildRequires Action: closed To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/3/head:pr3 git checkout pr3 From bind-dyndb-ldap-github-notification at redhat.com Tue Oct 18 13:15:40 2016 From: bind-dyndb-ldap-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 15:15:40 +0200 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#2][+ack] fix ldif syntax and add idnsTemplateAttribute In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/2 Title: #2: fix ldif syntax and add idnsTemplateAttribute Label: +ack From freeipa-github-notification at redhat.com Tue Oct 18 14:07:50 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Tue, 18 Oct 2016 16:07:50 +0200 Subject: [Freeipa-devel] [freeipa PR#158][synchronized] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Author: pvomacka Title: #158: WebUI: update Patternfly and Bootstrap Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/158/head:pr158 git checkout pr158 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-158.patch Type: text/x-diff Size: 480804 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 18 14:09:30 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Tue, 18 Oct 2016 16:09:30 +0200 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap pvomacka commented: """ I added minimized patternfly and boostrap javascript files instead of classic ones. """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-254518940 From freeipa-github-notification at redhat.com Tue Oct 18 14:41:39 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 18 Oct 2016 16:41:39 +0200 Subject: [Freeipa-devel] [freeipa PR#165][+ack] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all Label: +ack From freeipa-github-notification at redhat.com Tue Oct 18 15:21:19 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:21:19 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all mbasti-rh commented: """ Ticket is in already closed milestone, please change ticket in the commit message. """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-254541820 From freeipa-github-notification at redhat.com Tue Oct 18 15:21:39 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:21:39 +0200 Subject: [Freeipa-devel] [freeipa PR#165][-ack] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all Label: -ack From freeipa-github-notification at redhat.com Tue Oct 18 15:25:40 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:25:40 +0200 Subject: [Freeipa-devel] [freeipa PR#160][+ack] Reverted the assertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Title: #160: Reverted the assertion for replica uninstall returncode Label: +ack From freeipa-github-notification at redhat.com Tue Oct 18 15:31:08 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:31:08 +0200 Subject: [Freeipa-devel] [freeipa PR#160][+pushed] Reverted the assertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Title: #160: Reverted the assertion for replica uninstall returncode Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 18 15:31:10 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:31:10 +0200 Subject: [Freeipa-devel] [freeipa PR#160][comment] Reverted the assertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Title: #160: Reverted the assertion for replica uninstall returncode mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/5710ecddcaea7b00fbbc2ee24b845f7a4ac90f57 ipa-4-4: https://fedorahosted.org/freeipa/changeset/66d7872e43fefeb341e71862b82a431bf2bb7791 """ See the full comment at https://github.com/freeipa/freeipa/pull/160#issuecomment-254545138 From freeipa-github-notification at redhat.com Tue Oct 18 15:31:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:31:11 +0200 Subject: [Freeipa-devel] [freeipa PR#160][closed] Reverted the assertion for replica uninstall returncode In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/160 Author: ofayans Title: #160: Reverted the assertion for replica uninstall returncode Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/160/head:pr160 git checkout pr160 From freeipa-github-notification at redhat.com Tue Oct 18 15:34:39 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:34:39 +0200 Subject: [Freeipa-devel] [freeipa PR#116][+pushed] Add fix for no-hbac-allow option in server install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Title: #116: Add fix for no-hbac-allow option in server install Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 18 15:34:41 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:34:41 +0200 Subject: [Freeipa-devel] [freeipa PR#116][comment] Add fix for no-hbac-allow option in server install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Title: #116: Add fix for no-hbac-allow option in server install mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/a42059228018839ae2656c27f5b00d96bc935ee3 """ See the full comment at https://github.com/freeipa/freeipa/pull/116#issuecomment-254546299 From freeipa-github-notification at redhat.com Tue Oct 18 15:34:42 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 18 Oct 2016 17:34:42 +0200 Subject: [Freeipa-devel] [freeipa PR#116][closed] Add fix for no-hbac-allow option in server install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/116 Author: Akasurde Title: #116: Add fix for no-hbac-allow option in server install Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/116/head:pr116 git checkout pr116 From freeipa-github-notification at redhat.com Tue Oct 18 15:48:12 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 17:48:12 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ This version fixes minor problems in error reporing and should have no other visible effect. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254550722 From freeipa-github-notification at redhat.com Tue Oct 18 15:47:12 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Tue, 18 Oct 2016 17:47:12 +0200 Subject: [Freeipa-devel] [freeipa PR#171][synchronized] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Author: pspacek Title: #171: Build system cleanup phase 2 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/171/head:pr171 git checkout pr171 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-171.patch Type: text/x-diff Size: 8193537 bytes Desc: not available URL: From zhenglei at kylinos.cn Wed Oct 19 01:35:04 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Wed, 19 Oct 2016 09:35:04 +0800 Subject: [Freeipa-devel] [help] In-Reply-To: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> References: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> Message-ID: Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. ------------------ ?? ?????????? -------------------------- ?????? ?? Phone?18684703229 Email?zhenglei at kylinos.cn Company????????????? Address???????????????????? ------------------ Original ------------------ From: "Martin Basti"; Date: Tue, Oct 18, 2016 06:50 PM To: "??"; "freeipa-devel"; Subject: Re: [Freeipa-devel] [help] On 18.10.2016 03:28, ?? wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Oct 19 05:14:59 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Wed, 19 Oct 2016 07:14:59 +0200 Subject: [Freeipa-devel] [freeipa PR#165][synchronized] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Author: mirielka Title: #165: Tests: Verify that cert-find show CA without --all Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/165/head:pr165 git checkout pr165 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-165.patch Type: text/x-diff Size: 1913 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 05:15:41 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Wed, 19 Oct 2016 07:15:41 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all mirielka commented: """ Sorry for that, I created new ticket and changed commit message. """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-254712487 From freeipa-github-notification at redhat.com Wed Oct 19 07:12:12 2016 From: freeipa-github-notification at redhat.com (shanyin) Date: Wed, 19 Oct 2016 09:12:12 +0200 Subject: [Freeipa-devel] [freeipa PR#172][opened] fix pki-tomcat error after uninstall Message-ID: URL: https://github.com/freeipa/freeipa/pull/172 Author: shanyin Title: #172: fix pki-tomcat error after uninstall Action: opened PR body: """ I set up the freeipa(version 4.3.1) environment in Ubuntu 16.04, there is a reconfigure error found after uninstall. The error message is ERROR CA configuration failed. The pki log message shows that pkispawn : ERROR ....... OSError: [Errno 2] No such file or directory! The reason is that there is no pki-tomcatd.target.wants directory in /etc/systemd/system/ directory. Creating the directory can solve the problem. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/172/head:pr172 git checkout pr172 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-172.patch Type: text/x-diff Size: 947 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 19 08:03:57 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Oct 2016 10:03:57 +0200 Subject: [Freeipa-devel] [help] In-Reply-To: References: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> Message-ID: On 19.10.2016 03:35, ?? wrote: > Hello, > In the process of using freeipa, we found a lot of content without > Chinese translation. In order to we can better use the platform, > we made a Chinese translation. Sorry but I don't see any updates in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 If you do a custom/manual translations this will not scale and you will do the same every release > I think the translation work for freeipa internationalization > promotion also can have certain help. In addition, in use process, we > found that when test the corresponding function of operation in the > Web interface is not a straightforward logging which needs to query in > the background, and it may not be intuitive and convenient. In order > to we can intuitively record what we have done the operation in the > Web interface, we do the log module plug-ins. > > webUI is just layer on top of our API calls. > > > > ------------------ > ?? > ?????????? > -------------------------- > ?????? ?? > Phone?18684703229 > Email?zhenglei at kylinos.cn > Company????????????? > Address???????????????????? > ------------------ Original ------------------ > *From: * "Martin Basti"; > *Date: * Tue, Oct 18, 2016 06:50 PM > *To: * "??"; > "freeipa-devel"; > *Subject: * Re: [Freeipa-devel] [help] > > > > On 18.10.2016 03:28, ?? wrote: >> Hello everyone, >> I'm using freeipa, and having a test and research with the >> function of freeipa. At the same time, I have carried on the Chinese >> translation to the web interface, also added own log module in web >> interface, referring to the following screenshots. However, for these >> changes I don't know how to interact with the community. Is there a >> administrator to review these changes? Who should I send mail to? >> Please help me. Thank you very much! >> >> >> > > Hello, > > at first you can write here what is your goal, what are your use cases > and how do you plan to achieve that. > > Then, if we agree on solution, you can send code as pull request to > our github repository https://github.com/freeipa/freeipa > > > Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Oct 19 08:24:28 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Oct 2016 10:24:28 +0200 Subject: [Freeipa-devel] [help] In-Reply-To: References: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> Message-ID: <308577c3-5003-010c-aa5f-52d39a04b47d@redhat.com> On 10/19/2016 10:03 AM, Martin Basti wrote: > > > On 19.10.2016 03:35, ?? wrote: >> Hello, >> In the process of using freeipa, we found a lot of content without Chinese >> translation. In order to we can better use the platform, > >> we made a Chinese translation. > Sorry but I don't see any updates in zanata > https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 > > If you do a custom/manual translations this will not scale and you will do the > same every release > >> I think the translation work for freeipa internationalization promotion also >> can have certain help. In addition, in use process, we found that when test >> the corresponding function of operation in the Web interface is not a >> straightforward logging which needs to query in the background, and it may not >> be intuitive and convenient. In order to we can intuitively record what we >> have done the operation in the Web interface, we do the log module plug-ins. >> >> > webUI is just layer on top of our API calls. Note that there are some parts of Web UI that aren't translated. Mainly login page. It's because translations are fetched by API call which needs successful auth. > > >> >> >> >> ------------------ >> ?? >> ?????????? >> -------------------------- >> ?????? ?? >> Phone?18684703229 >> Email?zhenglei at kylinos.cn >> Company????????????? >> Address???????????????????? >> ------------------ Original ------------------ >> *From: * "Martin Basti"; >> *Date: * Tue, Oct 18, 2016 06:50 PM >> *To: * "??"; "freeipa-devel"; >> *Subject: * Re: [Freeipa-devel] [help] >> >> >> >> On 18.10.2016 03:28, ?? wrote: >>> Hello everyone, >>> I'm using freeipa, and having a test and research with the function of >>> freeipa. At the same time, I have carried on the Chinese translation to the >>> web interface, also added own log module in web interface, referring to the >>> following screenshots. However, for these changes I don't know how to >>> interact with the community. Is there a administrator to review these >>> changes? Who should I send mail to? Please help me. Thank you very much! >>> >>> >>> >> >> Hello, >> >> at first you can write here what is your goal, what are your use cases and how >> do you plan to achieve that. >> >> Then, if we agree on solution, you can send code as pull request to our github >> repository https://github.com/freeipa/freeipa >> >> >> Martin^2 > > > -- Petr Vobornik From freeipa-github-notification at redhat.com Wed Oct 19 08:25:19 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 10:25:19 +0200 Subject: [Freeipa-devel] [freeipa PR#169][synchronized] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with a meta importer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/169/head:pr169 git checkout pr169 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-169.patch Type: text/x-diff Size: 4271 bytes Desc: not available URL: From zhenglei at kylinos.cn Wed Oct 19 08:30:25 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Wed, 19 Oct 2016 16:30:25 +0800 Subject: [Freeipa-devel] [help] In-Reply-To: References: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> Message-ID: ------------------ ?? ?????????? -------------------------- ?????? ?? Phone?18684703229 Email?zhenglei at kylinos.cn Company????????????? Address???????????????????? ------------------ Original ------------------ From: "Martin Basti"; Date: Wed, Oct 19, 2016 04:03 PM To: "??"; "freeipa-devel"; Subject: Re: [Freeipa-devel] [help] On 19.10.2016 03:35, ?? wrote: Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. Sorry but I don't see any updates in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 If you do a custom/manual translations this will not scale and you will do the same every release I have applied to join Chinese translation organization in zanata https://fedora.zanata.org/language/view/zh-CN?dswid=2727, but there is no reply. And I have tried to translate in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750, But there seems to be no permission to modify. Whether I need to put the translation file zh_CN.po to create pull request against freeipa/freeipa on github? I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. webUI is just layer on top of our API calls. I know, What I mean is that no matter we are in API calls mode to manipulate freeipa or Web UI way, we all can intuitive see clearly under the log module. The log module function is to record any of our operation. ------------------ ?? ?????????? -------------------------- ?????? ?? Phone?18684703229 Email?zhenglei at kylinos.cn Company????????????? Address???????????????????? ------------------ Original ------------------ From: "Martin Basti"; Date: Tue, Oct 18, 2016 06:50 PM To: "??"; "freeipa-devel"; Subject: Re: [Freeipa-devel] [help] On 18.10.2016 03:28, ?? wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Oct 19 08:31:52 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 10:31:52 +0200 Subject: [Freeipa-devel] [freeipa PR#169][synchronized] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with a meta importer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/169/head:pr169 git checkout pr169 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-169.patch Type: text/x-diff Size: 4310 bytes Desc: not available URL: From ofayans at redhat.com Wed Oct 19 10:32:19 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 19 Oct 2016 12:32:19 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: References: <57A07FE4.8000904@redhat.com> <2b0ed7fe-f0bc-7137-bdc1-b0758ffe9cd6@redhat.com> <20160914154119.mkk2ma7tvks55xsu@redhat.com> <97eaa313-e889-cd4a-e900-9e88596577a0@redhat.com> <20160914155320.iowrijrq3z62evoo@redhat.com> <1af52e6c-c24b-d58b-ccf5-a85c5c290e0c@redhat.com> <20160914165348.GE2761@p.Speedport_W_724V_Typ_A_05011603_00_009> <59763ea7-2ab5-bdc2-72c1-489a462f78ef@redhat.com> Message-ID: <6089c103-ab56-62f7-971c-a41710eee22f@redhat.com> Hi Martin, As you suggested, I've extended the test_xmlrpc/test_add_remove_cert_cmd.py to contain basic tests for certs in idoverrides. The integration part still needs some polishing in the part related to user lookup by cert On 10/14/2016 03:57 PM, Martin Babinsky wrote: > On 10/14/2016 03:48 PM, Oleg Fayans wrote: >> So, did I understand correctly, that there would be 2 patches: one >> containing test for basic idoverrides functionality without >> AD-integration, and the second one - with AD-integration and an sssd >> check, correct? >> I guess, the >> freeipa-ofayans-0050.1-Automated-test-for-certs-in-idoverrides-feature.patch >> >> might be a good candidate for the first one, I only have to change the >> filename to test_idviews.py, right? >> > > Oleg, we already have XMLRPC tests for idoverrides: > > ipatests/test_xmlrpc/test_idviews_plugin.py > > Is there any particular reason why not to extend them with add > cert/remove cert operations? > > Even better, you can extend > `ipatests/test_xmlrpc/test_add_remove_cert_cmd.py` suite by doing the > same set of tests on idoverrideuser objects. > > Or am I missing something? > >> On 09/15/2016 10:32 AM, Martin Basti wrote: >>> >>> >>> On 15.09.2016 10:10, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> The file was renamed. Did I understand correctly that for now we are >>>> leaving the test as is and are planning to extend it later? >>> >>> I would like to have there SSSD check involved, please use what Summit >>> recommends. No new test cases. >>> >>> And this can be done by separate patch, I want to have API/CLI >>> certificate override tests for non-AD idview (extending current tests I >>> posted in this thread) >>> >>> Martin^2 >>>> >>>> On 09/15/2016 09:49 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 14.09.2016 18:53, Sumit Bose wrote: >>>>>> On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote: >>>>>>> >>>>>>> On 14.09.2016 17:53, Alexander Bokovoy wrote: >>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 14.09.2016 17:41, Alexander Bokovoy wrote: >>>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>>> 1) >>>>>>>>>>> I still don't see the reason why AD trust is needed. Default >>>>>>>>>>> trust ID view is added just by ipa-adtrust-install, adding >>>>>>>>>>> trust is not needed for current implementation. You don't >>>>>>>>>>> need AD for this, IDviews is generic feature not just for >>>>>>>>>>> AD. Is that user configured on AD side? >>>>>>>>>> You cannot add non-AD user to 'default trust view', so you will >>>>>>>>>> not be >>>>>>>>>> able to set up certificates to ID override which does not exist. >>>>>>>>>> >>>>>>>>>> For non-'default trust view' you can add both IPA and AD users, >>>>>>>>>> so using >>>>>>>>>> some other view and then assign certificate for a ID override in >>>>>>>>>> that >>>>>>>>>> one. >>>>>>>>>> >>>>>>>>> Ok then, but anyway I would like to see API/CLI tests for this >>>>>>>>> feature with proper output validation. >>>>>>>>> >>>>>>>>> >>>>>>>>> How can be this tested with SSSD? >>>>>>>> You need to log into the system with a certificate... >>>>>>> Is this possible from test? We are logged remotely as root, is >>>>>>> there any >>>>>>> cmdline util which allows us to test certificate against AD user? >>>>>> >>>>>> You can use 'sss_ssh_authorizedkeys aduser at ad.domain' which should >>>>>> return the ssh key derived from the public key in the certificate. >>>>>> This >>>>>> should work for certificate stored in AD as well as for overrides. >>>>>> >>>>>> You can also you the DBus lookup by certificate as described in >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate >>>>>> >>>>>> . >>>>>> >>>>>> HTH >>>>>> >>>>>> bye, >>>>>> Sumit >>>>> >>>>> Thank you Alexander and Summit for hints. >>>>> >>>>> Oleg I realized we don't have any other idviews integration tests >>>>> >>>>> So I propose to rename test file you are adding to test_idviews.py. We >>>>> can add more testcases for idviews there later >>>>> >>>>> Martin^2 >>>>>>> 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 >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0089-tests-Added-basic-tests-for-certs-in-idoverrides.patch Type: text/x-patch Size: 3947 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 10:45:21 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 19 Oct 2016 12:45:21 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ ACK to Build: modernize SASL library detection Build: modernize XMLRPC-client library detection Build: cleanup INI library detection It would be good to push them if you do not want to wait for review of other patches. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254777931 From freeipa-github-notification at redhat.com Wed Oct 19 11:16:01 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 19 Oct 2016 13:16:01 +0200 Subject: [Freeipa-devel] [freeipa PR#169][comment] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Title: #169: Replace ipaplatform's symlinks with a meta importer pspacek commented: """ NACK freeipa-server-4.4.90.201610190959GITf8012c0-0.fc24.x86_64 it broke following call which is used in RPM `%post client` scriptlet: ~~~ $ python2 -c 'from ipapython.certdb import update_ipa_nssdb; update_ipa_nssdb()' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/site-packages/ipapython/certdb.py", line 28, in from ipaplatform.paths import paths ImportError: No module named paths ~~~ """ See the full comment at https://github.com/freeipa/freeipa/pull/169#issuecomment-254783841 From freeipa-github-notification at redhat.com Wed Oct 19 10:44:41 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Wed, 19 Oct 2016 12:44:41 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 8236809 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 11:27:17 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 13:27:17 +0200 Subject: [Freeipa-devel] [freeipa PR#169][synchronized] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with a meta importer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/169/head:pr169 git checkout pr169 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-169.patch Type: text/x-diff Size: 4354 bytes Desc: not available URL: From dkupka at redhat.com Wed Oct 19 11:31:35 2016 From: dkupka at redhat.com (David Kupka) Date: Wed, 19 Oct 2016 13:31:35 +0200 Subject: [Freeipa-devel] Refactoring certificate-handling code: Staging branch and copr Message-ID: <4ca5caf3-80c9-8f8e-d372-21ab63ae502f@redhat.com> Hello! If you're interested in certificate refactoring you can find our staging branch here [0] and builds in copr repository here [1]. Currently the branch is identical to master and copr contains some test builds but this will change soon. [0] https://github.com/dkupka/freeipa/tree/refactoring-certificates [1] https://copr.fedorainfracloud.org/coprs/dkupka/freeipa-refactoring-certificates/ -- David Kupka From freeipa-github-notification at redhat.com Wed Oct 19 11:39:22 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 13:39:22 +0200 Subject: [Freeipa-devel] [freeipa PR#171][+ack] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 Label: +ack From freeipa-github-notification at redhat.com Wed Oct 19 11:39:23 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 13:39:23 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 stlaz commented: """ ACK, works for me. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254788258 From freeipa-github-notification at redhat.com Wed Oct 19 11:50:56 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 13:50:56 +0200 Subject: [Freeipa-devel] [freeipa PR#169][synchronized] Replace ipaplatform's symlinks with a meta importer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with a meta importer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/169/head:pr169 git checkout pr169 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-169.patch Type: text/x-diff Size: 4354 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 19 11:56:07 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Oct 2016 13:56:07 +0200 Subject: [Freeipa-devel] [help] In-Reply-To: References: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> Message-ID: <28ae586a-caa0-1c9a-a24b-c05391f96992@redhat.com> Comments inline On 19.10.2016 10:30, ?? wrote: > > > > > > > ------------------ > ?? > ?????????? > -------------------------- > ?????? ?? > Phone?18684703229 > Email?zhenglei at kylinos.cn > Company????????????? > Address???????????????????? > ------------------ Original ------------------ > *From: * "Martin Basti"; > *Date: * Wed, Oct 19, 2016 04:03 PM > *To: * "??"; > "freeipa-devel"; > *Subject: * Re: [Freeipa-devel] [help] > > > > On 19.10.2016 03:35, ?? wrote: >> Hello, >> In the process of using freeipa, we found a lot of content without >> Chinese translation. In order to we can better use the platform, > >> we made a Chinese translation. > Sorry but I don't see any updates in zanata > https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 > > If you do a custom/manual translations this will not scale and you > will do the same every release > > > I have applied to join Chinese translation organization in zanata > https://fedora.zanata.org/language/view/zh-CN?dswid=2727, but there is > no reply. And I have tried to translate in zanata > https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750, > But there seems to be no permission to modify. Whether I need to put > the translation file zh_CN.po to create pull request against > freeipa/freeipa on github? No please don't, we always generate .po files from zanata before releases, so all changes are overwritten Ok, let me know how the adding you to zanata continue, if nobody will answer for longer time, I can put you just to freeIPA project as translator. > > > >> I think the translation work for freeipa internationalization >> promotion also can have certain help. In addition, in use process, we >> found that when test the corresponding function of operation in the >> Web interface is not a straightforward logging which needs to query >> in the background, and it may not be intuitive and convenient. In >> order to we can intuitively record what we have done the operation in >> the Web interface, we do the log module plug-ins. >> >> > webUI is just layer on top of our API calls. > > > I know, What I mean is that no matter we are in API calls mode to > manipulate freeipa or Web UI way, we all can intuitive see clearly > under the log module. The log module function is to record any of our > operation. > > I think that they can be many caveats (access control, replication, etc.) maybe would be good to see your code (you can send PR) how is you current implementation. Martin >> >> >> >> ------------------ >> ?? >> ?????????? >> -------------------------- >> ?????? ?? >> Phone?18684703229 >> Email?zhenglei at kylinos.cn >> Company????????????? >> Address???????????????????? >> ------------------ Original ------------------ >> *From: * "Martin Basti"; >> *Date: * Tue, Oct 18, 2016 06:50 PM >> *To: * "??"; >> "freeipa-devel"; >> *Subject: * Re: [Freeipa-devel] [help] >> >> >> >> On 18.10.2016 03:28, ?? wrote: >>> Hello everyone, >>> I'm using freeipa, and having a test and research with the >>> function of freeipa. At the same time, I have carried on the Chinese >>> translation to the web interface, also added own log module in web >>> interface, referring to the following screenshots. However, for >>> these changes I don't know how to interact with the community. Is >>> there a administrator to review these changes? Who should I send >>> mail to? Please help me. Thank you very much! >>> >>> >>> >> >> Hello, >> >> at first you can write here what is your goal, what are your use >> cases and how do you plan to achieve that. >> >> Then, if we agree on solution, you can send code as pull request to >> our github repository https://github.com/freeipa/freeipa >> >> >> Martin^2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Oct 19 12:19:28 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 14:19:28 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires stlaz commented: """ For some reason, after running `sudo dnf builddep freeipa.spec`, which is successful, if I run the same command again, if fails: ``` [login at vm freeipa-git]$ sudo dnf builddep --spec freeipa.spec Last metadata expiration check: 0:23:03 ago on Wed Oct 19 13:53:25 2016. Failed to open: 'freeipa.spec', not a valid spec file. Error: Some packages could not be found. ``` Adding `-v` or `-d 10` options did not provide any more useful output about this error. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254795768 From freeipa-github-notification at redhat.com Wed Oct 19 12:20:37 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 14:20:37 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires stlaz commented: """ For some reason, after running `sudo dnf builddep freeipa.spec`, which is successful, if I run the same command again, if fails: ``` [login at vm freeipa-git]$ sudo dnf builddep --spec freeipa.spec Last metadata expiration check: 0:23:03 ago on Wed Oct 19 13:53:25 2016. Failed to open: 'freeipa.spec', not a valid spec file. Error: Some packages could not be found. ``` Adding `-v` or `-d 10` options did not provide any more useful output about this error. This may possibly be a dnf bug. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254795768 From freeipa-github-notification at redhat.com Wed Oct 19 12:29:53 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 19 Oct 2016 14:29:53 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ -ACK, my comments has not been addressed yet. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254797969 From freeipa-github-notification at redhat.com Wed Oct 19 12:39:12 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 19 Oct 2016 14:39:12 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ Justification is above, please push. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800046 From freeipa-github-notification at redhat.com Wed Oct 19 12:39:21 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 14:39:21 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires stlaz commented: """ For some reason, after running `sudo dnf builddep freeipa.spec`, which is successful, if I run the same command again, if fails: ``` [login at vm freeipa-git]$ sudo dnf builddep --spec freeipa.spec Last metadata expiration check: 0:23:03 ago on Wed Oct 19 13:53:25 2016. Failed to open: 'freeipa.spec', not a valid spec file. Error: Some packages could not be found. ``` Adding `-v` or `-d 10` options did not provide any more useful output about this error. This may possibly be a dnf bug. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254795768 From freeipa-github-notification at redhat.com Wed Oct 19 12:39:31 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 14:39:31 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires stlaz commented: """ For some reason, after running `sudo dnf builddep freeipa.spec`, which is successful, if I run the same command again, if fails: ``` [login at vm freeipa-git]$ sudo dnf builddep --spec freeipa.spec Last metadata expiration check: 0:23:03 ago on Wed Oct 19 13:53:25 2016. Failed to open: 'freeipa.spec', not a valid spec file. Error: Some packages could not be found. ``` Adding `-v` or `-d 10` options did not provide any more useful output about this error. This may possibly be a dnf bug. edit: This was done on minimal systems with "Development Tools" group installed. The very same .spec file works on other systems, though. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254795768 From freeipa-github-notification at redhat.com Wed Oct 19 12:41:28 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 14:41:28 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 stlaz commented: """ +1 to push, the comments were added to outdated diffs so I thought them resolved. They are now. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800566 From freeipa-github-notification at redhat.com Wed Oct 19 12:41:30 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 19 Oct 2016 14:41:30 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ I am sorry I still do not agree with popt change reducing 3lines to 1 is not huge simplification. And it does not work on rhel7.2 """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800570 From freeipa-github-notification at redhat.com Wed Oct 19 12:42:55 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 19 Oct 2016 14:42:55 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ and the explanation for changing curl is not appropriate. -1 """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254800904 From freeipa-github-notification at redhat.com Wed Oct 19 12:43:08 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 19 Oct 2016 14:43:08 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires martbab commented: """ On F24 you need to explicitly install python-srpm-macros due to broken package dependencies dnf install -y python-srpm-macros otherwise dnf/rpm is unable to expand python-specific macros in the spec and fails. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254800991 From freeipa-github-notification at redhat.com Wed Oct 19 12:51:03 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 19 Oct 2016 14:51:03 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ BTW. previously it was possible to build just a client code. But after these changes configure will require to have installed even daemon dependencies If someone decide to build just a client. Is there a reason why there is not a configure time option for such use-case. It would skip detections of build requirements for daemon part. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254802847 From freeipa-github-notification at redhat.com Wed Oct 19 12:51:04 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 19 Oct 2016 14:51:04 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ I consider CURL topic to be just bikesheding. Ad POPT: RHEL is going to require explicit configuration as designed in http://www.freeipa.org/page/V4/Build_system_refactoring because you have to explicitly disable missing checks etc. anyway. At the same time you can provide correct POPT flags. If RHEL packager disagrees we can use some auto-magic but I would rather avoid it whenever possible. For reasons above, I think that upstream version should use pkgconfig as it is preferred way for library auto-detection. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254802857 From freeipa-github-notification at redhat.com Wed Oct 19 12:53:12 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 19 Oct 2016 14:53:12 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn If you read the pull request description you will notice that client-only build will be solved later on. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254803410 From freeipa-github-notification at redhat.com Wed Oct 19 13:09:51 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 15:09:51 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 33721 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 13:14:29 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 15:14:29 +0200 Subject: [Freeipa-devel] [freeipa PR#169][edited] Replace ipaplatform's symlinks with __path__ In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with __path__ Action: edited Changed field: title Original value: """ Replace ipaplatform's symlinks with a meta importer """ From freeipa-github-notification at redhat.com Wed Oct 19 13:15:58 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 15:15:58 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 33749 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 13:19:19 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 19 Oct 2016 15:19:19 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 mbasti-rh commented: """ I see just bikeshading here, on IRC Petr1 agreed that this should be pushed and incrementally upgraded according our needs """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254809761 From freeipa-github-notification at redhat.com Wed Oct 19 13:21:41 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 15:21:41 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 35138 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 13:24:29 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 19 Oct 2016 15:24:29 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 35116 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 13:30:01 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 19 Oct 2016 15:30:01 +0200 Subject: [Freeipa-devel] [freeipa PR#171][synchronized] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Author: pspacek Title: #171: Build system cleanup phase 2 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/171/head:pr171 git checkout pr171 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-171.patch Type: text/x-diff Size: 8197854 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 13:31:03 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Wed, 19 Oct 2016 15:31:03 +0200 Subject: [Freeipa-devel] [freeipa PR#171][synchronized] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Author: pspacek Title: #171: Build system cleanup phase 2 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/171/head:pr171 git checkout pr171 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-171.patch Type: text/x-diff Size: 8193537 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 13:58:34 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 19 Oct 2016 15:58:34 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ I see you need to increase patch_count and not to have proper review """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254820687 From freeipa-github-notification at redhat.com Wed Oct 19 14:03:53 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 19 Oct 2016 16:03:53 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all tomaskrizek commented: """ Ticket/commit msg seems to be correct now. """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-254822204 From freeipa-github-notification at redhat.com Wed Oct 19 14:03:55 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 19 Oct 2016 16:03:55 +0200 Subject: [Freeipa-devel] [freeipa PR#165][+ack] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all Label: +ack From pvoborni at redhat.com Wed Oct 19 14:38:45 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Oct 2016 16:38:45 +0200 Subject: [Freeipa-devel] Limiting pull request notification sizes Message-ID: Looking at: [Freeipa-devel] [freeipa PR#171][synchronized] Build system cleanup phase 2 I see that the attached freeipa-pr-171.patch has 7.8 MB. With couple forced pushed to the private branch it creates quite big traffic a takes space. Is it possible to limit sizes of these attachments to let's say 50KB? I.e., I would be interested in the small patches but let's read the large ones on GitHub. -- Petr Vobornik From ofayans at redhat.com Wed Oct 19 14:54:16 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Wed, 19 Oct 2016 16:54:16 +0200 Subject: [Freeipa-devel] [Test][Patch-0047] Added a test for Ticket N 5964 In-Reply-To: <8caa3b3a-54a6-e168-6304-09ce8fb60a7f@redhat.com> References: <5762BBDD.4010502@redhat.com> <5763AA17.60207@redhat.com> <5763C073.5020503@redhat.com> <577113B2.1080904@redhat.com> <8ada929c-ebff-b8ce-6f1f-ae65fb8b1ba2@redhat.com> <577FAD77.7080504@redhat.com> <9149be7c-ee3d-42e5-16fb-fd0c0f351bb8@redhat.com> <57A1E76F.9@redhat.com> <478f33da-10d4-0994-e588-b28ca002b3b4@redhat.com> <36a2eba5-a03d-131e-0042-46f0d4f0299a@redhat.com> <80d2ccd8-8e1b-52a7-df76-087c72f21a12@redhat.com> <8caa3b3a-54a6-e168-6304-09ce8fb60a7f@redhat.com> Message-ID: <5b666684-ada4-8721-0671-a6a0424e115b@redhat.com> Hi Martin, Thanks for the review. Fixed both issues. $ ipa-run-tests test_integration/test_topology.py -k TestCASpecificRUVs WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] Permission denied: 'lextab.py' WARNING: yacc table file version is out of date WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission denied: 'yacctab.py' ==================================================================================== test session starts ===================================================================================== platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: sourceorder-0.5, multihost-1.0 collected 5 items test_integration/test_topology.py .. ================================================================================ 2 passed in 2444.84 seconds ================================================================================= On 10/17/2016 07:05 PM, Martin Basti wrote: > 1) > > you don't need to disable/enable dirsrv, just stop/start. Please remove > disable/enable parts > > > 2) > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > traceback >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > self = object at 0x7f6a502eec90> > > def test_delete_ruvs(self): > """ > http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/ > Test_Plan#Test_case:_clean-ruv_subcommand > """ > replica = self.replicas[0] > master = self.master > res1 = master.run_command(['ipa-replica-manage', 'list-ruv', '-p', > master.config.dirman_password]) >> assert(res1.stdout_text.count(replica.hostname) == 2 and > "Certificate Server Replica Update Vectors" in res1), ( > "CA-specific RUVs are not displayed") > E TypeError: argument of type 'SSHCommand' is not iterable > > test_integration/test_topology.py:215: TypeError >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > entering PDB >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >> > /usr/lib/python2.7/site-packages/ipatests/test_integration/test_topology.py(215)test_delete_ruvs() > > > -> assert(res1.stdout_text.count(replica.hostname) == 2 and > > > > On 14.10.2016 11:36, Oleg Fayans wrote: >> Right you are! I am sorry. >> >> On 10/13/2016 06:10 PM, Martin Basti wrote: >>> I think that you forgot to squash commits. Patch 47 doesn't apply >>> >>> >>> On 13.10.2016 14:01, Oleg Fayans wrote: >>>> Hi Martin, >>>> >>>> Thanks for the review. >>>> With disabling directory server it works as well, thanks for the hint. >>>> Also I moved the cleanup logic to the test itself for the sake of >>>> simplicity. Patch-0048 was not changed >>>> >>>> On 10/12/2016 02:35 PM, Martin Basti wrote: >>>>> 1) >>>>> >>>>> Can you just turn off dirsrv on replica instead of doing iptables >>>>> magic? >>>>> >>>>> >>>>> 2) NACK >>>>> >>>>> No more eval() ever in code, use 'getattr', 'get' or whatever in the >>>>> object that can be used. >>>>> >>>>> + evalhost = eval("args[0].%s" % host) >>>>> >>>>> Martin^2 >>>>> >>>>> On 12.10.2016 14:03, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> After extensive discussion with Ludwig, I finally got the clue on how >>>>>> does this feature work. When we uninstall the replica, the master >>>>>> cleans the replication agreements with this replica and automatically >>>>>> cleans all replica's RUVs. >>>>>> If we clean replica's RUVs on master without uninstalling the >>>>>> replica, >>>>>> the replica's RUVs get recreated on master (replication works!). So, >>>>>> the only way to test the clean-ruv subcommand is to turn off the >>>>>> replica, or block the traffic on it so it gets inaccessible to >>>>>> updates >>>>>> from master. >>>>>> The testcases were updated, see [1] and [2] >>>>>> >>>>>> The updated versions of the patches are attached >>>>>> >>>>>> [1] >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [2] >>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 08/05/2016 06:36 PM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 03.08.2016 14:45, Oleg Fayans wrote: >>>>>>>> Hi Martin, >>>>>>>> >>>>>>>> Thanks for the review! Both patches were updated. >>>>>>>> >>>>>>>> On 07/28/2016 04:11 PM, Martin Basti wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08.07.2016 15:41, Oleg Fayans wrote: >>>>>>>>>> Hi Martin, >>>>>>>>>> >>>>>>>>>> Thanks for the review! >>>>>>>>>> >>>>>>>>>> On 07/08/2016 02:18 PM, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 27.06.2016 13:53, Oleg Fayans wrote: >>>>>>>>>>>> Hi guys, >>>>>>>>>>>> >>>>>>>>>>>> Is there a chance the patches NN 0047.1 and 0048.1 get reviewed >>>>>>>>>>>> before >>>>>>>>>>>> 4.4 release? They cover a good part of the Managed Topology 4.4 >>>>>>>>>>>> feature. >>>>>>>>>>>> >>>>>>>>>>>> On 06/17/2016 11:18 AM, Oleg Fayans wrote: >>>>>>>>>>>>> One more test was added to the patch-0048 >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/17/2016 09:43 AM, Oleg Fayans wrote: >>>>>>>>>>>>>> Fixed a bug in the previous patch, automated 2 more testcases >>>>>>>>>>>>>> from >>>>>>>>>>>>>> http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/16/2016 04:46 PM, Oleg Fayans wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> IIUC, this will turn off the machine completely, how is cleanup >>>>>>>>>>> done >>>>>>>>>>> then. AFAIK our tests cannot turn on machine again and run >>>>>>>>>>> cleanup, so >>>>>>>>>>> you will not be able to run more tests on the same topology >>>>>>>>>>> without >>>>>>>>>>> manual cleanup and manual start. >>>>>>>>>>> >>>>>>>>>>> + replica = self.replicas[0] >>>>>>>>>>> + replica.run_command(['poweroff']) >>>>>>>>>>> >>>>>>>>>>> IMO would be better to just call 'ipactl stop' instead of >>>>>>>>>>> 'poweroff' >>>>>>>>>> >>>>>>>>>> Agreed! Fixed. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Martin^2 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> *Automated ipa-replica-manage del tests* >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> + replica.run_command(['ipactl', 'stop']) >>>>>>>>> + time.sleep(3) >>>>>>>>> >>>>>>>>> Why do you need sleep here? >>>>>>>> >>>>>>>> Removed, it was left from the old "poweroff" approach >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> + ruvid_re = re.compile(".*%s:389: (\d+).*" % >>>>>>>>> replica.hostname) >>>>>>>>> + replica_ruvs = ruvid_re.findall(result.stdout_text) >>>>>>>>> + master.run_command(['ipa-replica-manage', 'clean-ruv', >>>>>>>>> 'f', >>>>>>>>> + '-p', master.config.dirman_password, >>>>>>>>> + replica_ruvs[0]]) >>>>>>>>> >>>>>>>>> Because you are using re.findall(), without any match you will >>>>>>>>> receive >>>>>>>>> IndexError here replica_ruvs[0]. IMO it deserves assert before >>>>>>>> >>>>>>>> Implemented the assert which checks that the output contains enough >>>>>>>> replica RUVs >>>>>>>> >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> assert(replica.hostname in result1.stdout_text) >>>>>>>>> >>>>>>>>> I think that this is error prone. What if there is just error >>>>>>>>> 'could not >>>>>>>>> connect to replica ', or something similar. >>>>>>>>> instead of >>>>>>>>> listing/cleaning/whatever operation was executed. I think that it >>>>>>>>> should >>>>>>>>> be more specific regexp than just finding a replica name substring >>>>>>>>> (Yes >>>>>>>>> In IPA we dont always print error so stderr) >>>>>>>>> >>>>>>>>> I'm not sure, but probably there might be cases when non critical >>>>>>>>> error >>>>>>>>> happen and exist status is still 0 >>>>>>>> >>>>>>>> Agree. Implemented a regex-based search >>>>>>>> >>>>>>>>> >>>>>>>>> 4) >>>>>>>>> >>>>>>>>> + replica.run_command(['poweroff']) >>>>>>>>> + time.sleep(3) >>>>>>>>> >>>>>>>>> There should not be poweroff, probably sleep could be removed too. >>>>>>>> >>>>>>>> Gone >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * Automated clean-ruv subcommand test* >>>>>>>>> >>>>>>>>> 1) PEP8, 2 new lines expected >>>>>>>>> ./ipatests/test_integration/test_topology.py:163:1: E302 >>>>>>>>> expected 2 >>>>>>>>> blank lines, found 0 >>>>>>>>> ./ipatests/test_integration/test_topology.py:182:80: E501 line too >>>>>>>>> long >>>>>>>>> (85 > 79 characters) >>>>>>>> >>>>>>>> Fixed >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2) >>>>>>>>> I dont like doing assert just with count of occurences of >>>>>>>>> substring in >>>>>>>>> STDOUT, would be possible to improve this somehow? >>>>>>>> >>>>>>>> Maybe, but frankly, I don't see how. In this case we are making >>>>>>>> sure >>>>>>>> that both simple and CA-specific RUVs of a replica are >>>>>>>> displayed. The >>>>>>>> format of the output is strict: >>>>>>>> Replica Update Vectors: >>>>>>>> replica1_hostname:389: RUV_id >>>>>>>> replica2_hostname:389: RUV_id >>>>>>>> Certificate Server Replica Update Vectors: >>>>>>>> replica1_hostname:389: RUV_id >>>>>>>> replica2_hostname:389: RUV_id >>>>>>>> If we do not see 2 occurrences of the replica hostname than >>>>>>>> definitely >>>>>>>> something went wrong >>>>>>>> >>>>>>>>> >>>>>>>>> 3) >>>>>>>>> I'm not sure if clean-ruv is instant operations or there is some >>>>>>>>> magic >>>>>>>>> happening in background (we have abort-clean-ruv). Maybe some >>>>>>>>> sleep >>>>>>>>> should be there, but this needs investigation. >>>>>>>>> >>>>>>>>> + assert(replica.hostname in result2.stdout_text), ( >>>>>>>>> + "The wrong RUV was deleted") >>>>>>>>> + result3 = master.run_command(['ipa-replica-manage', >>>>>>>>> 'list-ruv', >>>>>>>>> + '-p', >>>>>>>>> master.config.dirman_password]) >>>>>>>>> + assert(result3.stdout_text.count(replica.hostname) == 1), ( >>>>>>>>> + "CA RUV of the replica is still displayed") >>>>>>>>> >>>>>>>> >>>>>>>> Based on my discussion with Stanislav Laznicka, I understood >>>>>>>> that by >>>>>>>> default clean-ruv does not return the shell until the operation is >>>>>>>> finished. You can force dropping into the shell by pressing >>>>>>>> CTRL+C, in >>>>>>>> which case the background job will still be running, but this is >>>>>>>> not >>>>>>>> the default behavior >>>>>>>> >>>>>>> Test failed: >>>>>>> result4 = master.run_command(['ipa-replica-manage', >>>>>>> 'list-ruv', >>>>>>> '-p', >>>>>>> master.config.dirman_password]) >>>>>>>> assert(replica.hostname not in result4.stdout_text), ( >>>>>>> "replica's RUV is still displayed") >>>>>>> E AssertionError: replica's RUV is still displayed >>>>>>> E assert 'replica3.ipa.test' not in 'Replica Update >>>>>>> V...ipa.test:389: 8\n' >>>>>>> E 'replica3.ipa.test' is contained here: >>>>>>> E Replica Update Vectors: >>>>>>> E \tmaster.ipa.test:389: 4 >>>>>>> E \treplica3.ipa.test:389: 3 >>>>>>> E \treplica2.ipa.test:389: 7 >>>>>>> E Certificate Server Replica Update Vectors: >>>>>>> E \tmaster.ipa.test:389: 6 >>>>>>> E \treplica2.ipa.test:389: 8 >>>>>>> >>>>>>> >>>>>>> [root at master ~]# ipa topologysegment-find >>>>>>> Suffix name: domain >>>>>>> ------------------ >>>>>>> 2 segments matched >>>>>>> ------------------ >>>>>>> Segment name: master.ipa.test-to-replica2.ipa.test >>>>>>> Left node: master.ipa.test >>>>>>> Right node: replica2.ipa.test >>>>>>> Connectivity: both >>>>>>> >>>>>>> Segment name: master.ipa.test-to-replica3.ipa.test >>>>>>> Left node: master.ipa.test >>>>>>> Right node: replica3.ipa.test >>>>>>> Connectivity: both >>>>>>> ---------------------------- >>>>>>> Number of entries returned 2 >>>>>>> ---------------------------- >>>>>>> [root at master ~]# ipa-replica-manage list-ruv >>>>>>> Directory Manager password: >>>>>>> >>>>>>> Replica Update Vectors: >>>>>>> master.ipa.test:389: 4 >>>>>>> replica2.ipa.test:389: 7 >>>>>>> replica3.ipa.test:389: 3 >>>>>>> Certificate Server Replica Update Vectors: >>>>>>> master.ipa.test:389: 6 >>>>>>> replica2.ipa.test:389: 8 >>>>>>> [root at master ~]# >>>>>>> >>>>>>> Then I tried manually to clean RUV 3, and it behaves somehow odd >>>>>>> >>>>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>>>> 'Secret123' '-f' >>>>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>>>> Background task created to clean replication data. This may take a >>>>>>> while. >>>>>>> This may be safely interrupted with Ctrl+C >>>>>>> Cleanup task created >>>>>>> [root at master ~]# less /var/log/dirsrv/slapd-IPA-TEST/errors >>>>>>> [root at master ~]# ipa-replica-manage list-ruv >>>>>>> Directory Manager password: >>>>>>> >>>>>>> Replica Update Vectors: >>>>>>> master.ipa.test:389: 4 >>>>>>> replica2.ipa.test:389: 7 >>>>>>> replica3.ipa.test:389: 3 >>>>>>> Certificate Server Replica Update Vectors: >>>>>>> master.ipa.test:389: 6 >>>>>>> replica2.ipa.test:389: 8 >>>>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>>>> 'Secret123' '-f' >>>>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>>>> CLEANALLRUV task for replica id 3 already exists. >>>>>>> This may be safely interrupted with Ctrl+C >>>>>>> Cleanup task created >>>>>>> >>>>>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>>>>> No CLEANALLRUV tasks running >>>>>>> >>>>>>> No abort CLEANALLRUV tasks running >>>>>>> [root at master ~]# 'ipa-replica-manage' 'clean-ruv' '3' '-p' >>>>>>> 'Secret123' '-f' >>>>>>> Clean the Replication Update Vector for replica3.ipa.test:389 >>>>>>> Background task created to clean replication data. This may take a >>>>>>> while. >>>>>>> This may be safely interrupted with Ctrl+C >>>>>>> Cleanup task created >>>>>>> [root at master ~]# ipa-replica-manage list-clean-ruv -p Secret123 >>>>>>> CLEANALLRUV tasks >>>>>>> RID 3: Successfully cleaned rid(3). >>>>>>> >>>>>>> No abort CLEANALLRUV tasks running >>>>>>> [root at master ~]# ipa-replica-manage list-ruv -p Secret123 >>>>>>> Replica Update Vectors: >>>>>>> master.ipa.test:389: 4 >>>>>>> replica2.ipa.test:389: 7 >>>>>>> Certificate Server Replica Update Vectors: >>>>>>> master.ipa.test:389: 6 >>>>>>> replica2.ipa.test:389: 8 >>>>>>> >>>>>>> >>>>>>> I'm not sure if this behavior is right, Ludwig may know. >>>>>> >>>>> >>>> >>> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0047.6-Automated-clean-ruv-subcommand-tests.patch Type: text/x-patch Size: 4418 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 19 15:13:28 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 17:13:28 +0200 Subject: [Freeipa-devel] [freeipa PR#159][+ack] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires Label: +ack From freeipa-github-notification at redhat.com Wed Oct 19 15:13:30 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 17:13:30 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires stlaz commented: """ @martbab Thanks, that worked. ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254843561 From freeipa-github-notification at redhat.com Wed Oct 19 15:14:43 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 19 Oct 2016 17:14:43 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ BTW I am really interested in how do you plan to implement client only build. IMHO it would be much simpler include reduced version of daemon/configure.ac (+others) into top level configure.ac rather then creating if/else branches in huge long unified configured.ac """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-254843953 From freeipa-github-notification at redhat.com Wed Oct 19 15:15:42 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 19 Oct 2016 17:15:42 +0200 Subject: [Freeipa-devel] [freeipa PR#171][-ack] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 Label: -ack From mbasti at redhat.com Wed Oct 19 15:25:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Oct 2016 17:25:13 +0200 Subject: [Freeipa-devel] Limiting pull request notification sizes In-Reply-To: References: Message-ID: <3e77ae9f-da95-f509-52d3-839223a3de73@redhat.com> On 19.10.2016 16:38, Petr Vobornik wrote: > Looking at: [Freeipa-devel] [freeipa PR#171][synchronized] Build system > cleanup phase 2 > > I see that the attached freeipa-pr-171.patch has 7.8 MB. With couple > forced pushed to the private branch it creates quite big traffic a takes > space. > > Is it possible to limit sizes of these attachments to let's say 50KB? > > I.e., I would be interested in the small patches but let's read the > large ones on GitHub. It is possible, you can: *) open issue against freeipa/freeipa-tools or *) sent PR against freeipa/freeipa-tools PS: github will not show you the big patches :D you have to use git show Martin^2 From freeipa-github-notification at redhat.com Wed Oct 19 15:34:04 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 17:34:04 +0200 Subject: [Freeipa-devel] [freeipa PR#159][-ack] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires Label: -ack From freeipa-github-notification at redhat.com Wed Oct 19 15:34:57 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 19 Oct 2016 17:34:57 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires stlaz commented: """ @martbab Thanks, that worked. However, first set of patches was not yet ACKed in https://github.com/freeipa/freeipa/pull/171. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-254843561 From mharmsen at redhat.com Wed Oct 19 21:07:12 2016 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 19 Oct 2016 15:07:12 -0600 Subject: [Freeipa-devel] Karma Requests for pki-core-10.3.5-7 and pki-console-10.3.5-2 In-Reply-To: <16446870-894a-178a-a664-58c009c62931@redhat.com> References: <16446870-894a-178a-a664-58c009c62931@redhat.com> Message-ID: On 10/11/2016 01:12 PM, Matthew Harmsen wrote: > *The following updated candidate builds of pki-core 10.3.5 and > pki-console 10.3.5 were generated:* > > * *Fedora 24* > o *pki-core-10.3.5-7.fc24 > * > o *pki-console-10.3.5-2.fc24 > > * > * *Fedora 25* > o *pki-core-10.3.5-7.fc25 > * > o *pki-console-10.3.5-2.fc25 > > * > * *Fedora 26* > o *pki-core-10.3.5-7.fc26 (still working on build issues > encountered on rawhide)* > * *pki-core-10.3.5-7.fc26 ** * > o *pki-console-10.3.5-2.fc26 > * > > *Additionally, the CentOS 7 COPR EPEL Builds of Dogtag 10.3.3 were > also updated:* > > * *https://copr.fedorainfracloud.org/coprs/g/pki/epel-7.3/repo/epel-7/group_pki-epel-7.3-epel-7.repo* > > > [group_pki-epel-7.3] > name=Copr repo for epel-7.3 owned by @pki > baseurl=https://copr-be.cloud.fedoraproject.org/results/@pki/epel-7.3/epel-7-$basearch/ > type=rpm-md > skip_if_unavailable=True > gpgcheck=1 > gpgkey=https://copr-be.cloud.fedoraproject.org/results/@pki/epel-7.3/pubkey.gpg > repo_gpgcheck=0 > enabled=1 > enabled_metadata=1 > > *These builds address the following PKI tickets:* > > * PKI TRAC Ticket #1527 - TPS Enrollment always goes to "ca1" (cfu) > > * PKI TRAC Ticket #1664 - [BUG] Add ability to disallow TPS to > enroll a single user on multiple tokens. (jmagne) > > * PKI TRAC Ticket #2463 - Troubleshooting improvements (edewata) > > o potentially more to come in future releases > * PKI TRAC Ticket #2466 - two-step externally-signed CA installation > fails due to missing AuthorityID (ftweedal) > > * PKI TRAC Ticket #2475 - Multiple host authority entries created > (ftweedal) > * PKI TRAC Ticket #2476 - Dogtag Miscellaneous Minor Changes > (edewata) > o potentially more to come in future releases > * PKI TRAC Ticket #2478 - pkispawn fails as it is not able to find > openssl as a dependency package (mharmsen) > > * PKI TRAC Ticket #2483 - Unable to read an encrypted email using > renewed tokens (jmagne) > * PKI TRAC Ticket #2496 - Cert/Key recovery is successful when the > cert serial number and key id on the ldap user mismatches (cfu) > > * PKI TRAC Ticket #2497 - KRA installation failed against > externally-signed CA with partial certificate chain (edewata) > > * PKI TRAC Ticket #2505 - Fix packaging duplicates of classes in > multiple jar files (edewata) > > > *Please provide Karma for the following builds:* > > * *Fedora 24* > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-76fae7b25f > pki-core-10.3.5-7.fc24 > * > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-a9e6c42783 > pki-console-10.3.5-2.fc24 > * > * *Fedora 25* > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-3496056579 > pki-core-10.3.5-7.fc25* > o *https://bodhi.fedoraproject.org/updates/FEDORA-2016-70b3b8b697 > pki-console-10.3.5-2.fc25 > > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhenglei at kylinos.cn Thu Oct 20 01:06:00 2016 From: zhenglei at kylinos.cn (=?utf-8?B?6YOR56OK?=) Date: Thu, 20 Oct 2016 09:06:00 +0800 Subject: [Freeipa-devel] [help] In-Reply-To: <28ae586a-caa0-1c9a-a24b-c05391f96992@redhat.com> References: <8c429db1-ecf8-4cfd-3214-22be37754321@redhat.com> <28ae586a-caa0-1c9a-a24b-c05391f96992@redhat.com> Message-ID: comments inline. ------------------ ?? ?????????? -------------------------- ?????? ?? Phone?18684703229 Email?zhenglei at kylinos.cn Company????????????? Address???????????????????? ------------------ Original ------------------ From: "Martin Basti"; Date: Wed, Oct 19, 2016 07:56 PM To: "??"; "freeipa-devel"; Subject: Re: [Freeipa-devel] [help] Comments inline On 19.10.2016 10:30, ?? wrote: ------------------ ?? ?????????? -------------------------- ?????? ?? Phone?18684703229 Email?zhenglei at kylinos.cn Company????????????? Address???????????????????? ------------------ Original ------------------ From: "Martin Basti"; Date: Wed, Oct 19, 2016 04:03 PM To: "??"; "freeipa-devel"; Subject: Re: [Freeipa-devel] [help] On 19.10.2016 03:35, ?? wrote: Hello, In the process of using freeipa, we found a lot of content without Chinese translation. In order to we can better use the platform, we made a Chinese translation. Sorry but I don't see any updates in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750 If you do a custom/manual translations this will not scale and you will do the same every release I have applied to join Chinese translation organization in zanata https://fedora.zanata.org/language/view/zh-CN?dswid=2727, but there is no reply. And I have tried to translate in zanata https://fedora.zanata.org/iteration/view/freeipa/master/languages/zh-CN?dswid=-4750, But there seems to be no permission to modify. Whether I need to put the translation file zh_CN.po to create pull request against freeipa/freeipa on github? No please don't, we always generate .po files from zanata before releases, so all changes are overwritten Ok, let me know how the adding you to zanata continue, if nobody will answer for longer time, I can put you just to freeIPA project as translator. Ok, Thx! If there is still no respond in zanata for a period of time, I will contact you again. I think the translation work for freeipa internationalization promotion also can have certain help. In addition, in use process, we found that when test the corresponding function of operation in the Web interface is not a straightforward logging which needs to query in the background, and it may not be intuitive and convenient. In order to we can intuitively record what we have done the operation in the Web interface, we do the log module plug-ins. webUI is just layer on top of our API calls. I know, What I mean is that no matter we are in API calls mode to manipulate freeipa or Web UI way, we all can intuitive see clearly under the log module. The log module function is to record any of our operation. I think that they can be many caveats (access control, replication, etc.) maybe would be good to see your code (you can send PR) how is you current implementation. Ok, I organize the content first, you'll create a pull request against freeipa/freeipa on github later. Martin ------------------ ?? ?????????? -------------------------- ?????? ?? Phone?18684703229 Email?zhenglei at kylinos.cn Company????????????? Address???????????????????? ------------------ Original ------------------ From: "Martin Basti"; Date: Tue, Oct 18, 2016 06:50 PM To: "??"; "freeipa-devel"; Subject: Re: [Freeipa-devel] [help] On 18.10.2016 03:28, ?? wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the Chinese translation to the web interface, also added own log module in web interface, referring to the following screenshots. However, for these changes I don't know how to interact with the community. Is there a administrator to review these changes? Who should I send mail to? Please help me. Thank you very much! Hello, at first you can write here what is your goal, what are your use cases and how do you plan to achieve that. Then, if we agree on solution, you can send code as pull request to our github repository https://github.com/freeipa/freeipa Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Thu Oct 20 05:03:03 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 20 Oct 2016 07:03:03 +0200 Subject: [Freeipa-devel] [freeipa PR#173][opened] Ensure correct IPA CA nickname in DS and HTTP NSSDBs Message-ID: URL: https://github.com/freeipa/freeipa/pull/173 Author: frasertweedale Title: #173: Ensure correct IPA CA nickname in DS and HTTP NSSDBs Action: opened PR body: """ During replica installation, if the IPA deployment has a custom subject_base, the routines that create the DS and HTTP NSSDBs erroneously compare the subject of CA certs to the *default* subject base. This causes the IPA CA cert to be added to the NSSDBs with a nickname derived from the subject name, instead of "{REALM} IPA CA". At a later stage of installation, the `upload_cacrt` plugin reads certs from the HTTP NSSDB in order to update the cn=certificates LDAP certstore. The NSSDB nickname of the cert is used as the CN for the entry. Because the IPA CA cert was not installed in the HTTP NSSDB with the "{REALM} IPA CA", this causes a spurious entry for the IPA CA to be added to the certstore. To avoid this scenario, use the deployment's actual subject base when deciding if a cert is the IPA CA cert. Fixes: https://fedorahosted.org/freeipa/ticket/6415 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/173/head:pr173 git checkout pr173 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-173.patch Type: text/x-diff Size: 2568 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 05:48:06 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 20 Oct 2016 07:48:06 +0200 Subject: [Freeipa-devel] [freeipa PR#162][closed] Certificate processing refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/162 Author: frasertweedale Title: #162: Certificate processing refactoring Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/162/head:pr162 git checkout pr162 From freeipa-github-notification at redhat.com Thu Oct 20 05:48:08 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 20 Oct 2016 07:48:08 +0200 Subject: [Freeipa-devel] [freeipa PR#162][comment] Certificate processing refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/162 Title: #162: Certificate processing refactoring frasertweedale commented: """ Closing PR (will retarget to @dkupka's refactoring-certificates staging branch. """ See the full comment at https://github.com/freeipa/freeipa/pull/162#issuecomment-255014837 From freeipa-github-notification at redhat.com Thu Oct 20 06:52:36 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 08:52:36 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn Decision if we need client_only build is still open. We may drop it so reimplementing it would be busy work. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255023841 From freeipa-github-notification at redhat.com Thu Oct 20 06:57:17 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 08:57:17 +0200 Subject: [Freeipa-devel] [freeipa PR#169][+ack] Replace ipaplatform's symlinks with __path__ In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Title: #169: Replace ipaplatform's symlinks with __path__ Label: +ack From freeipa-github-notification at redhat.com Thu Oct 20 07:03:04 2016 From: freeipa-github-notification at redhat.com (shanyin) Date: Thu, 20 Oct 2016 09:03:04 +0200 Subject: [Freeipa-devel] [freeipa PR#174][opened] add log module Message-ID: URL: https://github.com/freeipa/freeipa/pull/174 Author: shanyin Title: #174: add log module Action: opened PR body: """ add log module on the ipa-4-3 branch, the function of log module is to record any of our operation. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/174/head:pr174 git checkout pr174 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-174.patch Type: text/x-diff Size: 19170 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 07:55:44 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Thu, 20 Oct 2016 09:55:44 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ My proposal would not require any reimplementation because it will reuse current solution. And I would like to know the reasons why upstream might consider to drop client_only feature. There are still distribution/platforms which does not have systemd which s required for server part. And decision to drop client-only feature would not increase portability of currently fedora based project. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255035073 From freeipa-github-notification at redhat.com Thu Oct 20 08:10:52 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 10:10:52 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn Please discuss this matter on freeipa-devel list to gethigher visibility. Please note that current client-only build is quite broken and requires heavy machinery in downstream spec file so it is hard to speak about any reusage. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255038213 From freeipa-github-notification at redhat.com Thu Oct 20 08:28:03 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 10:28:03 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ Version rebased on top of current master (without PR 171) is available from https://github.com/pspacek/freeipa/tree/pr159-rebase . """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-255041910 From freeipa-github-notification at redhat.com Thu Oct 20 08:36:07 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Thu, 20 Oct 2016 10:36:07 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ > Please note that current client-only build is quite broken and requires heavy machinery in downstream spec file so it is hard to speak about any reusage. That's the problem of ugly downstream spec file. This is a pure upstream discussion and how to make at least part of freeIPA more portable rather then closing doors for other platforms/distributions without systemd. There are still people on debian which does not use systemd and want to use sssd and ipa-client. The current patch-set would not create more portable client code. It would would just make it much harder and would require more downstream patches which is not very upstream friendly approach. @pspacek, it would be good if you could comment my proposal with including configure snippets from subdirectories. `m4_include` works like a magic and if conditions around them would make much nicer configure script. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255043715 From freeipa-github-notification at redhat.com Thu Oct 20 08:42:30 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 20 Oct 2016 10:42:30 +0200 Subject: [Freeipa-devel] [freeipa PR#169][comment] Replace ipaplatform's symlinks with __path__ In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Title: #169: Replace ipaplatform's symlinks with __path__ dkupka commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/8f98fa1bd5f1da207fab6f89b75e0cdc19d00797 """ See the full comment at https://github.com/freeipa/freeipa/pull/169#issuecomment-255045129 From freeipa-github-notification at redhat.com Thu Oct 20 08:42:33 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 20 Oct 2016 10:42:33 +0200 Subject: [Freeipa-devel] [freeipa PR#169][closed] Replace ipaplatform's symlinks with __path__ In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Author: tiran Title: #169: Replace ipaplatform's symlinks with __path__ Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/169/head:pr169 git checkout pr169 From freeipa-github-notification at redhat.com Thu Oct 20 08:42:34 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 20 Oct 2016 10:42:34 +0200 Subject: [Freeipa-devel] [freeipa PR#169][+pushed] Replace ipaplatform's symlinks with __path__ In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/169 Title: #169: Replace ipaplatform's symlinks with __path__ Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 20 08:47:08 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 10:47:08 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 34409 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 08:49:29 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 20 Oct 2016 10:49:29 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 43425 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 09:39:38 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 20 Oct 2016 11:39:38 +0200 Subject: [Freeipa-devel] [freeipa PR#174][comment] add log module In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/174 Title: #174: add log module mbasti-rh commented: """ Hello, what is use case for this? "I'm admin and I want to audit what commads were used" or what? Have you tried, http://www.freeipa.org/page/Centralized_Logging ? Does it match your use case? I folowing serious notes: - we merge new features only to master branch - there is no policy who can access that information, I don't think that everybody should be able to see IPA log - it works only for a particular replica, we have replicated topology, so commands should work for all servers - also parsing log everytime looks for me quite inefficient """ See the full comment at https://github.com/freeipa/freeipa/pull/174#issuecomment-255058451 From freeipa-github-notification at redhat.com Thu Oct 20 09:54:12 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 11:54:12 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 34784 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 09:59:35 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 11:59:35 +0200 Subject: [Freeipa-devel] [freeipa PR#175][opened] Remove ipapython/ipa.conf Message-ID: URL: https://github.com/freeipa/freeipa/pull/175 Author: tiran Title: #175: Remove ipapython/ipa.conf Action: opened PR body: """ The file ipapython/ipa.conf is no longer used and not installed. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/175/head:pr175 git checkout pr175 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-175.patch Type: text/x-diff Size: 898 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 10:05:27 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 12:05:27 +0200 Subject: [Freeipa-devel] [freeipa PR#175][comment] Remove ipapython/ipa.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/175 Title: #175: Remove ipapython/ipa.conf tiran commented: """ @pspacek prefers a separate commit in PR #132 """ See the full comment at https://github.com/freeipa/freeipa/pull/175#issuecomment-255064396 From freeipa-github-notification at redhat.com Thu Oct 20 10:05:29 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 12:05:29 +0200 Subject: [Freeipa-devel] [freeipa PR#175][closed] Remove ipapython/ipa.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/175 Author: tiran Title: #175: Remove ipapython/ipa.conf Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/175/head:pr175 git checkout pr175 From freeipa-github-notification at redhat.com Thu Oct 20 10:05:35 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 12:05:35 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Draft for a new setup.py (WIP) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Draft for a new setup.py (WIP) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 35143 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 10:08:34 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 12:08:34 +0200 Subject: [Freeipa-devel] [freeipa PR#132][edited] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Port all setup.py files to setuptools Action: edited Changed field: title Original value: """ Draft for a new setup.py (WIP) """ From freeipa-github-notification at redhat.com Thu Oct 20 10:09:28 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 12:09:28 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Port all setup.py files to setuptools tiran commented: """ The PR is no longer provisional and ready-to-merge. """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-255065278 From freeipa-github-notification at redhat.com Thu Oct 20 10:22:48 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 20 Oct 2016 12:22:48 +0200 Subject: [Freeipa-devel] [freeipa PR#145][synchronized] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Author: tomaskrizek Title: #145: Refactoring: LDAP Connection Management Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/145/head:pr145 git checkout pr145 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-145.patch Type: text/x-diff Size: 135865 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 10:25:58 2016 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 20 Oct 2016 12:25:58 +0200 Subject: [Freeipa-devel] [freeipa PR#145][comment] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Title: #145: Refactoring: LDAP Connection Management tomaskrizek commented: """ Please review the code. I fixed a problem that was identified with the previous set of integration tests, but I'm still waiting for results of this build. Nevertheless, no more changes should be introduced in this PR, only potential fixes of issues. """ See the full comment at https://github.com/freeipa/freeipa/pull/145#issuecomment-255068687 From freeipa-github-notification at redhat.com Thu Oct 20 10:51:14 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 12:51:14 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ Commit 6256e8014aa3d68dc46e6c878be813473bffd1ac breaks pylint because it is not compatible with ipaplatform implementation introduced in 8f98fa1bd5f1da207fab6f89b75e0cdc19d00797. I do not care which part will be changed but we need to fix this first. (Either change ipaplatform to not confuse pylint or improve pylint plugin.) """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-255073461 From freeipa-github-notification at redhat.com Thu Oct 20 10:51:38 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 12:51:38 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ Commit 6256e8014aa3d68dc46e6c878be813473bffd1ac breaks pylint because it is not compatible with ipaplatform implementation introduced in 8f98fa1bd5f1da207fab6f89b75e0cdc19d00797. I do not care which part will be changed but we need to fix this first. (Either change ipaplatform not to confuse pylint or improve pylint plugin.) """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-255073461 From freeipa-github-notification at redhat.com Thu Oct 20 11:56:59 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Thu, 20 Oct 2016 13:56:59 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Port all setup.py files to setuptools jcholast commented: """ LGTM, but shouldn't we also move `/setup.py` to `/ipaserver/setup.py`? """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-255085433 From freeipa-github-notification at redhat.com Thu Oct 20 12:37:58 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 14:37:58 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 tiran commented: """ I agree with @lslebodn . It should be possible to build only the necessary bits and pieces for an IPA client. It should be rather simple to implement a ```--without-server``` ```AC_ARG_WITH()``` in another PR. Just move server-only ```PKG_CHECK_MODULES``` and ```AC_CONFIG_FILES()``` blocks into a ```if test "x$with_server" = "xyes"; then ... fi```` block. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255093805 From freeipa-github-notification at redhat.com Thu Oct 20 12:54:19 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 14:54:19 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 tiran commented: """ I agree with @lslebodn . It should be possible to build only the necessary bits and pieces for an IPA client. It should be rather simple to implement a ```--without-server``` ```AC_ARG_WITH()``` in another PR. Just move server-only ```PKG_CHECK_MODULES``` and ```AC_CONFIG_FILES()``` blocks into a ```if test "x$with_server" = "xyes"; then ... fi```` block. **To be clear**: I'm fine with this PR. client-only installation can be added in a later PR. Since it it easy to implement we can re-add it later without much trouble. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255093805 From freeipa-github-notification at redhat.com Thu Oct 20 13:02:26 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 15:02:26 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 tiran commented: """ ACK make rpms is passing on my machine. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255099321 From freeipa-github-notification at redhat.com Thu Oct 20 13:05:11 2016 From: freeipa-github-notification at redhat.com (rcritten) Date: Thu, 20 Oct 2016 15:05:11 +0200 Subject: [Freeipa-devel] [freeipa PR#145][comment] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Title: #145: Refactoring: LDAP Connection Management rcritten commented: """ Removing the connection timeout makes me a bit edgy. It is quite unclear why that's there, perhaps python-ldap doesn't provide a timeout and things hung forever, I'm not sure. I'd double-check that there is a timeout if the remote server either isn't there (probably raises a connection error), or is there but doesn't respond. """ See the full comment at https://github.com/freeipa/freeipa/pull/145#issuecomment-255099945 From freeipa-github-notification at redhat.com Thu Oct 20 13:19:59 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 15:19:59 +0200 Subject: [Freeipa-devel] [freeipa PR#175][+rejected] Remove ipapython/ipa.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/175 Title: #175: Remove ipapython/ipa.conf Label: +rejected From freeipa-github-notification at redhat.com Thu Oct 20 13:20:08 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 15:20:08 +0200 Subject: [Freeipa-devel] [freeipa PR#175][comment] Remove ipapython/ipa.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/175 Title: #175: Remove ipapython/ipa.conf pspacek commented: """ Sorry for the confusing here. Marking as rejected so it does not pop out in reports. """ See the full comment at https://github.com/freeipa/freeipa/pull/175#issuecomment-255103443 From freeipa-github-notification at redhat.com Thu Oct 20 13:20:22 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 15:20:22 +0200 Subject: [Freeipa-devel] [freeipa PR#175][comment] Remove ipapython/ipa.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/175 Title: #175: Remove ipapython/ipa.conf pspacek commented: """ Sorry for the confusing here. Marking as rejected so it does not pop out in reports. """ See the full comment at https://github.com/freeipa/freeipa/pull/175#issuecomment-255103443 From freeipa-github-notification at redhat.com Thu Oct 20 13:40:04 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Thu, 20 Oct 2016 15:40:04 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ > 08:53 < pspacek> lslebodn: I would appreciate patch showing the nicer solution to me. I do not think it > is that easy as you claim, especially when we count in that client_only build depends heavily on spec file, which is not usable in Debian at all, which makes > client-only-purely-upstream-point completely moot. Currently it is possible to build just a client part with following steps. Ant it has nothing to do with downstream specfile ``` make version-update cd client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} --localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd .. make client-install ``` As you can see configure script is executed only in client sub-directory. Here I am not interested in python part of client code. My concerns are pure related to C-code. But after merging everything to the one big configure script it would not be possible without patching a master. And you also wanted to see some patches with nicer solution here is a POC: ``` AC_ARG_WITH([server], [AC_HELP_STRING([--with-server], [Whether to build with server support [yes]] ) ], [], with_server=yes ) if test x"$with_server" = xyes; then AC_SUBST(HAVE_SERVER) AC_DEFINE_UNQUOTED(HAVE_SERVER, 1, [Build with server support]) m4_include([./install/configure.ac.inc]] m4_include([./daemons/configure.ac.inc]] m4_include([./asn1/configure.acac.inc]] fi m4_include([./client/configure.ac]) AM_CONDITIONAL([BUILD_SERVER], [test x"$with_server" = xyes]) ``` Or If you you can merge configure part into main configure script rather then `m4_include([./client/configure.ac])` """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255108446 From freeipa-github-notification at redhat.com Thu Oct 20 13:40:30 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Thu, 20 Oct 2016 15:40:30 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ > 08:53 < pspacek> lslebodn: I would appreciate patch showing the nicer solution to me. I do not think it > is that easy as you claim, especially when we count in that client_only build depends heavily on spec file, which is not usable in Debian at all, which makes > client-only-purely-upstream-point completely moot. Currently it is possible to build just a client part with following steps. Ant it has nothing to do with downstream specfile ``` make version-update cd client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} --localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd .. make client-install ``` As you can see configure script is executed only in client sub-directory. Here I am not interested in python part of client code. My concerns are pure related to C-code. But after merging everything to the one big configure script it would not be possible without patching a master. And you also wanted to see some patches with nicer solution here is a POC: ``` AC_ARG_WITH([server], [AC_HELP_STRING([--with-server], [Whether to build with server support [yes]] ) ], [], with_server=yes ) if test x"$with_server" = xyes; then AC_SUBST(HAVE_SERVER) AC_DEFINE_UNQUOTED(HAVE_SERVER, 1, [Build with server support]) m4_include([./install/configure.ac.inc]] m4_include([./daemons/configure.ac.inc]] m4_include([./asn1/configure.acac.inc]] fi m4_include([./client/configure.ac]) AM_CONDITIONAL([BUILD_SERVER], [test x"$with_server" = xyes]) ``` Or If you you can merge configure part into main configure script rather then `m4_include([./client/configure.ac])` """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255108446 From freeipa-github-notification at redhat.com Thu Oct 20 13:42:59 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Thu, 20 Oct 2016 15:42:59 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ > 08:53 < pspacek> lslebodn: I would appreciate patch showing the nicer solution to me. I do not think it > is that easy as you claim, especially when we count in that client_only build depends heavily on spec file, which is not usable in Debian at all, which makes > client-only-purely-upstream-point completely moot. Currently it is possible to build just a client part with following steps. Ant it has nothing to do with downstream specfile ``` make version-update cd client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} --localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd .. make client-install ``` As you can see configure script is executed only in client sub-directory. Here I am not interested in python part of client code. My concerns are pure related to C-code. But after merging everything to the one big configure script it would not be possible without patching a master. And you also wanted to see some patches with nicer solution here is a POC: ``` AC_ARG_WITH([server], [AC_HELP_STRING([--with-server], [Whether to build with server support [yes]] ) ], [], with_server=yes ) if test x"$with_server" = xyes; then AC_SUBST(HAVE_SERVER) AC_DEFINE_UNQUOTED(HAVE_SERVER, 1, [Build with server support]) m4_include([./install/configure.ac.inc]] m4_include([./daemons/configure.ac.inc]] m4_include([./asn1/configure.acac.inc]] fi m4_include([./client/configure.ac]) AM_CONDITIONAL([BUILD_SERVER], [test x"$with_server" = xyes]) ``` Or If you you can merge configure part into main configure script rather then `m4_include([./client/configure.ac])` """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255108446 From freeipa-github-notification at redhat.com Thu Oct 20 14:09:13 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 16:09:13 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ This version replaces ipaplatform magic with symlinks generated by configure. It should work with jcholast's PR 159. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255116485 From freeipa-github-notification at redhat.com Thu Oct 20 14:23:03 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 16:23:03 +0200 Subject: [Freeipa-devel] [freeipa PR#132][synchronized] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Port all setup.py files to setuptools Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-132.patch Type: text/x-diff Size: 38836 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 14:24:18 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 20 Oct 2016 16:24:18 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Port all setup.py files to setuptools tiran commented: """ I have moved /setup.py into /ipaserver/, fixed some make distclean targets (they were still removing setup.py) and made /ipaclient/setup.u install the ipa script. make rpms is passing. """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-255120722 From freeipa-github-notification at redhat.com Thu Oct 20 15:37:51 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 17:37:51 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Port all setup.py files to setuptools pspacek commented: """ Jenkins does not complain. ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-255142707 From freeipa-github-notification at redhat.com Thu Oct 20 15:37:55 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 17:37:55 +0200 Subject: [Freeipa-devel] [freeipa PR#132][+ack] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Port all setup.py files to setuptools Label: +ack From freeipa-github-notification at redhat.com Thu Oct 20 16:44:25 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 20 Oct 2016 18:44:25 +0200 Subject: [Freeipa-devel] [freeipa PR#132][+pushed] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Port all setup.py files to setuptools Label: +pushed From freeipa-github-notification at redhat.com Thu Oct 20 16:44:27 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 20 Oct 2016 18:44:27 +0200 Subject: [Freeipa-devel] [freeipa PR#132][comment] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Title: #132: Port all setup.py files to setuptools pvoborni commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/4cd83fb51cc35a2ba7773b62a7aa8d295a1e1e4a https://fedorahosted.org/freeipa/changeset/e12a70a8b1aa5daac4b8ab7ac681b09f664a8357 """ See the full comment at https://github.com/freeipa/freeipa/pull/132#issuecomment-255161342 From freeipa-github-notification at redhat.com Thu Oct 20 16:44:29 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 20 Oct 2016 18:44:29 +0200 Subject: [Freeipa-devel] [freeipa PR#132][closed] Port all setup.py files to setuptools In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/132 Author: tiran Title: #132: Port all setup.py files to setuptools Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/132/head:pr132 git checkout pr132 From freeipa-github-notification at redhat.com Thu Oct 20 17:29:07 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 19:29:07 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ @lslebodn I'm really trying to explain this but I'm still not able to get the point across. > My concerns are related purely to C-code. Please understand that IPA client consists of components in C as well from components in Python, and also non-programatic components like translation machinery etc. We certainly can create m4 include maze and force maintainer to always use `grep` before he finds particular part in the build system. Unfortunatlly, even the m4 maze will not solve the problem that client-only build of C binaries simply do not constitute working IPA client. Integration with other Python components is necessary to get the client to work. The end goal is to fold all of hand-made Makefile and SPEC file scripts to the build system, so in the end, it should help with porting to other arches - there will be just one place where changes need to be done, instead of three. I hope that it clears up why it is not useful to insist on keeping current pieces as they were before. The design document was sent to freeipa-devel mailing list in this thread: https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html Please discuss conceptual questions on the mailing list so we can get attention of other FreeIPA developers and avoid need to point people one by one to this PR. Thank you for understanding. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255172783 From freeipa-github-notification at redhat.com Thu Oct 20 17:51:57 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 19:51:57 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ This pull request was (again) rebased on top of PR#171. PR#171 changes ipaplatform handling to symlinks so the issue caused by `__path__` trick should go away. I.e. the rebased version is functional only with PR#171. """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-255178754 From freeipa-github-notification at redhat.com Thu Oct 20 17:52:19 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 19:52:19 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ This pull request was (again) rebased on top of PR#171. PR#171 changes ipaplatform handling to symlinks so the issue caused by `__path__` trick should go away. I.e. the rebased version is functional only with PR#171. The code is again available from https://github.com/pspacek/freeipa/tree/pr159-rebase """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-255178754 From freeipa-github-notification at redhat.com Thu Oct 20 17:56:42 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 19:56:42 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ This PR including additional patches on top have passed build + all XMLRPC tests in Jenkins: job/build_refactoring-build-f24build_refactoring/18/ Additional commits can be found on https://github.com/pspacek/freeipa/commits/pr159-rebase The test included everything up to e33e00bdc17dc164a1c143d8cba85f5df6de9d7e """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255180087 From freeipa-github-notification at redhat.com Thu Oct 20 17:57:07 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 19:57:07 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires pspacek commented: """ The rebased PR have passed build + all XMLRPC tests in Jenkins: job/build_refactoring-build-f24build_refactoring/18/ The test included everything up to e33e00bdc17dc164a1c143d8cba85f5df6de9d7e """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-255180193 From blipton at redhat.com Thu Oct 20 19:52:27 2016 From: blipton at redhat.com (Ben Lipton) Date: Thu, 20 Oct 2016 15:52:27 -0400 Subject: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation In-Reply-To: References: <8198a4a5-14fa-485f-fa89-325468b65c96@redhat.com> <23f5ad4f-c624-87db-0807-770979880bfb@redhat.com> <20160725111123.qthtarfgcsfbdnzk@redhat.com> <4eb3fe2f-ac80-4cf9-0f17-1c420fd52034@redhat.com> <57f0be1e-2915-fa33-d579-f173f1f5d019@redhat.com> <4f2f65ed-e525-1f04-f19b-c8a00b23001f@redhat.com> <57BF50E1.8030209@redhat.com> <82017bee-a989-cbe5-d5ed-f481441269e6@redhat.com> Message-ID: <8d6899e2-4357-8bf2-4e3e-dfd2c2466b01@redhat.com> On 10/17/2016 02:16 AM, Jan Cholasta wrote: > On 13.10.2016 17:23, Ben Lipton wrote: >> Thank you, this was a really helpful clarification of your point. >> Comments below. Once again, I'm sorry I missed the email for so long. >> >> Ben >> >> On 09/05/2016 06:52 AM, Jan Cholasta wrote: >>> On 27.8.2016 22:40, Ben Lipton wrote: >>>> On 08/25/2016 04:11 PM, Rob Crittenden wrote: >>>>> Ben Lipton wrote: >>>>>> On 08/23/2016 03:54 AM, Jan Cholasta wrote: >>>>>>> On 8.8.2016 22:23, Ben Lipton wrote: >>>>>>>> On 07/25/2016 07:45 AM, Jan Cholasta wrote: >>>>>>>>> On 25.7.2016 13:11, Alexander Bokovoy wrote: >>>>>>>>>> On Mon, 25 Jul 2016, Jan Cholasta wrote: >>>>>>>>>>> On 20.7.2016 16:05, Ben Lipton wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Thanks very much for the feedback! Some responses below; I >>>>>>>>>>>> hope >>>>>>>>>>>> you'll >>>>>>>>>>>> let me know what you think of my reasoning. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 07/20/2016 04:20 AM, Jan Cholasta wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 17.6.2016 00:06, Ben Lipton wrote: >>>>>>>>>>>>>> On 06/14/2016 08:27 AM, Ben Lipton wrote: >>>>>>>>>>>>>>> Hello all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have written up a design proposal for making certificate >>>>>>>>>>>>>>> requests >>>>>>>>>>>>>>> easier to generate when using alternate certificate >>>>>>>>>>>>>>> profiles: >>>>>>>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The use case for this is described in >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4899. I will be >>>>>>>>>>>>>>> working on >>>>>>>>>>>>>>> implementing this design over the next couple of months. >>>>>>>>>>>>>>> If you >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>> the time and interest, please take a look and share any >>>>>>>>>>>>>>> comments or >>>>>>>>>>>>>>> concerns that you have. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ben >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Just a quick update to say that I've created a new document >>>>>>>>>>>>>> that >>>>>>>>>>>>>> covers >>>>>>>>>>>>>> the proposed schema additions in a more descriptive way >>>>>>>>>>>>>> (with >>>>>>>>>>>>>> diagrams!) >>>>>>>>>>>>>> I'm very new to developing with LDAP, so some more >>>>>>>>>>>>>> experienced >>>>>>>>>>>>>> eyes on >>>>>>>>>>>>>> the proposal would be very helpful, even if you don't have >>>>>>>>>>>>>> time to >>>>>>>>>>>>>> absorb the full design. Please take a look at >>>>>>>>>>>>>> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> if you have a chance. >>>>>>>>>>>>> >>>>>>>>>>>>> I finally had a chance to take a look at this, here are some >>>>>>>>>>>>> comments: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) I don't like how transformation rules are tied to a >>>>>>>>>>>>> particular >>>>>>>>>>>>> helper and have to be duplicated for each of them. They >>>>>>>>>>>>> should be >>>>>>>>>>>>> generic and work with any helper, as helpers are just an >>>>>>>>>>>>> implementation detail and their resulting data is the same. >>>>>>>>>>>>> >>>>>>>>>>>>> In fact, I think I would prefer if the CSR was generated >>>>>>>>>>>>> using >>>>>>>>>>>>> python-cryptography's CertificateSigningRequestBuilder [1] >>>>>>>>>>>>> rather >>>>>>>>>>>>> than >>>>>>>>>>>>> openssl or certutil or any other command line tool. >>>>>>>>>>>>> >>>>>>>>>>>> There are lots of tools that users might want to use to manage >>>>>>>>>>>> their >>>>>>>>>>>> private keys, so I don't know if we can assume that whatever >>>>>>>>>>>> library we >>>>>>>>>>>> prefer will actually be able to access the private key to >>>>>>>>>>>> sign a >>>>>>>>>>>> CSR, >>>>>>>>>>>> which is why I thought it would be useful to support more than >>>>>>>>>>>> one. >>>>>>>>>>> >>>>>>>>>>> python-cryptography has the notion of backends, which allow >>>>>>>>>>> it to >>>>>>>>>>> support multiple crypto implementations. Upstream it currently >>>>>>>>>>> supports only OpenSSL [2], but some work has been done on >>>>>>>>>>> PKCS#11 >>>>>>>>>>> backend [3], which provides support for HSMs and soft-tokens >>>>>>>>>>> (like >>>>>>>>>>> NSS >>>>>>>>>>> databases). >>>>>>>>>>> >>>>>>>>>>> Alternatively, for NSS databases (and other "simple" cases), >>>>>>>>>>> you >>>>>>>>>>> can >>>>>>>>>>> generate the private key with python-cryptography using the >>>>>>>>>>> default >>>>>>>>>>> backend, export it to a file and import the file to the target >>>>>>>>>>> database, so you don't actually need the PKCS#11 backend for >>>>>>>>>>> them. >>>>>>>>>>> >>>>>>>>>>> So, the only thing that's currently lacking is HSM support, but >>>>>>>>>>> given >>>>>>>>>>> that we don't support HSMs in IPA nor in certmonger, I don't >>>>>>>>>>> think >>>>>>>>>>> it's an issue for now. >>>>>>>>>>> >>>>>>>>>>>> The >>>>>>>>>>>> purpose of the mapping rule is to tie together the >>>>>>>>>>>> transformation >>>>>>>>>>>> rules >>>>>>>>>>>> that produce the same data into an object that's >>>>>>>>>>>> implementation-agnostic, so that profiles referencing those >>>>>>>>>>>> rules >>>>>>>>>>>> are >>>>>>>>>>>> automatically compatible with all the helper options. >>>>>>>>>>> >>>>>>>>>>> They are implementation-agnostic, as long as you consider >>>>>>>>>>> `openssl` >>>>>>>>>>> and `certutil` the only implementations :-) But I don't think >>>>>>>>>>> this >>>>>>>>>>> solution scales well to other possible implementations. >>>>>>>>>>> >>>>>>>>>>> Anyway, my main grudge is that the transformation rules >>>>>>>>>>> shouldn't >>>>>>>>>>> really be stored on and processed by the server. The server >>>>>>>>>>> should >>>>>>>>>>> know the *what* (mapping rules), but not the *how* >>>>>>>>>>> (transformation >>>>>>>>>>> rules). The *how* is an implementation detail and does not >>>>>>>>>>> change in >>>>>>>>>>> time, so there's no benefit in handling it on the server. It >>>>>>>>>>> should be >>>>>>>>>>> handled exclusively on the client, which I believe would also >>>>>>>>>>> make >>>>>>>>>>> the >>>>>>>>>>> whole thing more robust (it would not be possible for a bug on >>>>>>>>>>> the >>>>>>>>>>> server to break all the clients). >>>>>>>>>> This is a good point. However, for the scope of Ben's project >>>>>>>>>> can we >>>>>>>>>> limit it by openssl and certutil support? Otherwise Ben >>>>>>>>>> wouldn't be >>>>>>>>>> able >>>>>>>>>> to complete the project in time. >>>>>>>>> >>>>>>>>> I'm fine with that, but I don't think it's up to me :-) >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> This is turning out to be a common (and, I think, reasonable) >>>>>>>>>>>> reaction >>>>>>>>>>>> to the proposal. It is rather complex, and I worry that it >>>>>>>>>>>> will be >>>>>>>>>>>> difficult to configure. On the other hand, there is some >>>>>>>>>>>> hidden >>>>>>>>>>>> complexity to enabling a simpler config format, as well. >>>>>>>>>>>> One of >>>>>>>>>>>> the >>>>>>>>>>>> goals of the project as it was presented to me was to allow >>>>>>>>>>>> the >>>>>>>>>>>> creation >>>>>>>>>>>> of profiles that add certificate extensions *that FreeIPA >>>>>>>>>>>> doesn't >>>>>>>>>>>> yet >>>>>>>>>>>> know about*. With the current proposal, one only has to add a >>>>>>>>>>>> rule >>>>>>>>>>>> generating text that the helper will understand. >>>>>>>>>>> >>>>>>>>>>> ... which will be possible only as long as the helper >>>>>>>>>>> understands the >>>>>>>>>>> extension. Which it might not, thus the current proposal works >>>>>>>>>>> only >>>>>>>>>>> for *some* extensions that FreeIPA doesn't yet support. >>>>>>>>>> We can go ad infinitum here but with any helper implementation, >>>>>>>>>> be it >>>>>>>>>> python-cryptography or anything else, you will need to have a >>>>>>>>>> support >>>>>>>>>> there as well. >>>>>>>>> >>>>>>>>> My point was that the current proposal is not any better than my >>>>>>>>> proposal in this regard, as neither of them allows one to use an >>>>>>>>> arbitrary extension. >>>>>>>>> >>>>>>>>>> The idea with unknown extensions was to allow mapping >>>>>>>>>> their acceptance to a specific relationship between IPA objects >>>>>>>>>> (optionally) and an input from the CSR. A simplest example would >>>>>>>>>> be an >>>>>>>>>> identity rule that would copy an ASN.1 encoded content from the >>>>>>>>>> CSR to >>>>>>>>>> the certificate. >>>>>>>>>> >>>>>>>>>> That's on the mapping side, not on the CSR generation side, >>>>>>>>>> but it >>>>>>>>>> would >>>>>>>>>> go similarly for the CSR if you would be able to enter >>>>>>>>>> unknown but >>>>>>>>>> otherwise correct ASN.1 stream. There is no difference at which >>>>>>>>>> helper >>>>>>>>>> type we are talking about because all of them support inserting >>>>>>>>>> ASN.1 >>>>>>>>>> content. >>>>>>>>>> >>>>>>>>>>>> With your suggestion, >>>>>>>>>>>> if there's a mapping between "san_directoryname" and the >>>>>>>>>>>> corresponding >>>>>>>>>>>> API calls or configuration lines, we need some way for >>>>>>>>>>>> users to >>>>>>>>>>>> augment >>>>>>>>>>>> that mapping without changing the code. If there's no >>>>>>>>>>>> mapping, and >>>>>>>>>>>> it's >>>>>>>>>>>> just done with text processing, we need enough in the config >>>>>>>>>>>> format to >>>>>>>>>>>> be able to generate fairly complex structures: >>>>>>>>>>>> >>>>>>>>>>>> builder = >>>>>>>>>>>> builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM')) >>>>>>>>>>>> builder = >>>>>>>>>>>> builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'user at example.com'), >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), >>>>>>>>>>>> False) >>>>>>>>>>>> >>>>>>>>>>>> and we need to do it without it being equivalent to calling >>>>>>>>>>>> eval() on >>>>>>>>>>>> the config attributes. I'm not sure how to achieve this (is it >>>>>>>>>>>> safe to >>>>>>>>>>>> call getattr(x509, extensiontype)(value) where >>>>>>>>>>>> extensiontype and >>>>>>>>>>>> value >>>>>>>>>>>> are user-specified?) and it definitely would have to be tied >>>>>>>>>>>> to a >>>>>>>>>>>> particular library/tool. >>>>>>>>>>> >>>>>>>>>>> As I pointed out above, this needs to be figured out for the >>>>>>>>>>> generic >>>>>>>>>>> case for both the current proposal and my suggestion. >>>>>>>> I have a proof of concept[1] for using openssl-based rules to >>>>>>>> add a >>>>>>>> subject alt name extension without using openssl's knowledge of >>>>>>>> that >>>>>>>> extension. It's not extremely pretty, and it took some trial and >>>>>>>> error, >>>>>>>> but no code changes. So, I think this actually is a difference >>>>>>>> between >>>>>>>> the two proposals. >>>>>>> >>>>>>> With the obvious catch being that it works only with OpenSSL, which >>>>>>> might not work for everyone, e.g. when using HSMs or SmartCards, >>>>>>> due >>>>>>> to a limited PKCS#11 support in OpenSSL. >>>>>> >>>>>> Very true. Even certutil's equivalent feature (--extGeneric) doesn't >>>>>> seem like it would work very well in this context, as you are >>>>>> supposed >>>>>> to pass in an already-encoded extension, so text-based templating >>>>>> wouldn't be able to do much. >>>>> >>>>> Yeah, I struggled with this myself. I ended up writing a pyasn1 >>>>> script >>>>> to generate the extension I needed, wrote that to a file, and passed >>>>> it to certutil using: >>>>> >>>>> --extGeneric 2.5.29.17:not-critical:/path/to/msupn.der >>>>> >>>>>>> >>>>>>>> >>>>>>>> Next we have the easy case, extensions that we as FreeIPA >>>>>>>> developers >>>>>>>> know are important and build support for. For these, the two >>>>>>>> proposals >>>>>>>> work equivalently well, but yours is simpler to configure because >>>>>>>> the >>>>>>>> knowledge of how to make a san_rfc822name is built into the >>>>>>>> library >>>>>>>> instead of being stored on the server as a set of rules. >>>>>>>> >>>>>>>> Finally, we have the case of extensions that are known to the >>>>>>>> helper, >>>>>>>> but not to FreeIPA. In the existing proposal, new rules can be >>>>>>>> written >>>>>>>> to support these extensions under a particular helper. Further, >>>>>>>> those >>>>>>>> rules can be used by reference in many profiles, reducing >>>>>>>> duplication of >>>>>>>> effort/data/errors. >>>>>>>> >>>>>>>> As I understand it, the main objections in this thread are that >>>>>>>> transformation rules are implementation (i.e. helper) specific >>>>>>>> data >>>>>>>> stored in the IPA server, and that the system has several >>>>>>>> levels of >>>>>>>> schema when it could just embed rules in the profile. But without >>>>>>>> helper-specific rules, administrators could not take advantage of >>>>>>>> the >>>>>>>> additional extensions supported by the helper they are using. >>>>>>> >>>>>>> There is *no* advantage in forcing the user to choose between >>>>>>> helpers >>>>>>> which differ only in the set of limitations on the CSR they are >>>>>>> able >>>>>>> to produce. The user should specify a) where the private key is >>>>>>> located and b) what profile to use, and that's it, it should just >>>>>>> work. >>>>>> Ok, this is a good point about usability. The user creating the CSR >>>>>> shouldn't have to care about helpers, and I agree that the >>>>>> current way >>>>>> they are exposed is clunky. I do think that an administrator >>>>>> creating >>>>>> custom rules might want to take advantage of a helper, so they >>>>>> wouldn't >>>>>> need to understand the ASN.1 representation of their chosen >>>>>> certificate >>>>>> extension. Of course, the desired extension might not be >>>>>> supported by >>>>>> the helper either. Since I don't know what specific extensions >>>>>> people >>>>>> will want to use this for, I don't know how to balance the better >>>>>> administrator experience of adding extensions via a helper with the >>>>>> limited extension support. >>>>>> >>>>>> The original reason we arrived at the concept of "helpers" was to >>>>>> support different ways of getting at private keys, but perhaps this >>>>>> should not be the concern of the CSR data generator. In your >>>>>> opinion, >>>>>> would it be sufficient to support just one key format (PKCS#12? >>>>>> PEM?) >>>>>> and let the user deal with putting those keys into whatever >>>>>> formats/databases they need? If that's ok, maybe we can stop having >>>>>> *multiple* helpers, but if we want to replace helpers entirely I'm >>>>>> still >>>>>> not certain what to replace them with. >>>>> >>>>> I'd just add an option to specify the output format, e.g PEM, NSS, >>>>> Java keystore, PKCS#12, whatever. You can probably get away with the >>>>> first two for starters. Different output format is going to mean >>>>> different options but that is probably not a big deal. >>>> >>>> My point was that if we want to get rid of all the helpers but one, or >>>> replace helpers with something else entirely like somehow templating >>>> ASN1 structures directly, it will get harder to support all those >>>> formats (or even both of the first two). For example, if we drop >>>> certutil as a helper, how will we sign CSRs with keys stored in NSS >>>> databases? >>> >>> 1. get the public part of the key from the NSS database >>> 2. construct a CertificationRequestInfo [1] from the template and the >>> public key >>> 3. sign the CertificationRequestInfo with NSS using the private key to >>> get a CSR >>> >>> This is purely client side, will work with any crypto library (just >>> substitute NSS for something else) and, if done right, using very >>> little code. >> >> Ok, I like this. If an encoded CertificationRequestInfo is something we >> can expect to be compatible with any reasonable library (it sounds like >> it should be) then the library can be used client-side to do the >> key-storage-specific parts. I'm going to try writing this data -> >> encoded CertificationRequestInfo -> CSR flow to make sure it works as >> well as it sounds. If it does, it will also be useful for the code I'm >> working on right now to connect certmonger with the current version of >> the CSR autogeneration tool. > > Note that this will most probably require calling C functions. You > might want to look into python-cffi. > >>> >>>>> >>>>> Remember that the private key will be at rest for some period of time >>>>> while the CSR is being approved. The key needs to be protected at >>>>> that >>>>> time. >>>>> >>>>> rob >>>>> >>>>>>> >>>>>>>> And >>>>>>>> without the separation of profiles from mapping rules in the >>>>>>>> schema, >>>>>>>> rules would need to be copy+pasted among profiles, and grouping >>>>>>>> rules >>>>>>>> with the same effect under different helpers would be much >>>>>>>> uglier. We >>>>>>>> can and should discuss whether these are the right tradeoffs, but >>>>>>>> this >>>>>>>> is where those decisions came from. >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> OTOH, I think we could use GSER encoding of the extension >>>>>>>>>>> value: >>>>>>>>>>> >>>>>>>>>>> { rfc822Name:"user at example.com", >>>>>>>>>>> directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" } >>>>>>>>>> GSER is not really used widely and does not have standardized >>>>>>>>>> encoding >>>>>>>>>> rules beyond its own definition. If you want to allow >>>>>>>>>> transformation >>>>>>>>>> rules in GSER that mention existing content in IPA objects, you >>>>>>>>>> would >>>>>>>>>> need to deal with templating anyway. At this point it becomes >>>>>>>>>> irrelevant >>>>>>>>>> what you are templating, though. >>>>>>>>> >>>>>>>>> True, but the goal here is not to avoid templating, but rather to >>>>>>>>> avoid implementation-specific bits on the server, and GSER is the >>>>>>>>> only >>>>>>>>> thing that is textual, implementation-neutral and, as a bonus, >>>>>>>>> standardized. >>>>>>>>> >>>>>>>> As I said elsewhere, we could use GSER as a textual output format >>>>>>>> instead of openssl or certutil, but it still needs its own >>>>>>>> "helper" to >>>>>>>> build the CSR, and unlike the other options, it seems like we >>>>>>>> might >>>>>>>> need >>>>>>>> to implement that helper. I'm not sure it's fair to call it >>>>>>>> implementation-neutral if no implementation exists yet :) >>>>>>> >>>>>>> Right. Like I said, using GSER was just a quick idea off the top >>>>>>> of my >>>>>>> head. I would actually rather use some sort of data structure >>>>>>> templating rather than textual templating on top of any kind of >>>>>>> textual representation of said data structures. I don't know if >>>>>>> there >>>>>>> is such a thing, though. >>>>>> >>>>>> This sounds interesting, can you give an example of what this might >>>>>> look >>>>>> like? >>> >>> It would be something like XSLT, but for ASN.1 rather than XML. >>> >>>>>> >>>>>> I learned that there's also an XML encoding for ASN.1, XER, but >>>>>> that's >>>>>> still a textual representation and we'd have to insert the data >>>>>> textually. >>> >>> Well, yes and no. While it's true that it's still a textual >>> representation, what really makes a difference is that for XML, there >>> is a templating mechanism which understands the structure of the data >>> (XLST, as mentioned above). >>> >>> Unforutantely, XER has the same shortcoming as GSER: to be able to >>> convert it to DER, you need to know the ASN.1 definition of the data >>> structure. If we used XER+XSLT, we would also have to provide means of >>> adding custom ASN.1 definitions and run them through ASN.1 compiler to >>> convert between XER and DER. >> >> This is a little disappointing, but it makes sense. I don't think I >> realized that we'll need to compile the ASN.1 data definitions for any >> extensions we want to use in a cert. That limitation didn't come up when >> we were only talking about extensions that were supported by the helper >> utility. But providing the ASN.1 spec for unusual extensions an admin >> wants to use in their certs is probably a reasonable expectation. > > Yes, that's what I think as well. It could be a simple IPA object with > name, description, extension OID and the ASN.1 definition. > >>> >>>>>> It doesn't seem to be supported by any python libraries, >>>>>> either, but it does look like it's supported by the asn1 compiler >>>>>> in the >>>>>> IPA source distribution.I could imagine an implementation that >>>>>> builds >>>>>> an XML representation of the CSR via python templating, then makes a >>>>>> signed CSR out of it in C. I'm a little concerned about it >>>>>> because it >>>>>> would have to implement the whole CSR structure from scratch, but is >>>>>> this a prototype that you'd be interested in seeing? >>> >>> I can imagine something like this might work: >>> >>> 1. (client) generate a key pair >>> 2. (client) get SubjectPublicKeyInfo [2] for the public key >>> 3. (client) encode the SubjectPublicKeyInfo as XER using asn1c and >>> python-cffi in API mode [3] >>> 4. (client) call server to construct CertificationRequestInfo for >>> specified subject from a specified template and the >>> SubjectPublicKeyInfo >>> 5. (server) get the subject's LDAP entry >>> 6. (server) create a XML document which contains the subject's LDAP >>> attributes and the SubjectPublicKeyInfo >>> 7. (server) use XSLT to transform the XML document to >>> CertificationRequestInfo using the specified template >>> 8. (server) return the CertificationRequestInfo to the client >>> 9. (client) convert the CertificationRequestInfo from XER to DER using >>> asn1c and python-cffi in API mode >>> 10. (client) sign the CertificationRequestInfo using the private key >>> to get a CSR >>> >>> It would be better if the XER-DER conversion was done on the server, >>> but I don't think that compiling and running code on the fly on the >>> server is a particularly good idea. Apparently there is a ASN.1 >>> compiler available for PyASN1 [4], maybe that could be used instead, >>> but we would have to write a XER codec for PyASN1 ourselves (which >>> shouldn't be too hard IMO). >> >> Yeah, running programs compiled from arbitrary ASN.1 seems like a risk. >> Maybe a little better because the ASN.1 is provided by an administrator, >> but we'd still be depending a lot on the security of the generated code. >> On the other hand, if we compile on the client, the CSR generation >> feature is limited to platforms where asn1c can be installed. I wish I >> could think of a way to do the compilation once when the profile is >> created, but run it on the client. That seems like asking for >> compatibility problems, though... > > It seems you missed the most important thing in the above paragraph > :-) - that is asn1ate, the PyASN1-based compiler. The nice thing about > it is that it compiles the ASN.1 definition into a PyASN1 type object, > which means you can compile the definition and use it to (un)parse > data in the same Python program. If we used it, we could JIT-compile > the ASN.1 definitions on the server, without the security risk of > executing native code and without the compatibility issues of > compilation on the client. What do you see as the risks of compiling native code with asn1c and executing it that are not present when generating python code with asn1ate and loading it? I would think that, native or not, we're depending on the ASN.1 compiler to generate secure code from any ASN.1 definition the admin might give it. Even a parser like libtasn1 that interprets the structure on the fly rather than generating executable code could do something dangerous when given poorly-constructed input. I don't mean to create a false equivalence, but are the interpreted options really safer than the native code? > > I did a little research since my last email, andt doesn't seem to have > there is also another library which allows you to compile and use > ASN.1 definitions on the fly - libtasn1 [5]. Compared to asn1ate, it > seems to be pretty stable (asn1ate is currently in alpha) and is > written in C, so it makes it possible to use the administrator-defined > extensions outside of IPA (specifically, it could be useful for > certificate matching and mapping [6] in SSSD). Good find. That seems quite useful for being able to interact with ASN.1 defined on the fly. I wonder how hard it would be to connect it to pyasn1 to get more flexible ASN.1 decoding within python. Still doesn't help with XER encoding/decoding, but I suppose that's a SMOP :) > >> >>> >>>>>> >>>> On further investigation, it turns out the version of >>>> python-cryptography in F24 includes a feature allowing arbitrary >>>> extensions to be added by adding an UnrecognizedExtension to the >>>> CertificateSigningRequestBuilder. This makes me feel somewhat better >>>> both about python-cryptography as a tool for this task and about the >>>> solution I just proposed. But I still don't have a clear idea that >>>> answers 1) how to make templates that we can turn into encoded >>>> extensions, and 2) how to deal with all the desired key formats. >>> >>> I hope the above clarifies these a little bit. >>> >>> [1] >>> [2] >>> [3] >>> [4] > > [5] > [6] > > From freeipa-github-notification at redhat.com Thu Oct 20 19:57:45 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Thu, 20 Oct 2016 21:57:45 +0200 Subject: [Freeipa-devel] [freeipa PR#10][synchronized] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Author: LiptonB Title: #10: Client-side CSR autogeneration Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/10/head:pr10 git checkout pr10 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-10.patch Type: text/x-diff Size: 205130 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 20:21:37 2016 From: freeipa-github-notification at redhat.com (LiptonB) Date: Thu, 20 Oct 2016 22:21:37 +0200 Subject: [Freeipa-devel] [freeipa PR#10][comment] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Title: #10: Client-side CSR autogeneration LiptonB commented: """ Updated to fix conflicts with master again. I'm not sure what's up with Travis, it seems to be checking out PR #109 instead of this one for the pep8 check: ``` $ cd freeipa/freeipa $ git fetch origin +refs/pull/109/merge: remote: Counting objects: 78053, done. remote: Compressing objects: 100% (14671/14671), done. remote: Total 78053 (delta 64375), reused 76890 (delta 63219), pack-reused 0 Receiving objects: 100% (78053/78053), 28.18 MiB | 18.03 MiB/s, done. Resolving deltas: 100% (64375/64375), completed with 841 local objects. From https://github.com/freeipa/freeipa * branch refs/pull/109/merge -> FETCH_HEAD $ git checkout -qf FETCH_HEAD ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/10#issuecomment-255217025 From freeipa-github-notification at redhat.com Fri Oct 21 03:52:07 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 21 Oct 2016 05:52:07 +0200 Subject: [Freeipa-devel] [freeipa PR#176][opened] cert-show: show validity in default output Message-ID: URL: https://github.com/freeipa/freeipa/pull/176 Author: frasertweedale Title: #176: cert-show: show validity in default output Action: opened PR body: """ cert-show no longer shows validity dates without `--all', but this is important information that should be shown by default. Make it so. Fixes: https://fedorahosted.org/freeipa/ticket/6419 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/176/head:pr176 git checkout pr176 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-176.patch Type: text/x-diff Size: 1376 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 21 04:13:36 2016 From: freeipa-github-notification at redhat.com (shanyin) Date: Fri, 21 Oct 2016 06:13:36 +0200 Subject: [Freeipa-devel] [freeipa PR#174][comment] add log module In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/174 Title: #174: add log module shanyin commented: """ Yes. As you see, our use case is I'm admin and want to audit what commads were used. - Because I use freeipa 4.3.1 version, adaptation through on this version, I saw the master branch source code structure is different from the ipa-4-3 branch, I am not sure if there is a problem after adding log module, so created pull request on the ipa-4-3 branch. - We can set up the log file permissions. Currently only the admin can view the log information in web interface. - The log module adapted by freeipa 4.3.1 version, not sure if there is a problem in other versions. As for the replicated topology, I need to familiar with its function. - Parsing the log is to show more friendly in the web interface. BTW, there is still no respond about joining Chinese translation organization in zanata https://fedora.zanata.org/language/view/zh-CN?dswid=2727 """ See the full comment at https://github.com/freeipa/freeipa/pull/174#issuecomment-255289588 From freeipa-github-notification at redhat.com Fri Oct 21 07:32:36 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Fri, 21 Oct 2016 09:32:36 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (20/10/16 10:29), Petr ?pa?ek wrote: >@lslebodn I'm really trying to explain this but I'm still not able to get the point across. >> My concerns are related purely to C-code. > >Please understand that IPA client consists of components in C as well from components in Python, and also non-programatic components like translation machinery etc. > Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. So here I cannot see a conflict with my proposal. >We certainly can create m4 include maze I cannot see a reason why it would be a maze Detection of client build dependencies will be done in main configure.ac Detection of server dependencies would be done in `daemons/configure.ac` `./ipatests/man/configure.ac` and `./install/configure.ac` does not have any C-related dependencies and `./asn1/configure.ac` is required by client code. IMHO ans1c/ can be moved to client/asn1c/ (but that's offtopic) There would not be much includes as I showed in POC >and force maintainer to always use `grep` before he finds particular part in the build system. maintainers do not use grep for finding build dependencies. The most common use case is just to run configure script and wait for reported errors. pkg-config returns nice error messages. And then add new build dependency. However, C related code is not changed very often and even more C-related dependencies are added much less often. But if new depenendecy will be added to server part then it will be much simpler to review whether build dependency is added to the right section if server dependencies will be in separate file. >Unfortunatlly, even the m4 maze will not solve the problem that client-only >build of C binaries simply do not constitute working IPA client. >Integration with other Python components is necessary to get the client to work. > Totally agree. But python components is not related to checking of build time dependencies for C-code. It should be solved in different PR IMHO, this PR should not complicate client-only build just for C-binaries. >The end goal is to fold all of hand-made Makefile and SPEC file scripts to the build system, so in the end, it should help with porting to other arches - there will be just one place +where changes need to be done, instead of three. > Agree, but here I cannot see any conflict with my proposal. >I hope that it clears up why it is not useful to insist on keeping current pieces as they were before. The design document was sent to freeipa-devel mailing list in this thread: >https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html >Please discuss conceptual questions on the mailing list so we can get attention of other FreeIPA developers and avoid need to point people one by one to this PR. > I read the desing page and there is mentioned that autotools will be used for C-part as an implementation and configure script should have the option --enable-server which default yes. I could not find any contradiction between my proposal and desing page. LS """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255313933 From freeipa-github-notification at redhat.com Fri Oct 21 07:34:05 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Fri, 21 Oct 2016 09:34:05 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (20/10/16 10:29), Petr ?pa?ek wrote: >@lslebodn I'm really trying to explain this but I'm still not able to get the point across. >> My concerns are related purely to C-code. > >Please understand that IPA client consists of components in C as well from components in Python, and also non-programatic components like translation machinery etc. Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. So here I cannot see a conflict with my proposal. >We certainly can create m4 include maze I cannot see a reason why it would be a maze Detection of client build dependencies will be done in main configure.ac Detection of server dependencies would be done in `daemons/configure.ac` `./ipatests/man/configure.ac` and `./install/configure.ac` does not have any C-related dependencies and `./asn1/configure.ac` is required by client code. IMHO ans1c/ can be moved to client/asn1c/ (but that's offtopic) There would not be much includes as I showed in POC >and force maintainer to always use `grep` before he finds particular part in the build system. maintainers do not use grep for finding build dependencies. The most common use case is just to run configure script and wait for reported errors. pkg-config returns nice error messages. And then add new build dependency. However, C related code is not changed very often and even more C-related dependencies are added much less often. But if new depenendecy will be added to server part then it will be much simpler to review whether build dependency is added to the right section if server dependencies will be in separate file. >Unfortunatlly, even the m4 maze will not solve the problem that client-only >build of C binaries simply do not constitute working IPA client. >Integration with other Python components is necessary to get the client to work. Totally agree. But python components is not related to checking of build time dependencies for C-code. It should be solved in different PR IMHO, this PR should not complicate client-only build just for C-binaries. >The end goal is to fold all of hand-made Makefile and SPEC file scripts to the build system, so in the end, it should help with porting to other arches - there will be just one place +where changes need to be done, instead of three. Agree, but here I cannot see any conflict with my proposal. >I hope that it clears up why it is not useful to insist on keeping current pieces as they were before. The design document was sent to freeipa-devel mailing list in this thread: >https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html >Please discuss conceptual questions on the mailing list so we can get attention of other FreeIPA developers and avoid need to point people one by one to this PR. I read the desing page and there is mentioned that autotools will be used for C-part as an implementation and configure script should have the option --enable-server which default yes. I could not find any contradiction between my proposal and desing page. LS """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255313933 From freeipa-github-notification at redhat.com Fri Oct 21 07:41:26 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Fri, 21 Oct 2016 09:41:26 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ > Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. Maybe this is why we do not understand each other. Autotools will orchestrate the complete build including configuration of Python (and other) components. This is what I meant by `Use autotools suite to orchestrate the build on the top-level` in the design document. If it is confusing I'm happy to improve it, just tell me what you want to see there. This PR starts to use configure to create symlinks in ipaplatform Python module and more things are comming. If you look at http://www.freeipa.org/page/V4/Build_system_refactoring#Configuration you will see that configure is going contain switches for Python components as well as for Javascript components. I.e. there is nothing like C-only configure anymore. I hope it clears the intent. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255315466 From freeipa-github-notification at redhat.com Fri Oct 21 08:07:50 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Fri, 21 Oct 2016 10:07:50 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (21/10/16 00:41), Petr ?pa?ek wrote: >> Correct me If I am wrong. The configure script is and will be used >just for detection of build dependencies for C-code. > >Maybe this is why we do not understand each other. Autotools will orchestrate the complete build including configuration of Python (and other) components. This is what I meant by `Use autotools suite to orchestrate the build on the top-level` in the design document. If it is confusing I'm happy to improve it, just tell me what you want to see there. > I cannot see a problem here. Design page just say that you will be able to optionally build and install python2 and/or python3. And setuptools instead of distutils will manage that part. I cannot see any conflict with detecting build time dependencies for C-code with enabled server and without enabled server (client_only) >This PR starts to use configure to create symlinks in ipaplatform Python module and more things are comming. If you look at http://www.freeipa.org/page/V4/Build_system_refactoring#Configuration you will see that configure is going contain switches for Python components as well as for Javascript components. I.e. there is nothing like C-only configure anymore. > Design page says something else. `./configure --without-python2 --without-python3 --without-pylint --without-jslint` . But I do not care about these options. My intention is to have a simple way how to implement "--enable-server/--disable-server". Merging everything to the one big configure script will not simplify it. It will just complicate it. And the purpose of refactoring is to make things simpler and easily maintainable. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255320295 From freeipa-github-notification at redhat.com Fri Oct 21 08:08:27 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 21 Oct 2016 10:08:27 +0200 Subject: [Freeipa-devel] [freeipa PR#177][opened] Add options to write lightweight CA cert or chain to file Message-ID: URL: https://github.com/freeipa/freeipa/pull/177 Author: frasertweedale Title: #177: Add options to write lightweight CA cert or chain to file Action: opened PR body: """ Administrators need a way to retrieve the certificate or certificate chain of an IPA-managed lightweight CA. Add params to the `ca' object for carrying the CA certificate and chain (as multiple DER values), and add the `--certificate-out' option and `--chain' flag as client-side options for writing one or the other to a file. Fixes: https://fedorahosted.org/freeipa/ticket/6178 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/177/head:pr177 git checkout pr177 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-177.patch Type: text/x-diff Size: 13448 bytes Desc: not available URL: From ftweedal at redhat.com Fri Oct 21 08:18:23 2016 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 21 Oct 2016 18:18:23 +1000 Subject: [Freeipa-devel] [PATCH] 0097 Add options to write lightweight CA cert or chain to file In-Reply-To: <2b962bda-df01-1a77-3f4d-8ee598155ae8@redhat.com> References: <20160809144716.GA23927@dhcp-40-8.bne.redhat.com> <20160816052401.GR23927@dhcp-40-8.bne.redhat.com> <7ad5a28f-9670-b76a-f100-1a6681ac52e5@redhat.com> <20160816140939.GV23927@dhcp-40-8.bne.redhat.com> <20160819111156.GQ3877@dhcp-40-8.bne.redhat.com> <20160905160506.GF11489@dhcp-40-8.bne.redhat.com> <20160923032906.GY11489@dhcp-40-8.bne.redhat.com> <2b962bda-df01-1a77-3f4d-8ee598155ae8@redhat.com> Message-ID: <20161021081823.GH20504@dhcp-40-8.bne.redhat.com> Patches have been reborn as https://github.com/freeipa/freeipa/pull/177. Brief commentary inline. If any further issues, let us continue discussion at GitHub. Thanks, Fraser On Thu, Oct 06, 2016 at 10:02:55AM +0200, Jan Cholasta wrote: > On 23.9.2016 05:29, Fraser Tweedale wrote: > > Bump for review. > > > > Rebased patches attached (there was a trivial conflict in imports). > > > > Thanks, > > Fraser > > > > On Tue, Sep 06, 2016 at 02:05:06AM +1000, Fraser Tweedale wrote: > > > On Fri, Aug 26, 2016 at 10:28:58AM +0200, Jan Cholasta wrote: > > > > On 19.8.2016 13:11, Fraser Tweedale wrote: > > > > > Bump for review. > > > > > > > > > > On Wed, Aug 17, 2016 at 12:09:39AM +1000, Fraser Tweedale wrote: > > > > > > On Tue, Aug 16, 2016 at 08:10:08AM +0200, Jan Cholasta wrote: > > > > > > > On 16.8.2016 07:24, Fraser Tweedale wrote: > > > > > > > > On Mon, Aug 15, 2016 at 08:19:33AM +0200, Jan Cholasta wrote: > > > > > > > > > On 9.8.2016 16:47, Fraser Tweedale wrote: > > > > > > > > > > On Mon, Aug 08, 2016 at 10:49:27AM +0200, Jan Cholasta wrote: > > > > > > > > > > > On 8.8.2016 09:06, Fraser Tweedale wrote: > > > > > > > > > > > > On Mon, Aug 08, 2016 at 08:54:05AM +0200, Jan Cholasta wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > On 8.8.2016 06:34, Fraser Tweedale wrote: > > > > > > > > > > > > > > Please review the attached patch with adds --certificate-out and > > > > > > > > > > > > > > --certificate-chain-out options to `ca-show' command. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Note that --certificate-chain-out currently writes a bogus file due > > > > > > > > > > > > > > to a bug in Dogtag that will be fixed in this week's build. > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6178 > > > > > > > > > > > > > > > > > > > > > > > > > > 1) The client-side *-out options should be defined on the client side, not > > > > > > > > > > > > > on the server side. > > > > > > > > > > > > > > > > > > > > > > > > > Will option defined on client side be propagated to, and observable > > > > > > > > > > > > in the ipaserver plugin? The ipaserver plugin needs to observe that > > > > > > > > > > > > *-out has been requested and executes additional command(s) on that > > > > > > > > > > > > basis. > > > > > > > > > > > > > > > > > > > > > > Is there a reason not to *always* return the certs? > > > > > > > > > > > > > > > > > > > > > We hit Dogtag to retrieve them. > > > > > > > > > > > > > > > > > > I don't think that's an issue in a -show command. > > > > > > > > > > > > > > > > > cert_show is invoked by other commands (cert_find*, cert_show, > > > > > > > > cert_request, cert_status, ca_del) but these all hit Dogtag anyway > > > > > > > > so I suppose that's fine. I'll return the cert *and* the chain in > > > > > > > > separate attributes, unconditionally. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) I don't think there should be additional information included in summary > > > > > > > > > > > > > (and it definitely should not be multi-line). I would rather inform the user > > > > > > > > > > > > > via an error message when unable to write the files. > > > > > > > > > > > > > > > > > > > > > > > > > I was just following the pattern of other commands that write certs, > > > > > > > > > > > > profile config, etc. Apart from consistency with other commands I > > > > > > > > > > > > agree that there is no need to have it. So I will remove it. > > > > > > > > > > > > > > > > > > > > > > > > > If you think there is an actual value in informing the user about > > > > > > > > > > > > > successfully writing the files, please use ipalib.messages for the job. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3) IMO a better format for the certificate chain than PKCS#7 would be > > > > > > > > > > > > > concatenated PEM, as that's the most commonly used format in IPA (in > > > > > > > > > > > > > installers, there are no cert chains in API commands ATM). > > > > > > > > > > > > > > > > > > > > > > > > > Sure, but the main use case isn't IPA. Other apps require PKCS #7 > > > > > > > > > > > > or concatenated PEMs, but sometimes they must be concatenated > > > > > > > > > > > > forward, and othertimes backwards. There is no one size fits all. > > > > > > > > > > > > > > > > > > > > > > True, which is exactly why I think we should at least be self-consistent and > > > > > > > > > > > use concatenated PEM (and multi-value DER over the wire). > > > > > > > > > > > > > > > > > > > > > Dogtag returns a PKCS7 (either DER or PEM, according to HTTP Accept > > > > > > > > > > header). > > > > > > > > > > > > > > > > > > > > If we want list-of-PEMs between server and client we have to convert > > > > > > > > > > on the server. Do we have a good way of doing this without exec'ing > > > > > > > > > > `openssl pkcs7' on the server? Is it acceptable to exec 'openssl' > > > > > > > > > > to do the conversion on the server? python-nss does not have PKCS7 > > > > > > > > > > functions and I am not keen on adding a pyasn1 PKCS7 parser just for > > > > > > > > > > the sake of pushing bits as list-of-PEMs. > > > > > > > > > > > > > > > > > > I'm afraid we can't avoid conversion to/from PKCS#7 one way or the other. > > > > > > > > > For example, if we added a call to retrieve external CA chain using certs > > > > > > > > > from cn=certificates,cn=ipa,cn=etc, we would have to convert the result to > > > > > > > > > PKCS#7 if it was our cert chain format of choice. > > > > > > > > > > > > > > > > > > What we can avoid though is executing "openssl pkcs7" to do the conversion - > > > > > > > > > we can use an approach similar to our DNSSEC code and use python-cffi to > > > > > > > > > call libcrypto's PKCS#7 conversion routines instead. > > > > > > > > > > > > > > > > > I had a look at the OpenSSL API for parsing PKCS #7; now I prefer to > > > > > > > > exec `openssl' to do the job :) > > > > > > > > > > > > > > > > I will transmit DER-encoded PKCS #7 object on the wire; we cannot > > > > > > > > used multi-valued DER attribute because order is important. Client > > > > > > > > will convert to PEMs. > > > > > > > > > > > > > > Well, my point was not to send PKCS#7 over the wire, so that clients > > > > > > > (including 3rd party clients) do not have to convert from PKCS#7 themselves. > > > > > > > > > > > > > > In fact we can use multi-valued DER - whatever you send over the wire from > > > > > > > the server will be received in the exact same order by the client. Even if > > > > > > > it wasn't, you can easily restore the order by matching issuer and subject > > > > > > > names of the certificates. > > > > > > > > > > > > > > > > > > > > > > > Should have new patch on list this afternoon. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Fraser > > > > > > > > > > > > > > > > > > > > > > > > > > > > FWIW, man pages and code suggest that PKCS #7 is accepted in > > > > > > > > > > installer, etc. > > > > > > > > > > > > > > > > > > True, but that's a relatively new feature (since 4.1) and the installer > > > > > > > > > internally executes "openssl pkcs7" to convert PKCS #7 to list of certs :-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can add an option to control the format later, but for now, > > > > > > > > > > > > Dogtag returns a PKCS #7 (PEM or DER) so let's go with that. Worst > > > > > > > > > > > > case is an admin has to invoke `openssl pkcs7' and concat the certs > > > > > > > > > > > > themselves. > > > > > > > > > > > > > > > > > > > > > > AFAIK none of NSS, OpenSSL or p11-kit can use PKCS#7 cert chains directly, > > > > > > > > > > > so I'm afraid the worst case would happen virtually always. > > > > > > > > > > > > > > > > > > > > > If you're OK with invoking OpenSSL on the client to convert PKCS #7 > > > > > > > > > > to list-of-PEMs (similar to what is done in > > > > > > > > > > ipapython.certdb.NSSDatabase) then we can have the client perform > > > > > > > > > > the conversion. > > > > > > > > > > > > > > > > > > See above. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4) Over the wire, the certs should be DER-formatted, as that's the most > > > > > > > > > > > > > common wire format in other API commands. > > > > > > > > > > > > > > > > > > > > > > > > > OK. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5) What is the benefit in having the CA cert and the rest of the chain > > > > > > > > > > > > > separate? For end-entity certs it makes sense to separate the cert from the > > > > > > > > > > > > > CA chain, but for CA certs, you usually want the full chain, no? > > > > > > > > > > > > > > > > > > > > > > > > > If you want to anchor trust directly at a subca (e.g. restrict VPN > > > > > > > > > > > > login to certs issued by VPN sub-CA) then you often just want the > > > > > > > > > > > > cert. The chain option does subsume it, at cost of more work for > > > > > > > > > > > > administrators with this use case. I think it makes sense to keep > > > > > > > > > > > > both options. > > > > > > > > > > > > > > > > > > > > > > Does it? From what you described above, you either want just the sub-CA > > > > > > > > > > > cert, or the full chain including the sub-CA cert, in which case it might > > > > > > > > > > > make more sense to have a single --out option and a --chain flag. > > > > > > > > > > > > > > > > > > > > > How about --certificate-out which defaults to single cert, but does > > > > > > > > > > chain (as list-of-PEMs) when --chain flag given. > > > > > > > > > > > > > > > > > > > > Per https://fedorahosted.org/freeipa/ticket/5166 let's not add more > > > > > > > > > > `--out' options. > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > Updated patch 0097-2 attached, and new patch 0099 which must be > > > > > > applied first. > > > > > > > > > > > > I have implemented the suggested changes, except for cffi (I execute > > > > > > `openssl pkcs7' instead). > > > > > > > > I don't like it, but OK. Another alternative would be to use pyasn1. > > > > > > > I don't like it either, but neither did I like the idea of > > > reimplementing the wheel with pyasn1. Now is not the time for > > > busywork :) > > > > > > > > > > > > > > > There are two new output attributes on the wire, 'certificate' > > > > > > (single-value DER X.509), and 'certificate_chain' (ordered > > > > > > multi-value DER X.509). They are always returned. The first cert > > > > > > in the chain is always the same as 'certificate'; obviously this is > > > > > > redunant but I have left it this way because I think usage is > > > > > > clearer. > > > > > > > > I don't have a strong feeling about this one way or the other, but the same > > > > scheme should be used for cert-show in the future. Does it make sense to do > > > > it this way for cert-show? > > > > > > > > I'm not sure about always returning the chain in cert-show. Now that we have > > > > a --chain flag rather than two out options, maybe we should go back to > > > > returning the chain only if --chain is specified. What do you think? > > > > > > > I think we should go for consistency and always include both over > > > the wire. > > My point exactly - ca-show output should be equivalent to cert-show on the > CA certificate, as far as the certificate and chain are concerned. > I reused `BaseCertObject.takes_params' and `BaseCertObject._parse' to define the params and do most of the work. There is some overlap with what `BaseCertObject' defines and fields of the `ca' LDAP attribute so these are ignored/removed. > > If we want to hide cert or chain or both at the `ipa' CLI > > > depending on options, I also don't feel strongly either way. For > > > now they're both displayed. > > I think I would prefer if the certificate was always returned by the server, > but the chain only if --chain (or --all) is specified. > > Additionally, ca-add should also get the new options and do all of this. > I've implemented this. `--chain' implies `--all' but otherwise remains a client-side only param. A single MethodOverride provides the desired functionality and is inherited by both `ca_add' and `ca_show' on the client side. > > > > > > > > > > > Patch 0099: > > > > > > > > 1) Please fix this: > > > > > > > > $ git show -U0 | pep8 --diff > > > > ./ipalib/x509.py:59:80: E501 line too long (93 > 79 characters) > > > > > > > Done. > > > > > > > > > > > Patch 0097: > > > > > > > > 1) `certificate` and `certificate_chain` are actually attributes of the ca > > > > object, so they should be defined in ca.takes_params rather than > > > > ca_show.has_output_params. > > > > > > > Done. Out of interest, now that they are part of ca_takes_params is > > > there a way to hide them by default in CLI output, and only show > > > them when `--all' is given? > > > > > > > > > > > 2) Please fix these: > > > > > > > > $ git show -U0 | pep8 --diff > > > > ./ipaclient/plugins/ca.py:21:9: E124 closing bracket does not match visual > > > > indentation > > > > ./ipaclient/plugins/ca.py:23:13: E128 continuation line under-indented for > > > > visual indent > > > > ./ipaclient/plugins/ca.py:24:13: E128 continuation line under-indented for > > > > visual indent > > > > ./ipaclient/plugins/ca.py:25:13: E128 continuation line under-indented for > > > > visual indent > > > > ./ipaclient/plugins/ca.py:26:9: E124 closing bracket does not match visual > > > > indentation > > > > ./ipaclient/plugins/ca.py:38:13: E731 do not assign a lambda expression, use > > > > a def > > > > > > > Done. Updated patches attached. > > > > > > Thanks, > > > Fraser > > > > > From 046b3dd078c4ccc3732a0106786bae4c01d30a89 Mon Sep 17 00:00:00 2001 > > > From: Fraser Tweedale > > > Date: Tue, 16 Aug 2016 13:16:58 +1000 > > > Subject: [PATCH] Add function for extracting PEM certs from PKCS #7 > > > > > > Add a single function for extracting X.509 certs in PEM format from > > > a PKCS #7 object. Refactor sites that execute ``openssl pkcs7`` to > > > use the new function. > > > > > > Part of: https://fedorahosted.org/freeipa/ticket/6178 > > > --- > > > ipalib/x509.py | 23 +++++++++++++++++- > > > ipapython/certdb.py | 14 ++++------- > > > ipaserver/install/cainstance.py | 52 +++++++++++++++-------------------------- > > > 3 files changed, 45 insertions(+), 44 deletions(-) > > > > > > diff --git a/ipalib/x509.py b/ipalib/x509.py > > > index e986a97a58aafd3aeab08765a397edbf67c7841a..0461553a73e3862c85f1ffcfe4432cabf4fdf7a1 100644 > > > --- a/ipalib/x509.py > > > +++ b/ipalib/x509.py > > > @@ -51,11 +51,14 @@ from ipalib import util > > > from ipalib import errors > > > from ipaplatform.paths import paths > > > from ipapython.dn import DN > > > +from ipapython import ipautil > > > > > > PEM = 0 > > > DER = 1 > > > > > > -PEM_REGEX = re.compile(r'(?<=-----BEGIN CERTIFICATE-----).*?(?=-----END CERTIFICATE-----)', re.DOTALL) > > > +PEM_REGEX = re.compile( > > > + r'-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----', > > > + re.DOTALL) > > > > > > EKU_SERVER_AUTH = '1.3.6.1.5.5.7.3.1' > > > EKU_CLIENT_AUTH = '1.3.6.1.5.5.7.3.2' > > > @@ -148,6 +151,24 @@ def load_certificate_list(data, dbdir=None): > > > certs = [load_certificate(cert, PEM, dbdir) for cert in certs] > > > return certs > > > > > > + > > > +def pkcs7_to_pems(data, datatype=PEM): > > > + """ > > > + Extract certificates from a PKCS #7 object. > > > + > > > + Return a ``list`` of X.509 PEM strings. > > > + > > > + May throw ``ipautil.CalledProcessError`` on invalid data. > > > + > > > + """ > > > + cmd = [ > > > + paths.OPENSSL, "pkcs7", "-print_certs", > > > + "-inform", "PEM" if datatype == PEM else "DER", > > > + ] > > > + result = ipautil.run(cmd, stdin=data, capture_output=True) > > > + return PEM_REGEX.findall(result.output) > > > + > > > + > > > def load_certificate_list_from_file(filename, dbdir=None): > > > """ > > > Load a certificate list from a PEM file. > > > diff --git a/ipapython/certdb.py b/ipapython/certdb.py > > > index e19f712d82f160ebc5de9c5b8d6627cb941c2cef..fd18023794a2daace60efd97aff54180b8409bbd 100644 > > > --- a/ipapython/certdb.py > > > +++ b/ipapython/certdb.py > > > @@ -270,13 +270,11 @@ class NSSDatabase(object): > > > continue > > > > > > if label in ('PKCS7', 'PKCS #7 SIGNED DATA', 'CERTIFICATE'): > > > - args = [ > > > - paths.OPENSSL, 'pkcs7', > > > - '-print_certs', > > > - ] > > > try: > > > - result = ipautil.run( > > > - args, stdin=body, capture_output=True) > > > + certs = x509.pkcs7_to_pems(body) > > > + extracted_certs += '\n'.join(certs) + '\n' > > > + loaded = True > > > + continue > > > except ipautil.CalledProcessError as e: > > > if label == 'CERTIFICATE': > > > root_logger.warning( > > > @@ -287,10 +285,6 @@ class NSSDatabase(object): > > > "Skipping PKCS#7 in %s at line %s: %s", > > > filename, line, e) > > > continue > > > - else: > > > - extracted_certs += result.output + '\n' > > > - loaded = True > > > - continue > > Moving this to the try block is a completely unnecessary change. > Moved it back :) > > > > > > if label in ('PRIVATE KEY', 'ENCRYPTED PRIVATE KEY', > > > 'RSA PRIVATE KEY', 'DSA PRIVATE KEY', > > > diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py > > > index c4b8e9ae326fb7ebda9e927cd4d0b5bad9743db4..f57c724b0273a275f8146f0d6055e2ee2e51192c 100644 > > > --- a/ipaserver/install/cainstance.py > > > +++ b/ipaserver/install/cainstance.py > > > @@ -844,44 +844,30 @@ class CAInstance(DogtagInstance): > > > # makes openssl throw up. > > > data = base64.b64decode(chain) > > > > > > - result = ipautil.run( > > > - [paths.OPENSSL, > > > - "pkcs7", > > > - "-inform", > > > - "DER", > > > - "-print_certs", > > > - ], stdin=data, capture_output=True) > > > - certlist = result.output > > > + certlist = x509.pkcs7_to_pems(data, x509.DER) > > > > > > # Ok, now we have all the certificates in certs, walk through it > > > # and pull out each certificate and add it to our database > > > > > > - st = 1 > > > - en = 0 > > > - subid = 0 > > > ca_dn = DN(('CN','Certificate Authority'), self.subject_base) > > > - while st > 0: > > > - st = certlist.find('-----BEGIN', en) > > > - en = certlist.find('-----END', en+1) > > > - if st > 0: > > > - try: > > > - (chain_fd, chain_name) = tempfile.mkstemp() > > > - os.write(chain_fd, certlist[st:en+25]) > > > - os.close(chain_fd) > > > - (_rdn, subject_dn) = certs.get_cert_nickname(certlist[st:en+25]) > > > - if subject_dn == ca_dn: > > > - nick = get_ca_nickname(self.realm) > > > - trust_flags = 'CT,C,C' > > > - else: > > > - nick = str(subject_dn) > > > - trust_flags = ',,' > > > - self.__run_certutil( > > > - ['-A', '-t', trust_flags, '-n', nick, '-a', > > > - '-i', chain_name] > > > - ) > > > - finally: > > > - os.remove(chain_name) > > > - subid += 1 > > > + for cert in certlist: > > > + try: > > > + (chain_fd, chain_name) = tempfile.mkstemp() > > > + os.write(chain_fd, cert) > > > + os.close(chain_fd) > > > + (_rdn, subject_dn) = certs.get_cert_nickname(cert) > > > + if subject_dn == ca_dn: > > > + nick = get_ca_nickname(self.realm) > > > + trust_flags = 'CT,C,C' > > > + else: > > > + nick = str(subject_dn) > > > + trust_flags = ',,' > > > + self.__run_certutil( > > > + ['-A', '-t', trust_flags, '-n', nick, '-a', > > > + '-i', chain_name] > > > + ) > > > + finally: > > > + os.remove(chain_name) > > > > > > def __request_ra_certificate(self): > > > # Create a noise file for generating our private key > > > -- > > > 2.5.5 > > > > > > > > From fba36bd2b86c2aee1d77e05aa563ced4633ab182 Mon Sep 17 00:00:00 2001 > > > From: Fraser Tweedale > > > Date: Mon, 8 Aug 2016 14:27:20 +1000 > > > Subject: [PATCH] Add options to write lightweight CA cert or chain to file > > > > > > Administrators need a way to retrieve the certificate or certificate > > > chain of an IPA-managed lightweight CA. Add params to the `ca' > > > object for carrying the CA certificate and chain (as multiple DER > > > values), and add the `--certificate-out' option and `--chain' flag > > > as client-side options for writing one or the other to a file. > > > > > > Fixes: https://fedorahosted.org/freeipa/ticket/6178 > > > --- > > > ipaclient/plugins/ca.py | 50 +++++++++++++++++++++++++++++++++++++++++++++ > > > ipaserver/plugins/ca.py | 31 ++++++++++++++++++++++++---- > > > ipaserver/plugins/dogtag.py | 12 +++++++++++ > > > 3 files changed, 89 insertions(+), 4 deletions(-) > > > create mode 100644 ipaclient/plugins/ca.py > > > > > > diff --git a/ipaclient/plugins/ca.py b/ipaclient/plugins/ca.py > > > new file mode 100644 > > > index 0000000000000000000000000000000000000000..f7e55dec196495f820ebf745eb49e8ddce6b3ee7 > > > --- /dev/null > > > +++ b/ipaclient/plugins/ca.py > > > @@ -0,0 +1,50 @@ > > > +# > > > +# Copyright (C) 2016 FreeIPA Contributors see COPYING for license > > > +# > > > + > > > +import base64 > > > +from ipaclient.frontend import MethodOverride > > > +from ipalib import util, x509, Flag, Str > > > +from ipalib.plugable import Registry > > > +from ipalib.text import _ > > > + > > > +register = Registry() > > > + > > > + > > > + at register(override=True, no_fail=True) > > > +class ca_show(MethodOverride): > > > + > > > + takes_options = ( > > > + Str( > > > + 'certificate_out?', > > > + doc=_('Write certificate to file'), > > > + include='cli', > > > + ), > > > + Flag( > > > + 'chain', > > > + default=False, > > > + doc=_('Write certificate chain instead of single certificate'), > > > + include='cli', > > > + ), > > > + ) > > > + > > > + def forward(self, *keys, **options): > > > + filename = None > > > + if 'certificate_out' in options: > > > + filename = options.pop('certificate_out') > > > + util.check_writable_file(filename) > > > + chain = options.pop('chain', False) > > > + > > > + result = super(ca_show, self).forward(*keys, **options) > > > + if filename: > > > + def to_pem(x): > > > + return x509.make_pem(base64.b64encode(x)) > > > + if chain: > > > + ders = result['result']['certificate_chain'] > > > + data = '\n'.join(map(to_pem, ders)) > > Generator expressions are generally preferred over map(): > > data = '\n'.join(to_pem(der) for der in ders) > Preferred by whom? ;) I changed it to gen expr. > > > + else: > > > + data = to_pem(result['result']['certificate']) > > > + with open(filename, 'wb') as f: > > > + f.write(data) > > > + > > > + return result > > > diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py > > > index 966ae2b1bdb4bb0207dfa58f0e9c951bc930f766..0684ddaed0ebfcab8910c1ea356550b504af15e2 100644 > > > --- a/ipaserver/plugins/ca.py > > > +++ b/ipaserver/plugins/ca.py > > > @@ -2,14 +2,14 @@ > > > # Copyright (C) 2016 FreeIPA Contributors see COPYING for license > > > # > > > > > > -from ipalib import api, errors, DNParam, Str > > > +from ipalib import api, errors, Bytes, DNParam, Str > > > from ipalib.constants import IPA_CA_CN > > > from ipalib.plugable import Registry > > > from ipaserver.plugins.baseldap import ( > > > LDAPObject, LDAPSearch, LDAPCreate, LDAPDelete, > > > LDAPUpdate, LDAPRetrieve) > > > from ipaserver.plugins.cert import ca_enabled_check > > > -from ipalib import _, ngettext > > > +from ipalib import _, ngettext, x509 > > > > > > > > > __doc__ = _(""" > > > @@ -79,6 +79,18 @@ class ca(LDAPObject): > > > doc=_('Issuer Distinguished Name'), > > > flags=['no_create', 'no_update'], > > > ), > > > + Bytes( > > > + 'certificate', > > > + label=_("Certificate"), > > > + doc=_("X.509 certificate"), > > > + flags={'no_create', 'no_update', 'no_search', 'no_display'}, > > Note that the no_display flag currently does nothing. > Removed the flag. > > > > + ), > > > + Bytes( > > > + 'certificate_chain*', > > > + label=_("Certificate chain"), > > > + doc=_("PKCS #7 certificate chain"), > > Looks like you forgot to update the doc string. > Well spotted; updated. > > > + flags={'no_create', 'no_update', 'no_search', 'no_display'}, > > > + ), > > > ) > > > > > > permission_filter_objectclasses = ['ipaca'] > > > @@ -140,9 +152,20 @@ class ca_find(LDAPSearch): > > > class ca_show(LDAPRetrieve): > > > __doc__ = _("Display the properties of a CA.") > > > > > > - def execute(self, *args, **kwargs): > > > + def execute(self, *keys, **options): > > > ca_enabled_check() > > > - return super(ca_show, self).execute(*args, **kwargs) > > > + result = super(ca_show, self).execute(*keys, **options) > > > + > > > + ca_id = result['result']['ipacaid'][0] > > > + with self.api.Backend.ra_lightweight_ca as ca_api: > > > + result['result']['certificate'] = ca_api.read_ca_cert(ca_id) > > > + > > > + pkcs7_der = ca_api.read_ca_chain(ca_id) > > > + pems = x509.pkcs7_to_pems(pkcs7_der, x509.DER) > > > + ders = (x509.normalize_certificate(pem) for pem in pems) > > > + result['result']['certificate_chain'] = list(ders) > > I would think list comprehension is the obvious choice over generator > expression when generating a list: > > ders = [x509.normalize_certificate(pem) for pem in pems] > result['result']['certificate_chain'] = ders > Changed, thanks. > > > + > > > + return result > > > > > > > > > @register() > > > diff --git a/ipaserver/plugins/dogtag.py b/ipaserver/plugins/dogtag.py > > > index aef1e888eb1b6c273c1fd12cbf4912407f8f8132..1fd3106e0ae723eb30dbe32c61e637790f6085d2 100644 > > > --- a/ipaserver/plugins/dogtag.py > > > +++ b/ipaserver/plugins/dogtag.py > > > @@ -2205,6 +2205,18 @@ class ra_lightweight_ca(RestClient): > > > except: > > > raise errors.RemoteRetrieveError(reason=_("Response from CA was not valid JSON")) > > > > > > + def read_ca_cert(self, ca_id): > > > + status, resp_headers, resp_body = self._ssldo( > > > + 'GET', '{}/cert'.format(ca_id), > > > + headers={'Accept': 'application/pkix-cert'}) > > > + return resp_body > > > + > > > + def read_ca_chain(self, ca_id): > > > + status, resp_headers, resp_body = self._ssldo( > > > + 'GET', '{}/chain'.format(ca_id), > > > + headers={'Accept': 'application/pkcs7-mime'}) > > > + return resp_body > > > + > > > def disable_ca(self, ca_id): > > > self._ssldo( > > > 'POST', ca_id + '/disable', > > > -- > > > 2.5.5 > > > > > -- > Jan Cholasta From ofayans at redhat.com Fri Oct 21 08:54:19 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Fri, 21 Oct 2016 10:54:19 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: <6089c103-ab56-62f7-971c-a41710eee22f@redhat.com> References: <57A07FE4.8000904@redhat.com> <2b0ed7fe-f0bc-7137-bdc1-b0758ffe9cd6@redhat.com> <20160914154119.mkk2ma7tvks55xsu@redhat.com> <97eaa313-e889-cd4a-e900-9e88596577a0@redhat.com> <20160914155320.iowrijrq3z62evoo@redhat.com> <1af52e6c-c24b-d58b-ccf5-a85c5c290e0c@redhat.com> <20160914165348.GE2761@p.Speedport_W_724V_Typ_A_05011603_00_009> <59763ea7-2ab5-bdc2-72c1-489a462f78ef@redhat.com> <6089c103-ab56-62f7-971c-a41710eee22f@redhat.com> Message-ID: <1d744d16-75de-2bdc-5892-b3c36a305581@redhat.com> Added one more test, resolved the pep8 issues On 10/19/2016 12:32 PM, Oleg Fayans wrote: > Hi Martin, > > As you suggested, I've extended the > test_xmlrpc/test_add_remove_cert_cmd.py to contain basic tests for certs > in idoverrides. > The integration part still needs some polishing in the part related to > user lookup by cert > > On 10/14/2016 03:57 PM, Martin Babinsky wrote: >> On 10/14/2016 03:48 PM, Oleg Fayans wrote: >>> So, did I understand correctly, that there would be 2 patches: one >>> containing test for basic idoverrides functionality without >>> AD-integration, and the second one - with AD-integration and an sssd >>> check, correct? >>> I guess, the >>> freeipa-ofayans-0050.1-Automated-test-for-certs-in-idoverrides-feature.patch >>> >>> >>> might be a good candidate for the first one, I only have to change the >>> filename to test_idviews.py, right? >>> >> >> Oleg, we already have XMLRPC tests for idoverrides: >> >> ipatests/test_xmlrpc/test_idviews_plugin.py >> >> Is there any particular reason why not to extend them with add >> cert/remove cert operations? >> >> Even better, you can extend >> `ipatests/test_xmlrpc/test_add_remove_cert_cmd.py` suite by doing the >> same set of tests on idoverrideuser objects. >> >> Or am I missing something? >> >>> On 09/15/2016 10:32 AM, Martin Basti wrote: >>>> >>>> >>>> On 15.09.2016 10:10, Oleg Fayans wrote: >>>>> Hi Martin, >>>>> >>>>> The file was renamed. Did I understand correctly that for now we are >>>>> leaving the test as is and are planning to extend it later? >>>> >>>> I would like to have there SSSD check involved, please use what Summit >>>> recommends. No new test cases. >>>> >>>> And this can be done by separate patch, I want to have API/CLI >>>> certificate override tests for non-AD idview (extending current tests I >>>> posted in this thread) >>>> >>>> Martin^2 >>>>> >>>>> On 09/15/2016 09:49 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 14.09.2016 18:53, Sumit Bose wrote: >>>>>>> On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote: >>>>>>>> >>>>>>>> On 14.09.2016 17:53, Alexander Bokovoy wrote: >>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> On 14.09.2016 17:41, Alexander Bokovoy wrote: >>>>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>>>> 1) >>>>>>>>>>>> I still don't see the reason why AD trust is needed. Default >>>>>>>>>>>> trust ID view is added just by ipa-adtrust-install, adding >>>>>>>>>>>> trust is not needed for current implementation. You don't >>>>>>>>>>>> need AD for this, IDviews is generic feature not just for >>>>>>>>>>>> AD. Is that user configured on AD side? >>>>>>>>>>> You cannot add non-AD user to 'default trust view', so you will >>>>>>>>>>> not be >>>>>>>>>>> able to set up certificates to ID override which does not exist. >>>>>>>>>>> >>>>>>>>>>> For non-'default trust view' you can add both IPA and AD users, >>>>>>>>>>> so using >>>>>>>>>>> some other view and then assign certificate for a ID override in >>>>>>>>>>> that >>>>>>>>>>> one. >>>>>>>>>>> >>>>>>>>>> Ok then, but anyway I would like to see API/CLI tests for this >>>>>>>>>> feature with proper output validation. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> How can be this tested with SSSD? >>>>>>>>> You need to log into the system with a certificate... >>>>>>>> Is this possible from test? We are logged remotely as root, is >>>>>>>> there any >>>>>>>> cmdline util which allows us to test certificate against AD user? >>>>>>> >>>>>>> You can use 'sss_ssh_authorizedkeys aduser at ad.domain' which should >>>>>>> return the ssh key derived from the public key in the certificate. >>>>>>> This >>>>>>> should work for certificate stored in AD as well as for overrides. >>>>>>> >>>>>>> You can also you the DBus lookup by certificate as described in >>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate >>>>>>> >>>>>>> >>>>>>> . >>>>>>> >>>>>>> HTH >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>> >>>>>> Thank you Alexander and Summit for hints. >>>>>> >>>>>> Oleg I realized we don't have any other idviews integration tests >>>>>> >>>>>> So I propose to rename test file you are adding to >>>>>> test_idviews.py. We >>>>>> can add more testcases for idviews there later >>>>>> >>>>>> Martin^2 >>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0089.1-tests-Added-basic-tests-for-certs-in-idoverrides.patch Type: text/x-patch Size: 4380 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 21 10:27:17 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 21 Oct 2016 12:27:17 +0200 Subject: [Freeipa-devel] [freeipa PR#174][comment] add log module In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/174 Title: #174: add log module mbasti-rh commented: """ > Yes. As you see, our use case is I'm admin and want to audit what commads were used. > In this case, if it is only for admins I endorse you to use centralized logging: - http://www.freeipa.org/page/Centralized_Logging > Because I use freeipa 4.3.1 version, adaptation through on this version, I saw the master branch source code structure is different from the ipa-4-3 branch, I am not sure if there is a problem after adding log module, so created pull request on the ipa-4-3 branch. Yes, master differs from 4.3, and as I said, new features are merged only to master, 4.3.x is only for bugfixes > > We can set up the log file permissions. Currently only the admin can view the log information in web interface. Where is this enforced in code? AFAIK you are accessing log as httpd user > The log module adapted by freeipa 4.3.1 version, not sure if there is a problem in other versions. As for the replicated topology, I need to familiar with its function. FreeIPA supports multimaster topology, your current implementation shows only history of commands from the server where a user is actually connected. It will not provide history from all servers. > Parsing the log is to show more friendly in the web interface. IMO Kibana and centralized logging shows log information in nice way too > BTW, there is still no respond about joining Chinese translation organization in zanata https://fedora.zanata.org/language/view/zh-CN?dswid=2727 Have you tried others way how to get into? Maybe ask teamlead on IRC https://fedoraproject.org/wiki/L10N_Teams https://fedoraproject.org/wiki/L10N_Simplified_Chinese_Team """ See the full comment at https://github.com/freeipa/freeipa/pull/174#issuecomment-255347803 From freeipa-github-notification at redhat.com Fri Oct 21 13:21:56 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Fri, 21 Oct 2016 15:21:56 +0200 Subject: [Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker apophys commented: """ Thank you, ack. """ See the full comment at https://github.com/freeipa/freeipa/pull/148#issuecomment-255363641 From freeipa-github-notification at redhat.com Fri Oct 21 13:22:06 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Fri, 21 Oct 2016 15:22:06 +0200 Subject: [Freeipa-devel] [freeipa PR#148][+ack] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker Label: +ack From freeipa-github-notification at redhat.com Fri Oct 21 13:22:18 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Fri, 21 Oct 2016 15:22:18 +0200 Subject: [Freeipa-devel] [freeipa PR#178][opened] ipatests: Fix assert_deepequal outside of pytest process Message-ID: URL: https://github.com/freeipa/freeipa/pull/178 Author: apophys Title: #178: ipatests: Fix assert_deepequal outside of pytest process Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6420 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/178/head:pr178 git checkout pr178 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-178.patch Type: text/x-diff Size: 1086 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Oct 21 15:13:10 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Fri, 21 Oct 2016 17:13:10 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ We (lslebodn and pspacek) agree that we disagree about maintainability of client_only in one monolithic configure.ac. But we agreed that the refactoring of build system[1] is more important. I will close my eyes and you can push the patch-set. :-) [1] http://www.freeipa.org/page/V4/Build_system_refactoring """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255404139 From freeipa-github-notification at redhat.com Fri Oct 21 15:26:44 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Fri, 21 Oct 2016 17:26:44 +0200 Subject: [Freeipa-devel] [freeipa PR#171][+ack] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 Label: +ack From freeipa-github-notification at redhat.com Fri Oct 21 15:27:27 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Fri, 21 Oct 2016 17:27:27 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 pspacek commented: """ Re-adding ACK which was removed while we were "resolving" our disagreement with Lukas. """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255408029 From freeipa-github-notification at redhat.com Sat Oct 22 04:18:07 2016 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Sat, 22 Oct 2016 06:18:07 +0200 Subject: [Freeipa-devel] [freeipa PR#177][synchronized] Add options to write lightweight CA cert or chain to file In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/177 Author: frasertweedale Title: #177: Add options to write lightweight CA cert or chain to file Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/177/head:pr177 git checkout pr177 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-177.patch Type: text/x-diff Size: 13452 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 05:35:46 2016 From: freeipa-github-notification at redhat.com (Akasurde) Date: Mon, 24 Oct 2016 07:35:46 +0200 Subject: [Freeipa-devel] [freeipa PR#179][opened] Fix for handling CalledProcessError in authconfig Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Author: Akasurde Title: #179: Fix for handling CalledProcessError in authconfig Action: opened PR body: """ NIS configuration error should be hidden from user while running ipa-client-install Fixes https://fedorahosted.org/freeipa/ticket/5244 Signed-off-by: Abhijeet Kasurde """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/179/head:pr179 git checkout pr179 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-179.patch Type: text/x-diff Size: 3108 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 06:45:15 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 24 Oct 2016 08:45:15 +0200 Subject: [Freeipa-devel] [freeipa PR#177][comment] Add options to write lightweight CA cert or chain to file In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/177 Title: #177: Add options to write lightweight CA cert or chain to file jcholast commented: """ The original review thread is available at: https://www.redhat.com/archives/freeipa-devel/2016-October/msg00578.html """ See the full comment at https://github.com/freeipa/freeipa/pull/177#issuecomment-255660397 From freeipa-github-notification at redhat.com Mon Oct 24 07:01:24 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 24 Oct 2016 09:01:24 +0200 Subject: [Freeipa-devel] [freeipa PR#143][synchronized] Issue6386 nss dir In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/143 Author: tiran Title: #143: Issue6386 nss dir Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/143/head:pr143 git checkout pr143 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-143.patch Type: text/x-diff Size: 3180 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 07:11:26 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 24 Oct 2016 09:11:26 +0200 Subject: [Freeipa-devel] [freeipa PR#143][comment] Issue6386 nss dir In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/143 Title: #143: Issue6386 nss dir tiran commented: """ Please ack. """ See the full comment at https://github.com/freeipa/freeipa/pull/143#issuecomment-255664324 From freeipa-github-notification at redhat.com Mon Oct 24 07:49:27 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 24 Oct 2016 09:49:27 +0200 Subject: [Freeipa-devel] [freeipa PR#180][opened] Make api.env.nss_dir relative to api.env.confdir Message-ID: URL: https://github.com/freeipa/freeipa/pull/180 Author: tiran Title: #180: Make api.env.nss_dir relative to api.env.confdir Action: opened PR body: """ api.env.nss_dir is no longer hard-coded to paths.IPA_NSSDB_DIR. Instead the path is calculated relatively to api.env.confdir. The default value is still /etc/ipa/nssdb. The change makes it a bit easier to run FreeIPA's API with a custom configuration directory. See https://fedorahosted.org/freeipa/ticket/6386 Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/180/head:pr180 git checkout pr180 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-180.patch Type: text/x-diff Size: 2021 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 09:47:22 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 24 Oct 2016 11:47:22 +0200 Subject: [Freeipa-devel] [freeipa PR#181][opened] Tests : User Tracker creation of user with minimal values Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Author: gkaihorodova Title: #181: Tests : User Tracker creation of user with minimal values Action: opened PR body: """ Fix provide possibility to create user-add test with minimal values, where uid is not specified, to provide better coverage https://fedorahosted.org/freeipa/ticket/6126 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/181/head:pr181 git checkout pr181 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-181.patch Type: text/x-diff Size: 3104 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 11:30:49 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 24 Oct 2016 13:30:49 +0200 Subject: [Freeipa-devel] [freeipa PR#171][+pushed] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 Label: +pushed From freeipa-github-notification at redhat.com Mon Oct 24 11:30:51 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 24 Oct 2016 13:30:51 +0200 Subject: [Freeipa-devel] [freeipa PR#171][closed] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Author: pspacek Title: #171: Build system cleanup phase 2 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/171/head:pr171 git checkout pr171 From freeipa-github-notification at redhat.com Mon Oct 24 11:30:52 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 24 Oct 2016 13:30:52 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 dkupka commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/329f080e6ac832ffd568e79ebca9907771f8ad61 https://fedorahosted.org/freeipa/changeset/41da8732051c193166fa69cd9bc1152d39ad8720 https://fedorahosted.org/freeipa/changeset/25dab77301f9e0289b94b0a672aed5067384c8ce https://fedorahosted.org/freeipa/changeset/b0cb6afa2308b9d96456f0355771ecbef0ca7263 https://fedorahosted.org/freeipa/changeset/6e1d777d2878de1e90e1dab4949075d31ffb0d52 https://fedorahosted.org/freeipa/changeset/5e028b59bcd3c485cc034f491a0171f26b03ce3a https://fedorahosted.org/freeipa/changeset/927ddcb95aeb5c9bcc0cb08c5f08cecdccd0acb8 https://fedorahosted.org/freeipa/changeset/0d37619db41abddabdd313f036f453821f438c8a https://fedorahosted.org/freeipa/changeset/881ab4edffa5e9c6c8bd8fb9762e04d776c4a573 https://fedorahosted.org/freeipa/changeset/0d7d6f3904287bb4903ffaa9d8c61e7593ae76d6 https://fedorahosted.org/freeipa/changeset/1f1648691de6687e748c5b8267f43cf196bd7cc9 https://fedorahosted.org/freeipa/changeset/fd3176a72951a2baece36620341991feb94b230a https://fedorahosted.org/freeipa/changeset/b12da59a6cde3580f97e4ceb7303bc85857faf4d https://fedorahosted.org/freeipa/changeset/1e0143c159134337a00a91d4ae64e614f72da62e https://fedorahosted.org/freeipa/changeset/8acb1f37f581e92a56951c069c990c77e83f3c42 https://fedorahosted.org/freeipa/changeset/c8be979b3263723a9ab7b3c71efbe85b42d981e9 https://fedorahosted.org/freeipa/changeset/1a4f287931edf0f3a76e97875f4af622716475af https://fedorahosted.org/freeipa/changeset/38628e46f05bde5ccc0fbb997f79364860713b48 https://fedorahosted.org/freeipa/changeset/f25c0cb0c5f309944904fd32e781c27ae7e45a62 https://fedorahosted.org/freeipa/changeset/c954d0e1ba2a9ba8e8da679bc7246788d086d976 https://fedorahosted.org/freeipa/changeset/c70a2873f8a4447f8b38ad7b8468fc78c91bbb63 https://fedorahosted.org/freeipa/changeset/3e79d8ad4aef1f62372a2169699df345348ba3e9 """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-255715699 From freeipa-github-notification at redhat.com Mon Oct 24 11:48:32 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 24 Oct 2016 13:48:32 +0200 Subject: [Freeipa-devel] [freeipa PR#159][synchronized] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-159.patch Type: text/x-diff Size: 40606 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 11:53:03 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 24 Oct 2016 13:53:03 +0200 Subject: [Freeipa-devel] [freeipa PR#181][synchronized] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Author: gkaihorodova Title: #181: Tests : User Tracker creation of user with minimal values Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/181/head:pr181 git checkout pr181 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-181.patch Type: text/x-diff Size: 2126 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 12:03:36 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Mon, 24 Oct 2016 14:03:36 +0200 Subject: [Freeipa-devel] [freeipa PR#159][+ack] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires Label: +ack From freeipa-github-notification at redhat.com Mon Oct 24 12:11:32 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 24 Oct 2016 14:11:32 +0200 Subject: [Freeipa-devel] [freeipa PR#159][comment] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires dkupka commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/21395d1724e6bf044438a8bc25ba028ed38cde8c https://fedorahosted.org/freeipa/changeset/1077743d90902fc776f837f8486fa7f08b560673 https://fedorahosted.org/freeipa/changeset/0d370a959b6b55f995661b2febe55c379065c4d9 https://fedorahosted.org/freeipa/changeset/0b91735c79a0ba577f9540e946180760a97913a4 https://fedorahosted.org/freeipa/changeset/9b534238157e003d2d7c3e1a7fd27531ab1dfd25 https://fedorahosted.org/freeipa/changeset/9477e39b4b267922dbdd86a65869f773d980df8e https://fedorahosted.org/freeipa/changeset/cc5ad6b3f951a6cb8298181690248d680c39922b """ See the full comment at https://github.com/freeipa/freeipa/pull/159#issuecomment-255723135 From freeipa-github-notification at redhat.com Mon Oct 24 12:11:33 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 24 Oct 2016 14:11:33 +0200 Subject: [Freeipa-devel] [freeipa PR#159][closed] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Author: jcholast Title: #159: spec file: clean up BuildRequires Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/159/head:pr159 git checkout pr159 From freeipa-github-notification at redhat.com Mon Oct 24 12:11:35 2016 From: freeipa-github-notification at redhat.com (dkupka) Date: Mon, 24 Oct 2016 14:11:35 +0200 Subject: [Freeipa-devel] [freeipa PR#159][+pushed] spec file: clean up BuildRequires In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/159 Title: #159: spec file: clean up BuildRequires Label: +pushed From freeipa-github-notification at redhat.com Mon Oct 24 12:58:09 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 24 Oct 2016 14:58:09 +0200 Subject: [Freeipa-devel] [freeipa PR#182][opened] Use env var IPA_CONFDIR to get confdir for 'cli' context Message-ID: URL: https://github.com/freeipa/freeipa/pull/182 Author: tiran Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context Action: opened PR body: """ For 'cli' contexts, the environment variable IPA_CONFDIR overrides the default confdir path. The value of the environment variable must be an absolute path to an existing directory. The new variable simplifies local configuration. Server and installer contexts do not use it. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/182/head:pr182 git checkout pr182 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-182.patch Type: text/x-diff Size: 2003 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 12:59:05 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 24 Oct 2016 14:59:05 +0200 Subject: [Freeipa-devel] [freeipa PR#183][opened] Add __name__ == __main__ guards to setup.pys Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Author: tiran Title: #183: Add __name__ == __main__ guards to setup.pys Action: opened PR body: """ Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/183/head:pr183 git checkout pr183 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-183.patch Type: text/x-diff Size: 9401 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 13:49:46 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Mon, 24 Oct 2016 15:49:46 +0200 Subject: [Freeipa-devel] [freeipa PR#183][comment] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Title: #183: Add __name__ == __main__ guards to setup.pys mirielka commented: """ Thanks, this fixes setup.py related failure in intree tests. """ See the full comment at https://github.com/freeipa/freeipa/pull/183#issuecomment-255745533 From freeipa-github-notification at redhat.com Mon Oct 24 14:37:48 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 24 Oct 2016 16:37:48 +0200 Subject: [Freeipa-devel] [freeipa PR#182][comment] Use env var IPA_CONFDIR to get confdir for 'cli' context In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/182 Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context jcholast commented: """ This seems rather unnecessary to me, as you can do: ``` $ ipa -e confdir=/path/to/confdir command ``` In case there is some shortcoming in the above, I would expect to see it described in the commit message. """ See the full comment at https://github.com/freeipa/freeipa/pull/182#issuecomment-255758670 From freeipa-github-notification at redhat.com Mon Oct 24 14:41:59 2016 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 24 Oct 2016 16:41:59 +0200 Subject: [Freeipa-devel] [freeipa PR#184][opened] Minor install script fixes Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Author: simo5 Title: #184: Minor install script fixes Action: opened PR body: """ - Use the correct unicode string for an error message, otherwise an exception will generate another exception about incorrect type, masking the original error. - Make sure to pass down the debug flag to ipa-client-install when the server install is run in debug mode """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/184/head:pr184 git checkout pr184 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-184.patch Type: text/x-diff Size: 1775 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 14:43:31 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 24 Oct 2016 16:43:31 +0200 Subject: [Freeipa-devel] [freeipa PR#181][synchronized] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Author: gkaihorodova Title: #181: Tests : User Tracker creation of user with minimal values Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/181/head:pr181 git checkout pr181 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-181.patch Type: text/x-diff Size: 2116 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 24 15:21:52 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Mon, 24 Oct 2016 17:21:52 +0200 Subject: [Freeipa-devel] [freeipa PR#183][comment] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Title: #183: Add __name__ == __main__ guards to setup.pys pspacek commented: """ @tiran PEP8 errors need to be fixed first: ~~~ ./ipaclient/setup.py:28:80: E501 line too long (80 > 79 characters) ./ipalib/setup.py:28:80: E501 line too long (80 > 79 characters) ./ipaplatform/setup.py:28:80: E501 line too long (80 > 79 characters) ./ipaserver/setup.py:30:80: E501 line too long (80 > 79 characters) ./ipatests/setup.py:29:80: E501 line too long (80 > 79 characters) ~~~ Other than that, functional ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/183#issuecomment-255772205 From freeipa-github-notification at redhat.com Mon Oct 24 15:38:09 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Mon, 24 Oct 2016 17:38:09 +0200 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes abbra commented: """ ACK from my side if you would split the commit into two small ones, please. Note that CI integration is currently broken so travis says your commits failed the checks. """ See the full comment at https://github.com/freeipa/freeipa/pull/184#issuecomment-255777099 From freeipa-github-notification at redhat.com Mon Oct 24 17:08:15 2016 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 24 Oct 2016 19:08:15 +0200 Subject: [Freeipa-devel] [freeipa PR#184][synchronized] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Author: simo5 Title: #184: Minor install script fixes Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/184/head:pr184 git checkout pr184 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-184.patch Type: text/x-diff Size: 2035 bytes Desc: not available URL: From simo at redhat.com Mon Oct 24 17:36:46 2016 From: simo at redhat.com (Simo Sorce) Date: Mon, 24 Oct 2016 13:36:46 -0400 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: <1477330606.18284.10.camel@redhat.com> On Mon, 2016-10-24 at 17:38 +0200, abbra wrote: > URL: https://github.com/freeipa/freeipa/pull/184 > Title: #184: Minor install script fixes > > abbra commented: > """ > ACK from my side if you would split the commit into two small ones, please. > > Note that CI integration is currently broken so travis says your commits failed the checks. > """ Done, and the CI seem happy ? Simo. -- Simo Sorce * Red Hat, Inc * New York From freeipa-github-notification at redhat.com Mon Oct 24 17:59:20 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Mon, 24 Oct 2016 19:59:20 +0200 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes abbra commented: """ ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/184#issuecomment-255816653 From freeipa-github-notification at redhat.com Mon Oct 24 17:59:23 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Mon, 24 Oct 2016 19:59:23 +0200 Subject: [Freeipa-devel] [freeipa PR#184][+ack] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes Label: +ack From abokovoy at redhat.com Mon Oct 24 17:59:57 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Oct 2016 20:59:57 +0300 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: <1477330606.18284.10.camel@redhat.com> References: <1477330606.18284.10.camel@redhat.com> Message-ID: <20161024175956.umzf72s22wb6ywnb@redhat.com> On ma, 24 loka 2016, Simo Sorce wrote: >On Mon, 2016-10-24 at 17:38 +0200, abbra wrote: >> URL: https://github.com/freeipa/freeipa/pull/184 >> Title: #184: Minor install script fixes >> >> abbra commented: >> """ >> ACK from my side if you would split the commit into two small ones, please. >> >> Note that CI integration is currently broken so travis says your commits failed the checks. >> """ > >Done, and the CI seem happy ? Yes, thank you. I acked the request. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Tue Oct 25 03:37:49 2016 From: freeipa-github-notification at redhat.com (shanyin) Date: Tue, 25 Oct 2016 05:37:49 +0200 Subject: [Freeipa-devel] [freeipa PR#174][comment] add log module In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/174 Title: #174: add log module shanyin commented: """ I'm sorry didn't reply your message in time. - I will set up centralized logging environment later. - Because my environment is Ubuntu, currently the latest freeIPA version is 4.3.x, so I can only verify the log module on this version. - There is no restriction in code. What I mean is to control file attributes in the script after installation. - I will be familiar with using topological features later. I have got the reply of the translation organization, but still in the stage of authentication. I will try to see if there is a permission to translate on freeIPA after certification. Thank you. """ See the full comment at https://github.com/freeipa/freeipa/pull/174#issuecomment-255927710 From freeipa-github-notification at redhat.com Tue Oct 25 06:48:55 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Tue, 25 Oct 2016 08:48:55 +0200 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values mirielka commented: """ The same minimal values apply for stageuser-add command, can you please modify the stageuser tracker as well? Also adding testcases for these changes would be nice. """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-255951439 From ofayans at redhat.com Tue Oct 25 08:24:25 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 25 Oct 2016 10:24:25 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: <1d744d16-75de-2bdc-5892-b3c36a305581@redhat.com> References: <57A07FE4.8000904@redhat.com> <2b0ed7fe-f0bc-7137-bdc1-b0758ffe9cd6@redhat.com> <20160914154119.mkk2ma7tvks55xsu@redhat.com> <97eaa313-e889-cd4a-e900-9e88596577a0@redhat.com> <20160914155320.iowrijrq3z62evoo@redhat.com> <1af52e6c-c24b-d58b-ccf5-a85c5c290e0c@redhat.com> <20160914165348.GE2761@p.Speedport_W_724V_Typ_A_05011603_00_009> <59763ea7-2ab5-bdc2-72c1-489a462f78ef@redhat.com> <6089c103-ab56-62f7-971c-a41710eee22f@redhat.com> <1d744d16-75de-2bdc-5892-b3c36a305581@redhat.com> Message-ID: <39a8af61-056b-df40-9126-50997a5b54c8@redhat.com> Integration part of the tests is ready. 2 tests: 1. Adds a cert to idoverride of a windows user 2. sssd part - looks up user by his certificate using dbus-sssd Second and third dbus call are executed as a string insted of as array of strings because it just does not work otherwise. Some quote escaping gets screwed probably, but the system returns "Error org.freedesktop.DBus.Error.UnknownInterface: Unknown interface" if the command is executed using the standard array-based approach The run looks like this: bash-4.3$ ipa-run-tests test_integration/test_idviews.py --pdb WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] Permission denied: 'lextab.py' WARNING: yacc table file version is out of date WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission denied: 'yacctab.py' ==================================== test session starts ==================================== platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini plugins: sourceorder-0.5, multihost-1.0 collected 2 items test_integration/test_idviews.py .. ================================ 2 passed in 948.44 seconds ================================= On 10/21/2016 10:54 AM, Oleg Fayans wrote: > Added one more test, resolved the pep8 issues > > On 10/19/2016 12:32 PM, Oleg Fayans wrote: >> Hi Martin, >> >> As you suggested, I've extended the >> test_xmlrpc/test_add_remove_cert_cmd.py to contain basic tests for certs >> in idoverrides. >> The integration part still needs some polishing in the part related to >> user lookup by cert >> >> On 10/14/2016 03:57 PM, Martin Babinsky wrote: >>> On 10/14/2016 03:48 PM, Oleg Fayans wrote: >>>> So, did I understand correctly, that there would be 2 patches: one >>>> containing test for basic idoverrides functionality without >>>> AD-integration, and the second one - with AD-integration and an sssd >>>> check, correct? >>>> I guess, the >>>> freeipa-ofayans-0050.1-Automated-test-for-certs-in-idoverrides-feature.patch >>>> >>>> >>>> >>>> might be a good candidate for the first one, I only have to change the >>>> filename to test_idviews.py, right? >>>> >>> >>> Oleg, we already have XMLRPC tests for idoverrides: >>> >>> ipatests/test_xmlrpc/test_idviews_plugin.py >>> >>> Is there any particular reason why not to extend them with add >>> cert/remove cert operations? >>> >>> Even better, you can extend >>> `ipatests/test_xmlrpc/test_add_remove_cert_cmd.py` suite by doing the >>> same set of tests on idoverrideuser objects. >>> >>> Or am I missing something? >>> >>>> On 09/15/2016 10:32 AM, Martin Basti wrote: >>>>> >>>>> >>>>> On 15.09.2016 10:10, Oleg Fayans wrote: >>>>>> Hi Martin, >>>>>> >>>>>> The file was renamed. Did I understand correctly that for now we are >>>>>> leaving the test as is and are planning to extend it later? >>>>> >>>>> I would like to have there SSSD check involved, please use what Summit >>>>> recommends. No new test cases. >>>>> >>>>> And this can be done by separate patch, I want to have API/CLI >>>>> certificate override tests for non-AD idview (extending current >>>>> tests I >>>>> posted in this thread) >>>>> >>>>> Martin^2 >>>>>> >>>>>> On 09/15/2016 09:49 AM, Martin Basti wrote: >>>>>>> >>>>>>> >>>>>>> On 14.09.2016 18:53, Sumit Bose wrote: >>>>>>>> On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote: >>>>>>>>> >>>>>>>>> On 14.09.2016 17:53, Alexander Bokovoy wrote: >>>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>>> >>>>>>>>>>> On 14.09.2016 17:41, Alexander Bokovoy wrote: >>>>>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>>>>> 1) >>>>>>>>>>>>> I still don't see the reason why AD trust is needed. Default >>>>>>>>>>>>> trust ID view is added just by ipa-adtrust-install, adding >>>>>>>>>>>>> trust is not needed for current implementation. You don't >>>>>>>>>>>>> need AD for this, IDviews is generic feature not just for >>>>>>>>>>>>> AD. Is that user configured on AD side? >>>>>>>>>>>> You cannot add non-AD user to 'default trust view', so you will >>>>>>>>>>>> not be >>>>>>>>>>>> able to set up certificates to ID override which does not >>>>>>>>>>>> exist. >>>>>>>>>>>> >>>>>>>>>>>> For non-'default trust view' you can add both IPA and AD users, >>>>>>>>>>>> so using >>>>>>>>>>>> some other view and then assign certificate for a ID >>>>>>>>>>>> override in >>>>>>>>>>>> that >>>>>>>>>>>> one. >>>>>>>>>>>> >>>>>>>>>>> Ok then, but anyway I would like to see API/CLI tests for this >>>>>>>>>>> feature with proper output validation. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> How can be this tested with SSSD? >>>>>>>>>> You need to log into the system with a certificate... >>>>>>>>> Is this possible from test? We are logged remotely as root, is >>>>>>>>> there any >>>>>>>>> cmdline util which allows us to test certificate against AD user? >>>>>>>> >>>>>>>> You can use 'sss_ssh_authorizedkeys aduser at ad.domain' which should >>>>>>>> return the ssh key derived from the public key in the certificate. >>>>>>>> This >>>>>>>> should work for certificate stored in AD as well as for overrides. >>>>>>>> >>>>>>>> You can also you the DBus lookup by certificate as described in >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> HTH >>>>>>>> >>>>>>>> bye, >>>>>>>> Sumit >>>>>>> >>>>>>> Thank you Alexander and Summit for hints. >>>>>>> >>>>>>> Oleg I realized we don't have any other idviews integration tests >>>>>>> >>>>>>> So I propose to rename test file you are adding to >>>>>>> test_idviews.py. We >>>>>>> can add more testcases for idviews there later >>>>>>> >>>>>>> Martin^2 >>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0049.2-Added-interface-to-certutil.patch Type: text/x-patch Size: 1165 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0050.6-Automated-test-for-certs-in-idoverrides-feature.patch Type: text/x-patch Size: 7931 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 25 08:33:07 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 25 Oct 2016 10:33:07 +0200 Subject: [Freeipa-devel] [freeipa PR#183][synchronized] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Author: tiran Title: #183: Add __name__ == __main__ guards to setup.pys Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/183/head:pr183 git checkout pr183 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-183.patch Type: text/x-diff Size: 10148 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 25 08:44:36 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 25 Oct 2016 10:44:36 +0200 Subject: [Freeipa-devel] [freeipa PR#182][synchronized] Use env var IPA_CONFDIR to get confdir for 'cli' context In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/182 Author: tiran Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/182/head:pr182 git checkout pr182 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-182.patch Type: text/x-diff Size: 2166 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 25 08:44:48 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 25 Oct 2016 10:44:48 +0200 Subject: [Freeipa-devel] [freeipa PR#183][comment] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Title: #183: Add __name__ == __main__ guards to setup.pys tiran commented: """ @pspacek Fixed """ See the full comment at https://github.com/freeipa/freeipa/pull/183#issuecomment-255974686 From freeipa-github-notification at redhat.com Tue Oct 25 08:45:47 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 25 Oct 2016 10:45:47 +0200 Subject: [Freeipa-devel] [freeipa PR#182][comment] Use env var IPA_CONFDIR to get confdir for 'cli' context In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/182 Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context tiran commented: """ It's explained in the title. The ```-e confdir=/path/to/confdir``` only works for ipa command. The env var affects all ```cli``` contexts including custom Python script that use ipalib and ipaclient libs directly. Also it is much easier to set an env var in a shell session than to add a lengthy argument to every call of the ```ipa``` command. """ See the full comment at https://github.com/freeipa/freeipa/pull/182#issuecomment-255974930 From freeipa-github-notification at redhat.com Tue Oct 25 08:48:12 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 25 Oct 2016 10:48:12 +0200 Subject: [Freeipa-devel] [freeipa PR#182][synchronized] Use env var IPA_CONFDIR to get confdir for 'cli' context In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/182 Author: tiran Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/182/head:pr182 git checkout pr182 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-182.patch Type: text/x-diff Size: 2166 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 25 08:54:32 2016 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Tue, 25 Oct 2016 10:54:32 +0200 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values gkaihorodova commented: """ Yes, It's a valid point to add testcases for these changes . Will do. Thank you. """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-255976850 From freeipa-github-notification at redhat.com Tue Oct 25 09:03:47 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 25 Oct 2016 11:03:47 +0200 Subject: [Freeipa-devel] [freeipa PR#180][comment] Make api.env.nss_dir relative to api.env.confdir In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/180 Title: #180: Make api.env.nss_dir relative to api.env.confdir tiran commented: """ The improvement depends on PR #143. """ See the full comment at https://github.com/freeipa/freeipa/pull/180#issuecomment-255978976 From ofayans at redhat.com Tue Oct 25 09:29:45 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Tue, 25 Oct 2016 11:29:45 +0200 Subject: [Freeipa-devel] [test][patch-0057] test for ticket N 6146 (installing rules with service principals) In-Reply-To: <57AB1418.60903@redhat.com> References: <57AAE7EA.5090604@redhat.com> <745bf2dc-18d4-9f89-b97c-980b447f2823@redhat.com> <57AB1418.60903@redhat.com> Message-ID: <7d137bdf-883c-2ef9-468d-f8b7de358804@redhat.com> The patch was rebased to be able to apply on top of latest version of certs in idoverrides patch. As before, it requires patches NN 0049 and 0059 to apply On 08/10/2016 01:46 PM, Oleg Fayans wrote: > Hi Martin, > > I am sorry, yes it depends on my patches 0049 and 0050. > > > On 08/10/2016 12:27 PM, Martin Basti wrote: >> >> >> On 10.08.2016 10:38, Oleg Fayans wrote: >>> >>> >>> >> Hello, >> >> I cannot apply this patch >> error: ipatests/test_integration/test_certs_in_idoverrides.py: does not >> exist in index >> It probably depends on another patch (which one?) >> >> Please, use human readable subjects in email, I do not remember from top >> of my head what #6146 is. >> >> Martin^2 >> >> > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ofayans-0057.1-Test-for-installing-rules-with-service-principals.patch Type: text/x-patch Size: 3997 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 25 09:36:24 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Tue, 25 Oct 2016 11:36:24 +0200 Subject: [Freeipa-devel] [freeipa PR#182][comment] Use env var IPA_CONFDIR to get confdir for 'cli' context In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/182 Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context jcholast commented: """ In custom Python scripts, you have to call `api.bootstrap()`, so you may as well call `api.bootstrap(confdir='/path/to/confdir')`. You may even call `api.bootstrap(confdir=os.environ['IPA_CONFDIR'])`, so this PR is not necessary for custom scripts at all. Instead of setting an env var, you can create an alias for `ipa -e confdir=/path/to/confdir`, which is equally easy. """ See the full comment at https://github.com/freeipa/freeipa/pull/182#issuecomment-255986281 From mbabinsk at redhat.com Tue Oct 25 11:21:03 2016 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 25 Oct 2016 13:21:03 +0200 Subject: [Freeipa-devel] tomcat-8.0.37-3.fc24.noarch package from updates testing breaks CA instance spawn Message-ID: An update for Apache Tmocat recently pushed into bodhi[1] seems to break CA instance spawning in a spectacular way.[2] It seems that the update once again breaks the loading of Java classes during Dogtag server initialization. I gave the package negative karma and I suggest for you to do the same until the issue is resolved. As a workaround you can either disable updates-testing or use: """ dnf downgrade --allowerasing tomcat """ to downgrade tomcat and dependencies to version 8.0.36-2.fc24 which works. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2016-c1b01b9278 [2] https://paste.fedoraproject.org/460589/77394029 -- Martin^3 Babinsky From freeipa-github-notification at redhat.com Tue Oct 25 12:01:20 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 14:01:20 +0200 Subject: [Freeipa-devel] [freeipa PR#184][closed] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Author: simo5 Title: #184: Minor install script fixes Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/184/head:pr184 git checkout pr184 From freeipa-github-notification at redhat.com Tue Oct 25 12:01:23 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 14:01:23 +0200 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/2f567f0e8eb53306c5a3ecc04ac93e375b9c07d1 https://fedorahosted.org/freeipa/changeset/d650c54fe4e327f95ffcb834418a5b6af59b212c """ See the full comment at https://github.com/freeipa/freeipa/pull/184#issuecomment-256015527 From freeipa-github-notification at redhat.com Tue Oct 25 12:01:24 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 14:01:24 +0200 Subject: [Freeipa-devel] [freeipa PR#184][+pushed] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes Label: +pushed From abokovoy at redhat.com Tue Oct 25 12:06:15 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 25 Oct 2016 15:06:15 +0300 Subject: [Freeipa-devel] tomcat-8.0.37-3.fc24.noarch package from updates testing breaks CA instance spawn In-Reply-To: References: Message-ID: <20161025120615.yhroolasfdqb27qb@redhat.com> On ti, 25 loka 2016, Martin Babinsky wrote: >An update for Apache Tmocat recently pushed into bodhi[1] seems to >break CA instance spawning in a spectacular way.[2] It seems that the >update once again breaks the loading of Java classes during Dogtag >server initialization. > >I gave the package negative karma and I suggest for you to do the same >until the issue is resolved. > >As a workaround you can either disable updates-testing or use: > >""" >dnf downgrade --allowerasing tomcat >""" > >to downgrade tomcat and dependencies to version 8.0.36-2.fc24 which works. > >[1] https://bodhi.fedoraproject.org/updates/FEDORA-2016-c1b01b9278 >[2] https://paste.fedoraproject.org/460589/77394029 Thank you Martin. I've found the corresponding Apache bugzilla entry: https://bz.apache.org/bugzilla/show_bug.cgi?id=60101 Tomcat needs to be rebased to 8.0.38 to work. I just broke my test install ;) -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Tue Oct 25 12:09:25 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 14:09:25 +0200 Subject: [Freeipa-devel] [freeipa PR#148][+pushed] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 25 12:09:26 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 14:09:26 +0200 Subject: [Freeipa-devel] [freeipa PR#148][comment] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Title: #148: Unaccessible variable self.attrs in Tracker mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/9b0b97073304ba6bfdd6292b07533ab3e7fe8bcb """ See the full comment at https://github.com/freeipa/freeipa/pull/148#issuecomment-256016975 From freeipa-github-notification at redhat.com Tue Oct 25 12:09:28 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 14:09:28 +0200 Subject: [Freeipa-devel] [freeipa PR#148][closed] Unaccessible variable self.attrs in Tracker In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/148 Author: gkaihorodova Title: #148: Unaccessible variable self.attrs in Tracker Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/148/head:pr148 git checkout pr148 From freeipa-github-notification at redhat.com Tue Oct 25 14:48:29 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 25 Oct 2016 16:48:29 +0200 Subject: [Freeipa-devel] [freeipa PR#182][comment] Use env var IPA_CONFDIR to get confdir for 'cli' context In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/182 Title: #182: Use env var IPA_CONFDIR to get confdir for 'cli' context tiran commented: """ Your proposals are hacks / workarounds, not a proper API to point ipa/ipalib to a custom configuration location. I'm proposing a proper API for integrators that works similar to ```KRB5_CONFIG``` (https://web.mit.edu/kerberos/krb5-1.14/doc/admin/env_variables.html). The PR is part of a larger effort to simplify integration of ipalib and ipa CLI into Ansible and other systems. Such integration needs to set ```KRB5_CONFIG``` anyway. It makes perfectly sense to have ```IPA_CONFDIR```, too. It's not ```IPA_CONFIG``` because a local enrolment needs ```ca.crt``` and ```nssdb```. """ See the full comment at https://github.com/freeipa/freeipa/pull/182#issuecomment-256056130 From freeipa-github-notification at redhat.com Tue Oct 25 15:03:25 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Tue, 25 Oct 2016 17:03:25 +0200 Subject: [Freeipa-devel] [freeipa PR#139][synchronized] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Author: pvomacka Title: #139: WebUI: Vault Management Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/139/head:pr139 git checkout pr139 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-139.patch Type: text/x-diff Size: 69637 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 25 15:07:37 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Tue, 25 Oct 2016 17:07:37 +0200 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management pvomacka commented: """ @mbasti-rh 2) fixed 3) I filled a ticket: https://fedorahosted.org/freeipa/ticket/6388 4) Tests added 5) Fixed 6) Fixed 7) Salt added 8) Field for public key added 9) Warning added 10) Transport certificate is now visible in WebUI 11) Information added into adder dialog The issue with showing error in case that KRA is not installed is also fixed. """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-256062716 From freeipa-github-notification at redhat.com Tue Oct 25 15:17:15 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Tue, 25 Oct 2016 17:17:15 +0200 Subject: [Freeipa-devel] [freeipa PR#185][opened] TESTS: Update group type name Message-ID: URL: https://github.com/freeipa/freeipa/pull/185 Author: pvomacka Title: #185: TESTS: Update group type name Action: opened PR body: """ As the group type has been changed from 'normal' to 'nonposix' we need to update this information also in tests. https://fedorahosted.org/freeipa/ticket/6334 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/185/head:pr185 git checkout pr185 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-185.patch Type: text/x-diff Size: 934 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Oct 25 15:48:26 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 17:48:26 +0200 Subject: [Freeipa-devel] [freeipa PR#183][+ack] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Title: #183: Add __name__ == __main__ guards to setup.pys Label: +ack From freeipa-github-notification at redhat.com Tue Oct 25 16:11:50 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 18:11:50 +0200 Subject: [Freeipa-devel] [freeipa PR#183][+pushed] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Title: #183: Add __name__ == __main__ guards to setup.pys Label: +pushed From freeipa-github-notification at redhat.com Tue Oct 25 16:11:52 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 18:11:52 +0200 Subject: [Freeipa-devel] [freeipa PR#183][comment] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Title: #183: Add __name__ == __main__ guards to setup.pys mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/91920e7cb48cbf143ae281c9c073df14b2c2dddf """ See the full comment at https://github.com/freeipa/freeipa/pull/183#issuecomment-256082320 From freeipa-github-notification at redhat.com Tue Oct 25 16:11:53 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 18:11:53 +0200 Subject: [Freeipa-devel] [freeipa PR#183][closed] Add __name__ == __main__ guards to setup.pys In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/183 Author: tiran Title: #183: Add __name__ == __main__ guards to setup.pys Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/183/head:pr183 git checkout pr183 From freeipa-github-notification at redhat.com Tue Oct 25 16:33:49 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 25 Oct 2016 18:33:49 +0200 Subject: [Freeipa-devel] [freeipa PR#145][comment] Refactoring: LDAP Connection Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/145 Title: #145: Refactoring: LDAP Connection Management mbasti-rh commented: """ @rcritten Tomas removed timelimit that was used for repeated connections, it is not used for preventing hangs. (If we talk about the same commit 'ldap refactoring: remove wait/timeout during binds') We added this functionality to DS restart, restart will block code until DS is not ready on LDAPI port. @tomaskrizek I put two inline comments there, otherwise changes make sense. I'll wait for tests results """ See the full comment at https://github.com/freeipa/freeipa/pull/145#issuecomment-256088359 From freeipa-github-notification at redhat.com Tue Oct 25 18:19:50 2016 From: freeipa-github-notification at redhat.com (lslebodn) Date: Tue, 25 Oct 2016 20:19:50 +0200 Subject: [Freeipa-devel] [freeipa PR#171][comment] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Title: #171: Build system cleanup phase 2 lslebodn commented: """ On (20/10/16 10:29), Petr ?pa?ek wrote: >@lslebodn I'm really trying to explain this but I'm still not able to get the point across. >> My concerns are related purely to C-code. > >Please understand that IPA client consists of components in C as well from components in Python, and also non-programatic components like translation machinery etc. > Correct me If I am wrong. The configure script is and will be used just for detection of build dependencies for C-code. So here I cannot see a conflict with my proposal. >We certainly can create m4 include maze I cannot see a reason why it would be a maze Detection of client build dependencies will be done in main configure.ac Detection of server dependencies would be done in `daemons/configure.ac` `./ipatests/man/configure.ac` and `./install/configure.ac` does not have any C-related dependencies and `./asn1/configure.ac` is required by client code. IMHO ans1c/ can be moved to client/asn1c/ (but that's offtopic) There would not be much includes as I showed in POC >and force maintainer to always use `grep` before he finds particular part in the build system. maintainers do not use grep for finding build dependencies. The most common use case is just to run configure script and wait for reported errors. pkg-config returns nice error messages. And then add new build dependency. However, C related code is not changed very often and even more C-related dependencies are added much less often. But if new depenendecy will be added to server part then it will be much simpler to review whether build dependency is added to the right section if server dependencies will be in separate file. >Unfortunatlly, even the m4 maze will not solve the problem that client-only >build of C binaries simply do not constitute working IPA client. >Integration with other Python components is necessary to get the client to work. > Totally agree. But python components is not related to checking of build time dependencies for C-code. It should be solved in different PR IMHO, this PR should not complicate client-only build just for C-binaries. >The end goal is to fold all of hand-made Makefile and SPEC file scripts to the build system, so in the end, it should help with porting to other arches - there will be just one place where changes need to be done, instead of three. > Agree, but here I cannot see any conflict with my proposal. >I hope that it clears up why it is not useful to insist on keeping current pieces as they were before. The design document was sent to freeipa-devel mailing list in this thread: >https://www.redhat.com/archives/freeipa-devel/2016-October/msg00134.html >Please discuss conceptual questions on the mailing list so we can get attention of other FreeIPA developers and avoid need to point people one by one to this PR. > I read the desing page and there is mentioned that autotools will be used for C-part as an implementation and configure script should have the option --enable-server which default yes. I could not find any contradiction between my proposal and desing page. LS """ See the full comment at https://github.com/freeipa/freeipa/pull/171#issuecomment-256120734 From freeipa-github-notification at redhat.com Tue Oct 25 20:26:21 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Tue, 25 Oct 2016 22:26:21 +0200 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes pvoborni commented: """ The debug patch breaks test installation on RHEL. Following exception is printed only if install.py is adjusted to print exception on line ``` ipa : ERROR debug Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/server/install.py", line 899, in install if options.debug: File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 550, in __getattr__ raise AttributeError(name) AttributeError: debug ``` I.e. there is no Knob debug nor verbose unless it is somehow copied. I don't know why it doesn't break install on Fedora but imho the patch cannot work. This might also be the "there is no ipa-client-install.log" issue. Because it fails just before calling ipa-client-install. """ See the full comment at https://github.com/freeipa/freeipa/pull/184#issuecomment-256165308 From freeipa-github-notification at redhat.com Wed Oct 26 07:06:07 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 26 Oct 2016 09:06:07 +0200 Subject: [Freeipa-devel] [freeipa PR#139][synchronized] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Author: pvomacka Title: #139: WebUI: Vault Management Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/139/head:pr139 git checkout pr139 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-139.patch Type: text/x-diff Size: 69753 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 07:34:09 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 26 Oct 2016 09:34:09 +0200 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management pvomacka commented: """ Fixed PEP8 errors. """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-256271405 From mbasti at redhat.com Wed Oct 26 07:51:09 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Oct 2016 09:51:09 +0200 Subject: [Freeipa-devel] [PATCH] restrict setkeytab operation In-Reply-To: <801215e7-666d-4b1f-bbed-031d0b0b6c42@redhat.com> References: <1469450405.18067.69.camel@redhat.com> <57962868.8090904@redhat.com> <1469458890.18067.72.camel@redhat.com> <57962BE5.60404@redhat.com> <1469460374.18067.79.camel@redhat.com> <1469533105.18067.89.camel@redhat.com> <801215e7-666d-4b1f-bbed-031d0b0b6c42@redhat.com> Message-ID: <8952c0f6-b421-3937-f9b7-dbd3e9a82c70@redhat.com> On 31.08.2016 14:36, Martin Basti wrote: > > > > On 26.07.2016 13:38, Simo Sorce wrote: >> On Mon, 2016-07-25 at 11:26 -0400, Simo Sorce wrote: >>> On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote: >>>>>> Simo Sorce wrote: >>>>>>> As described in #232 start restricting the use of the setkeytab >>>>>>> operation to just the computers objects. >>>>>>> >>>>>>> I haven't tested this with older RHEL/CentOS machines that actully use >>>>>>> the setkeytab operation as I do not have such an old VM handy right now. >>>>>>> >>>>>>> Meanwhile I'd like to know if ppl agree with this approach. >>>>>> What about services? >>>>> Do we automatically acquire keytab for services in the old clients ? >>>>> >>>>> Are you thinking about scripted ipa-getkytab callouts ? >>>> You are limiting access to host keytabs, what about service keytabs? >>>> Should they be or are they now similarly restricted? >>>> >>>> Installers for something like Foreman may try to generate a service >>>> keytab in its installer, probably using admin credentials. I am planning >>>> to do the same in Openstack. >>> Ok I'll amend the patch to allow service keytabs to still use the >>> setkeytab control still, and restrict only users. >>> However note that the idea of using this method is that admin can change >>> this default on their own, so they can restrict more or less if they >>> want, to that end I need to remember how to set a default that we do not >>> override in the update file. >>> >>> Simo. >>> >> Amended patch to allow services too. >> Only users are excluded. >> >> Simo. >> >> >> > > bump for review > > bump for review -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 26 07:53:13 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Oct 2016 09:53:13 +0200 Subject: [Freeipa-devel] [PATCH] 956 replicainstall: log ACI and LDAP errors in promotion check In-Reply-To: <56FB891E.5080405@redhat.com> References: <56F3F969.3050506@redhat.com> <56FB891E.5080405@redhat.com> Message-ID: On 30.03.2016 10:06, Martin Basti wrote: > > > On 24.03.2016 15:27, Petr Vobornik wrote: >> to enable debugging of such errors. >> >> E.g.: https://fedorahosted.org/freeipa/ticket/5741 >> >> > Can we log the whole traceback to get exact place where error happened? > > Martin^2 > > bump -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 26 07:54:32 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Oct 2016 09:54:32 +0200 Subject: [Freeipa-devel] [PATCH] webui: 0084, 0101: refactoring rpc module In-Reply-To: References: Message-ID: <6bd5f02a-e4d1-cb55-84ce-03db8f01755f@redhat.com> On 09.08.2016 13:29, Pavel Vomacka wrote: > Hello, > > please review attached patches. > > The rpc module is now separated from display layer > and changing activity text while loading metadata. > > https://fedorahosted.org/freeipa/ticket/6144 > > > bump for review -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Wed Oct 26 07:55:33 2016 From: mbasti at redhat.com (Martin Basti) Date: Wed, 26 Oct 2016 09:55:33 +0200 Subject: [Freeipa-devel] [PATCH] 0102-0104: webui: Add support for setting custom table pagination size In-Reply-To: <4f758e21-b951-9ca6-e685-29746c1cec44@redhat.com> References: <4f758e21-b951-9ca6-e685-29746c1cec44@redhat.com> Message-ID: <41469ae1-68e8-2329-7e4f-90f9482080d2@redhat.com> On 11.08.2016 16:18, Pavel Vomacka wrote: > Hello, > > please review attached patches. > > https://fedorahosted.org/freeipa/ticket/5742 > > > bump for review -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Oct 26 08:50:25 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Wed, 26 Oct 2016 10:50:25 +0200 Subject: [Freeipa-devel] [freeipa PR#186][opened] replicainstall: log ACI and LDAP errors in promotion check Message-ID: URL: https://github.com/freeipa/freeipa/pull/186 Author: pvoborni Title: #186: replicainstall: log ACI and LDAP errors in promotion check Action: opened PR body: """ to enable debugging of such errors. E.g.: https://fedorahosted.org/freeipa/ticket/5741 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/186/head:pr186 git checkout pr186 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-186.patch Type: text/x-diff Size: 1218 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 26 08:50:51 2016 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Oct 2016 10:50:51 +0200 Subject: [Freeipa-devel] [PATCH] 956 replicainstall: log ACI and LDAP errors in promotion check In-Reply-To: References: <56F3F969.3050506@redhat.com> <56FB891E.5080405@redhat.com> Message-ID: On 10/26/2016 09:53 AM, Martin Basti wrote: > > > On 30.03.2016 10:06, Martin Basti wrote: >> >> >> On 24.03.2016 15:27, Petr Vobornik wrote: >>> to enable debugging of such errors. >>> >>> E.g.: https://fedorahosted.org/freeipa/ticket/5741 >>> >>> >> Can we log the whole traceback to get exact place where error happened? >> >> Martin^2 >> >> > bump > replaced by: https://github.com/freeipa/freeipa/pull/186 -- Petr Vobornik From freeipa-github-notification at redhat.com Wed Oct 26 09:23:22 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 26 Oct 2016 11:23:22 +0200 Subject: [Freeipa-devel] [freeipa PR#187][opened] Register entry points of Custodia plugins Message-ID: URL: https://github.com/freeipa/freeipa/pull/187 Author: tiran Title: #187: Register entry points of Custodia plugins Action: opened PR body: """ With setuptools in place FreeIPA is able to register its Custodia plugins. Custodia 0.1 ignores the plugins directives. Custodia 0.2 uses the entry points to discover plugins. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/187/head:pr187 git checkout pr187 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-187.patch Type: text/x-diff Size: 1025 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 10:15:38 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 12:15:38 +0200 Subject: [Freeipa-devel] [freeipa PR#184][reopened] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Author: simo5 Title: #184: Minor install script fixes Action: reopened To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/184/head:pr184 git checkout pr184 From freeipa-github-notification at redhat.com Wed Oct 26 10:39:04 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 26 Oct 2016 12:39:04 +0200 Subject: [Freeipa-devel] [freeipa PR#188][opened] Move Python build artefacts to top level directory Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Author: tiran Title: #188: Move Python build artefacts to top level directory Action: opened PR body: """ All setup.py use the same build, dist and *.egg-info directory on top level. Build artefacts are no longer placed in local build directories. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/188/head:pr188 git checkout pr188 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-188.patch Type: text/x-diff Size: 3181 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 10:47:22 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 26 Oct 2016 12:47:22 +0200 Subject: [Freeipa-devel] [freeipa PR#188][comment] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Title: #188: Move Python build artefacts to top level directory tiran commented: """ The PR will also simplifies @pspacek next branch a bit. """ See the full comment at https://github.com/freeipa/freeipa/pull/188#issuecomment-256312577 From freeipa-github-notification at redhat.com Wed Oct 26 11:37:12 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 26 Oct 2016 13:37:12 +0200 Subject: [Freeipa-devel] [freeipa PR#188][synchronized] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Author: tiran Title: #188: Move Python build artefacts to top level directory Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/188/head:pr188 git checkout pr188 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-188.patch Type: text/x-diff Size: 3619 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 11:40:37 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 26 Oct 2016 13:40:37 +0200 Subject: [Freeipa-devel] [freeipa PR#189][opened] Create relative symbol links Message-ID: URL: https://github.com/freeipa/freeipa/pull/189 Author: tiran Title: #189: Create relative symbol links Action: opened PR body: """ Instead of absolute symbolic links to /usr/bin/COMMAND the RPM spec now creates relative symbolic links. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/189/head:pr189 git checkout pr189 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-189.patch Type: text/x-diff Size: 2834 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 11:42:30 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 26 Oct 2016 13:42:30 +0200 Subject: [Freeipa-devel] [freeipa PR#188][comment] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Title: #188: Move Python build artefacts to top level directory tiran commented: """ I ran into some issues with ```make rpm```. ```setup.py``` started to pick up build artefacts of other packages. Now every package uses its own subdirectory under the top-level ```build``` directory. """ See the full comment at https://github.com/freeipa/freeipa/pull/188#issuecomment-256323114 From freeipa-github-notification at redhat.com Wed Oct 26 11:47:07 2016 From: freeipa-github-notification at redhat.com (rcritten) Date: Wed, 26 Oct 2016 13:47:07 +0200 Subject: [Freeipa-devel] [freeipa PR#189][comment] Create relative symbol links In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/189 Title: #189: Create relative symbol links rcritten commented: """ I think you should add the reasoning for switching the link type to the commit message and if this is related to some higher-level ticket that should be included as well. """ See the full comment at https://github.com/freeipa/freeipa/pull/189#issuecomment-256323936 From freeipa-github-notification at redhat.com Wed Oct 26 11:52:01 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 26 Oct 2016 13:52:01 +0200 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes martbab commented: """ Note that the installer class has no access to debug options. These are only used in the containing ConfigureTool class to set up loggers (see https://git.fedorahosted.org/cgit/freeipa.git/tree/ipapython/install/cli.py#n267) and are not passed to the Configurable object. We may need to revert commit #2 to unblock installation of FreeIPA server. The proper fix shall be implemented as a part of installer refactoring effort. """ See the full comment at https://github.com/freeipa/freeipa/pull/184#issuecomment-256324868 From freeipa-github-notification at redhat.com Wed Oct 26 11:56:01 2016 From: freeipa-github-notification at redhat.com (abbra) Date: Wed, 26 Oct 2016 13:56:01 +0200 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes abbra commented: """ I'm fine with that (revert --debug commit). Either alternative (make Configurable be aware of the debug or do a refactoring of an installer) is roughly going into the same direction. I certainly see a reason to have Configurable gain knowledge about --debug option to allow it to configure specific services in debug mode which would go beyond just setting up loggers in the installer itself. """ See the full comment at https://github.com/freeipa/freeipa/pull/184#issuecomment-256325663 From freeipa-github-notification at redhat.com Wed Oct 26 11:58:35 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 26 Oct 2016 13:58:35 +0200 Subject: [Freeipa-devel] [freeipa PR#189][comment] Create relative symbol links In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/189 Title: #189: Create relative symbol links tiran commented: """ I ran into some strange issues while I was working on PR #188. The symlinks were both dangling symlinks and pointed to a directory that my user could not write to. Eventually I found the real culprit. I still think that relative symlinks are better. Python generally uses relative links for its aliases. """ See the full comment at https://github.com/freeipa/freeipa/pull/189#issuecomment-256326175 From freeipa-github-notification at redhat.com Wed Oct 26 12:28:00 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 26 Oct 2016 14:28:00 +0200 Subject: [Freeipa-devel] [freeipa PR#136][+ack] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Title: #136: Fix KRA install tests Label: +ack From freeipa-github-notification at redhat.com Wed Oct 26 12:36:08 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 26 Oct 2016 14:36:08 +0200 Subject: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Title: #184: Minor install script fixes martbab commented: """ Reverted the Fix install scripts debugging commit. master: * dc873007f8616ab9e77f903e235ba49f45ecde37 Revert "Fix install scripts debugging" """ See the full comment at https://github.com/freeipa/freeipa/pull/184#issuecomment-256334107 From freeipa-github-notification at redhat.com Wed Oct 26 12:36:51 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 26 Oct 2016 14:36:51 +0200 Subject: [Freeipa-devel] [freeipa PR#184][closed] Minor install script fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/184 Author: simo5 Title: #184: Minor install script fixes Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/184/head:pr184 git checkout pr184 From freeipa-github-notification at redhat.com Thu Oct 20 14:07:36 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 16:07:36 +0200 Subject: [Freeipa-devel] [freeipa PR#171][synchronized] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Author: pspacek Title: #171: Build system cleanup phase 2 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/171/head:pr171 git checkout pr171 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-171.patch Type: text/x-diff Size: 8203839 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 20 17:02:13 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 20 Oct 2016 19:02:13 +0200 Subject: [Freeipa-devel] [freeipa PR#171][synchronized] Build system cleanup phase 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/171 Author: pspacek Title: #171: Build system cleanup phase 2 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/171/head:pr171 git checkout pr171 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-171.patch Type: text/x-diff Size: 8216943 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 13:06:59 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 15:06:59 +0200 Subject: [Freeipa-devel] [freeipa PR#136][comment] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Title: #136: Fix KRA install tests mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/84ca1fc220c329b58fb6a22c8eb9bf17d3622c55 https://fedorahosted.org/freeipa/changeset/11d7b774c4d731896e3ab6109b6ed7d5524c1bec https://fedorahosted.org/freeipa/changeset/9408085c58a1e9627c1fb4e1ba0343700e36d7e7 """ See the full comment at https://github.com/freeipa/freeipa/pull/136#issuecomment-256341123 From freeipa-github-notification at redhat.com Wed Oct 26 13:07:01 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 15:07:01 +0200 Subject: [Freeipa-devel] [freeipa PR#136][closed] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Author: mbasti-rh Title: #136: Fix KRA install tests Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/136/head:pr136 git checkout pr136 From freeipa-github-notification at redhat.com Wed Oct 26 13:07:03 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 15:07:03 +0200 Subject: [Freeipa-devel] [freeipa PR#136][+pushed] Fix KRA install tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/136 Title: #136: Fix KRA install tests Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 26 13:13:46 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 15:13:46 +0200 Subject: [Freeipa-devel] [freeipa PR#190][opened] [4.4] Fix tests install dom0 Message-ID: URL: https://github.com/freeipa/freeipa/pull/190 Author: mbasti-rh Title: #190: [4.4] Fix tests install dom0 Action: opened PR body: """ Backport PR #136 to ipa-4-4 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/190/head:pr190 git checkout pr190 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-190.patch Type: text/x-diff Size: 12106 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 14:20:28 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 16:20:28 +0200 Subject: [Freeipa-devel] [freeipa PR#191][opened] Zanata fix 4 4 Message-ID: URL: https://github.com/freeipa/freeipa/pull/191 Author: mbasti-rh Title: #191: Zanata fix 4 4 Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/191/head:pr191 git checkout pr191 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-191.patch Type: text/x-diff Size: 290709 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 14:20:45 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 16:20:45 +0200 Subject: [Freeipa-devel] [freeipa PR#191][synchronized] Zanata fix 4 4 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/191 Author: mbasti-rh Title: #191: Zanata fix 4 4 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/191/head:pr191 git checkout pr191 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-191.patch Type: text/x-diff Size: 707 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 14:21:23 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 16:21:23 +0200 Subject: [Freeipa-devel] [freeipa PR#191][edited] Exclude testing ipa.pot file from zanata In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/191 Author: mbasti-rh Title: #191: Exclude testing ipa.pot file from zanata Action: edited Changed field: title Original value: """ Zanata fix 4 4 """ From freeipa-github-notification at redhat.com Wed Oct 26 14:26:14 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 26 Oct 2016 16:26:14 +0200 Subject: [Freeipa-devel] [freeipa PR#192][opened] server-del: fix incorrect check for one IPA master Message-ID: URL: https://github.com/freeipa/freeipa/pull/192 Author: martbab Title: #192: server-del: fix incorrect check for one IPA master Action: opened PR body: """ make the check more robust against returned container types for multivalued attributes (lists vs. tuples). https://fedorahosted.org/freeipa/ticket/6417 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/192/head:pr192 git checkout pr192 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-192.patch Type: text/x-diff Size: 976 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 14:48:30 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 26 Oct 2016 16:48:30 +0200 Subject: [Freeipa-devel] [freeipa PR#151][synchronized] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/151 Author: stlaz Title: #151: Make httpd publish its CA certificate on DL1 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/151/head:pr151 git checkout pr151 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-151.patch Type: text/x-diff Size: 1428 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 14:53:53 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 16:53:53 +0200 Subject: [Freeipa-devel] [freeipa PR#165][+pushed] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 26 14:53:56 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 16:53:56 +0200 Subject: [Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Title: #165: Tests: Verify that cert-find show CA without --all mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/42d1a06bd1e856c14110c06ba0d9d946df36331d ipa-4-4: https://fedorahosted.org/freeipa/changeset/7fde0982610cdc19ac4e85a6759820130c66a233 """ See the full comment at https://github.com/freeipa/freeipa/pull/165#issuecomment-256372338 From freeipa-github-notification at redhat.com Wed Oct 26 14:53:57 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 16:53:57 +0200 Subject: [Freeipa-devel] [freeipa PR#165][closed] Tests: Verify that cert-find show CA without --all In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/165 Author: mirielka Title: #165: Tests: Verify that cert-find show CA without --all Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/165/head:pr165 git checkout pr165 From freeipa-github-notification at redhat.com Wed Oct 26 15:08:22 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 17:08:22 +0200 Subject: [Freeipa-devel] [freeipa PR#192][comment] server-del: fix incorrect check for one IPA master In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/192 Title: #192: server-del: fix incorrect check for one IPA master mbasti-rh commented: """ LGTM, but I wrote possible improvement inline, please check. """ See the full comment at https://github.com/freeipa/freeipa/pull/192#issuecomment-256376902 From freeipa-github-notification at redhat.com Wed Oct 26 15:57:22 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 17:57:22 +0200 Subject: [Freeipa-devel] [freeipa PR#151][+ack] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/151 Title: #151: Make httpd publish its CA certificate on DL1 Label: +ack From freeipa-github-notification at redhat.com Wed Oct 26 15:58:10 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 17:58:10 +0200 Subject: [Freeipa-devel] [freeipa PR#151][comment] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/151 Title: #151: Make httpd publish its CA certificate on DL1 mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/5d15626b4db8f5e777e037680623badc86b6c31d """ See the full comment at https://github.com/freeipa/freeipa/pull/151#issuecomment-256394450 From freeipa-github-notification at redhat.com Wed Oct 26 15:58:11 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 17:58:11 +0200 Subject: [Freeipa-devel] [freeipa PR#151][+pushed] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/151 Title: #151: Make httpd publish its CA certificate on DL1 Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 26 15:58:13 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 17:58:13 +0200 Subject: [Freeipa-devel] [freeipa PR#151][closed] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/151 Author: stlaz Title: #151: Make httpd publish its CA certificate on DL1 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/151/head:pr151 git checkout pr151 From freeipa-github-notification at redhat.com Wed Oct 26 16:08:53 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 26 Oct 2016 18:08:53 +0200 Subject: [Freeipa-devel] [freeipa PR#193][opened] [ipa-4-4] Make httpd publish its CA certificate on DL1 Message-ID: URL: https://github.com/freeipa/freeipa/pull/193 Author: stlaz Title: #193: [ipa-4-4] Make httpd publish its CA certificate on DL1 Action: opened PR body: """ httpd did not publish its certificate on DL1 which could cause issues during client installation in a rare corner case where there would be no way of getting the certificate but from a HTTP instance. https://fedorahosted.org/freeipa/ticket/6393 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/193/head:pr193 git checkout pr193 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-193.patch Type: text/x-diff Size: 1405 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Oct 26 16:10:46 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:10:46 +0200 Subject: [Freeipa-devel] [freeipa PR#193][+ack] [ipa-4-4] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/193 Title: #193: [ipa-4-4] Make httpd publish its CA certificate on DL1 Label: +ack From freeipa-github-notification at redhat.com Wed Oct 26 16:11:09 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:11:09 +0200 Subject: [Freeipa-devel] [freeipa PR#193][+pushed] [ipa-4-4] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/193 Title: #193: [ipa-4-4] Make httpd publish its CA certificate on DL1 Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 26 16:11:10 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:11:10 +0200 Subject: [Freeipa-devel] [freeipa PR#193][comment] [ipa-4-4] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/193 Title: #193: [ipa-4-4] Make httpd publish its CA certificate on DL1 mbasti-rh commented: """ Fixed upstream ipa-4-4: https://fedorahosted.org/freeipa/changeset/c84d920ce8b4ca634d72d7bd99652f93f98b0959 """ See the full comment at https://github.com/freeipa/freeipa/pull/193#issuecomment-256398562 From freeipa-github-notification at redhat.com Wed Oct 26 16:11:12 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:11:12 +0200 Subject: [Freeipa-devel] [freeipa PR#193][closed] [ipa-4-4] Make httpd publish its CA certificate on DL1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/193 Author: stlaz Title: #193: [ipa-4-4] Make httpd publish its CA certificate on DL1 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/193/head:pr193 git checkout pr193 From freeipa-github-notification at redhat.com Wed Oct 26 16:25:36 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:25:36 +0200 Subject: [Freeipa-devel] [freeipa PR#186][+ack] replicainstall: log ACI and LDAP errors in promotion check In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/186 Title: #186: replicainstall: log ACI and LDAP errors in promotion check Label: +ack From freeipa-github-notification at redhat.com Wed Oct 26 16:26:07 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:26:07 +0200 Subject: [Freeipa-devel] [freeipa PR#163][comment] Do not create Object Signing certificate In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/163 Title: #163: Do not create Object Signing certificate mbasti-rh commented: """ Works for me """ See the full comment at https://github.com/freeipa/freeipa/pull/163#issuecomment-256402862 From freeipa-github-notification at redhat.com Wed Oct 26 16:26:13 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:26:13 +0200 Subject: [Freeipa-devel] [freeipa PR#163][+ack] Do not create Object Signing certificate In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/163 Title: #163: Do not create Object Signing certificate Label: +ack From freeipa-github-notification at redhat.com Wed Oct 26 16:26:52 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:26:52 +0200 Subject: [Freeipa-devel] [freeipa PR#163][+pushed] Do not create Object Signing certificate In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/163 Title: #163: Do not create Object Signing certificate Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 26 16:26:54 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:26:54 +0200 Subject: [Freeipa-devel] [freeipa PR#163][comment] Do not create Object Signing certificate In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/163 Title: #163: Do not create Object Signing certificate mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/eb6bfd82f363405e3377b2a912b1152ba76625ae """ See the full comment at https://github.com/freeipa/freeipa/pull/163#issuecomment-256403076 From freeipa-github-notification at redhat.com Wed Oct 26 16:26:55 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:26:55 +0200 Subject: [Freeipa-devel] [freeipa PR#163][closed] Do not create Object Signing certificate In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/163 Author: frasertweedale Title: #163: Do not create Object Signing certificate Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/163/head:pr163 git checkout pr163 From freeipa-github-notification at redhat.com Wed Oct 26 16:30:00 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:30:00 +0200 Subject: [Freeipa-devel] [freeipa PR#176][+ack] cert-show: show validity in default output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/176 Title: #176: cert-show: show validity in default output Label: +ack From freeipa-github-notification at redhat.com Wed Oct 26 16:30:50 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:30:50 +0200 Subject: [Freeipa-devel] [freeipa PR#176][+pushed] cert-show: show validity in default output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/176 Title: #176: cert-show: show validity in default output Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 26 16:30:52 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:30:52 +0200 Subject: [Freeipa-devel] [freeipa PR#176][comment] cert-show: show validity in default output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/176 Title: #176: cert-show: show validity in default output mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/b6a3c9dc74ccef6f8e7df4123670d7e11269198c ipa-4-4: https://fedorahosted.org/freeipa/changeset/0d8f8896db8ad3a1c91cacfb009640602552f55f """ See the full comment at https://github.com/freeipa/freeipa/pull/176#issuecomment-256404255 From freeipa-github-notification at redhat.com Wed Oct 26 16:30:53 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:30:53 +0200 Subject: [Freeipa-devel] [freeipa PR#176][closed] cert-show: show validity in default output In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/176 Author: frasertweedale Title: #176: cert-show: show validity in default output Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/176/head:pr176 git checkout pr176 From freeipa-github-notification at redhat.com Wed Oct 26 16:32:25 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:32:25 +0200 Subject: [Freeipa-devel] [freeipa PR#186][+pushed] replicainstall: log ACI and LDAP errors in promotion check In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/186 Title: #186: replicainstall: log ACI and LDAP errors in promotion check Label: +pushed From freeipa-github-notification at redhat.com Wed Oct 26 16:32:27 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:32:27 +0200 Subject: [Freeipa-devel] [freeipa PR#186][comment] replicainstall: log ACI and LDAP errors in promotion check In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/186 Title: #186: replicainstall: log ACI and LDAP errors in promotion check mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d0c17b4d9afb95db2abcd93096fa6626fd61870e """ See the full comment at https://github.com/freeipa/freeipa/pull/186#issuecomment-256404716 From freeipa-github-notification at redhat.com Wed Oct 26 16:32:28 2016 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 26 Oct 2016 18:32:28 +0200 Subject: [Freeipa-devel] [freeipa PR#186][closed] replicainstall: log ACI and LDAP errors in promotion check In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/186 Author: pvoborni Title: #186: replicainstall: log ACI and LDAP errors in promotion check Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/186/head:pr186 git checkout pr186 From freeipa-github-notification at redhat.com Thu Oct 27 06:16:48 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 27 Oct 2016 08:16:48 +0200 Subject: [Freeipa-devel] [freeipa PR#188][comment] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Title: #188: Move Python build artefacts to top level directory pspacek commented: """ Why this change? It goes against the usual behavior where build artifacts are placed in the same directory as sources. Also, I intend to support ouf-of-source-tree builds (aka [VPATH](https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html)) and I'm not sure it will work with your patch. I would reject this change if there is no strong need. """ See the full comment at https://github.com/freeipa/freeipa/pull/188#issuecomment-256555896 From freeipa-github-notification at redhat.com Thu Oct 27 06:18:22 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 27 Oct 2016 08:18:22 +0200 Subject: [Freeipa-devel] [freeipa PR#189][comment] Create relative symbol links In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/189 Title: #189: Create relative symbol links pspacek commented: """ As I said several times already, all the SPEC file logic is going away. I'm going to reject this as we do not need to change code which is going away and force everybody to rebase. """ See the full comment at https://github.com/freeipa/freeipa/pull/189#issuecomment-256556124 From freeipa-github-notification at redhat.com Thu Oct 27 06:18:27 2016 From: freeipa-github-notification at redhat.com (pspacek) Date: Thu, 27 Oct 2016 08:18:27 +0200 Subject: [Freeipa-devel] [freeipa PR#189][+rejected] Create relative symbol links In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/189 Title: #189: Create relative symbol links Label: +rejected From freeipa-github-notification at redhat.com Thu Oct 27 06:39:41 2016 From: freeipa-github-notification at redhat.com (mirielka) Date: Thu, 27 Oct 2016 08:39:41 +0200 Subject: [Freeipa-devel] [freeipa PR#194][opened] Tests: Verify that validity info is present in cert-show and cert-find command Message-ID: URL: https://github.com/freeipa/freeipa/pull/194 Author: mirielka Title: #194: Tests: Verify that validity info is present in cert-show and cert-find command Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6419 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/194/head:pr194 git checkout pr194 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-194.patch Type: text/x-diff Size: 1237 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 27 07:19:42 2016 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 27 Oct 2016 09:19:42 +0200 Subject: [Freeipa-devel] [freeipa PR#192][synchronized] server-del: fix incorrect check for one IPA master In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/192 Author: martbab Title: #192: server-del: fix incorrect check for one IPA master Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/192/head:pr192 git checkout pr192 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-192.patch Type: text/x-diff Size: 858 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 27 08:47:26 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 27 Oct 2016 10:47:26 +0200 Subject: [Freeipa-devel] [freeipa PR#188][comment] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Title: #188: Move Python build artefacts to top level directory stlaz commented: """ +1 with @pspacek, build artefacts should be in the same directory as is their source. I would like to have them removed on `make clean` if that does not currently work. """ See the full comment at https://github.com/freeipa/freeipa/pull/188#issuecomment-256583611 From freeipa-github-notification at redhat.com Thu Oct 27 09:37:12 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 11:37:12 +0200 Subject: [Freeipa-devel] [freeipa PR#188][synchronized] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Author: tiran Title: #188: Move Python build artefacts to top level directory Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/188/head:pr188 git checkout pr188 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-188.patch Type: text/x-diff Size: 7996 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 27 09:47:33 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 11:47:33 +0200 Subject: [Freeipa-devel] [freeipa PR#189][closed] Create relative symbol links In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/189 Author: tiran Title: #189: Create relative symbol links Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/189/head:pr189 git checkout pr189 From freeipa-github-notification at redhat.com Thu Oct 27 10:21:03 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 12:21:03 +0200 Subject: [Freeipa-devel] [freeipa PR#188][synchronized] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Author: tiran Title: #188: Move Python build artefacts to top level directory Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/188/head:pr188 git checkout pr188 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-188.patch Type: text/x-diff Size: 8450 bytes Desc: not available URL: From ofayans at redhat.com Thu Oct 27 12:21:09 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 27 Oct 2016 14:21:09 +0200 Subject: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test In-Reply-To: <39a8af61-056b-df40-9126-50997a5b54c8@redhat.com> References: <57A07FE4.8000904@redhat.com> <2b0ed7fe-f0bc-7137-bdc1-b0758ffe9cd6@redhat.com> <20160914154119.mkk2ma7tvks55xsu@redhat.com> <97eaa313-e889-cd4a-e900-9e88596577a0@redhat.com> <20160914155320.iowrijrq3z62evoo@redhat.com> <1af52e6c-c24b-d58b-ccf5-a85c5c290e0c@redhat.com> <20160914165348.GE2761@p.Speedport_W_724V_Typ_A_05011603_00_009> <59763ea7-2ab5-bdc2-72c1-489a462f78ef@redhat.com> <6089c103-ab56-62f7-971c-a41710eee22f@redhat.com> <1d744d16-75de-2bdc-5892-b3c36a305581@redhat.com> <39a8af61-056b-df40-9126-50997a5b54c8@redhat.com> Message-ID: ping for review On 10/25/2016 10:24 AM, Oleg Fayans wrote: > Integration part of the tests is ready. 2 tests: > > 1. Adds a cert to idoverride of a windows user > 2. sssd part - looks up user by his certificate using dbus-sssd > > Second and third dbus call are executed as a string insted of as array > of strings because it just does not work otherwise. Some quote escaping > gets screwed probably, but the system returns "Error > org.freedesktop.DBus.Error.UnknownInterface: Unknown interface" if the > command is executed using the standard array-based approach > > The run looks like this: > > bash-4.3$ ipa-run-tests test_integration/test_idviews.py --pdb > WARNING: Couldn't write lextab module 'pycparser.lextab'. [Errno 13] > Permission denied: 'lextab.py' > WARNING: yacc table file version is out of date > WARNING: Couldn't create 'pycparser.yacctab'. [Errno 13] Permission > denied: 'yacctab.py' > ==================================== test session starts > ==================================== > platform linux2 -- Python 2.7.11, pytest-2.9.2, py-1.4.31, pluggy-0.3.1 > rootdir: /usr/lib/python2.7/site-packages/ipatests, inifile: pytest.ini > plugins: sourceorder-0.5, multihost-1.0 > collected 2 items > > test_integration/test_idviews.py .. > > ================================ 2 passed in 948.44 seconds > ================================= > > > On 10/21/2016 10:54 AM, Oleg Fayans wrote: >> Added one more test, resolved the pep8 issues >> >> On 10/19/2016 12:32 PM, Oleg Fayans wrote: >>> Hi Martin, >>> >>> As you suggested, I've extended the >>> test_xmlrpc/test_add_remove_cert_cmd.py to contain basic tests for certs >>> in idoverrides. >>> The integration part still needs some polishing in the part related to >>> user lookup by cert >>> >>> On 10/14/2016 03:57 PM, Martin Babinsky wrote: >>>> On 10/14/2016 03:48 PM, Oleg Fayans wrote: >>>>> So, did I understand correctly, that there would be 2 patches: one >>>>> containing test for basic idoverrides functionality without >>>>> AD-integration, and the second one - with AD-integration and an sssd >>>>> check, correct? >>>>> I guess, the >>>>> freeipa-ofayans-0050.1-Automated-test-for-certs-in-idoverrides-feature.patch >>>>> >>>>> >>>>> >>>>> >>>>> might be a good candidate for the first one, I only have to change the >>>>> filename to test_idviews.py, right? >>>>> >>>> >>>> Oleg, we already have XMLRPC tests for idoverrides: >>>> >>>> ipatests/test_xmlrpc/test_idviews_plugin.py >>>> >>>> Is there any particular reason why not to extend them with add >>>> cert/remove cert operations? >>>> >>>> Even better, you can extend >>>> `ipatests/test_xmlrpc/test_add_remove_cert_cmd.py` suite by doing the >>>> same set of tests on idoverrideuser objects. >>>> >>>> Or am I missing something? >>>> >>>>> On 09/15/2016 10:32 AM, Martin Basti wrote: >>>>>> >>>>>> >>>>>> On 15.09.2016 10:10, Oleg Fayans wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> The file was renamed. Did I understand correctly that for now we are >>>>>>> leaving the test as is and are planning to extend it later? >>>>>> >>>>>> I would like to have there SSSD check involved, please use what >>>>>> Summit >>>>>> recommends. No new test cases. >>>>>> >>>>>> And this can be done by separate patch, I want to have API/CLI >>>>>> certificate override tests for non-AD idview (extending current >>>>>> tests I >>>>>> posted in this thread) >>>>>> >>>>>> Martin^2 >>>>>>> >>>>>>> On 09/15/2016 09:49 AM, Martin Basti wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 14.09.2016 18:53, Sumit Bose wrote: >>>>>>>>> On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote: >>>>>>>>>> >>>>>>>>>> On 14.09.2016 17:53, Alexander Bokovoy wrote: >>>>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 14.09.2016 17:41, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Wed, 14 Sep 2016, Martin Basti wrote: >>>>>>>>>>>>>> 1) >>>>>>>>>>>>>> I still don't see the reason why AD trust is needed. Default >>>>>>>>>>>>>> trust ID view is added just by ipa-adtrust-install, adding >>>>>>>>>>>>>> trust is not needed for current implementation. You don't >>>>>>>>>>>>>> need AD for this, IDviews is generic feature not just for >>>>>>>>>>>>>> AD. Is that user configured on AD side? >>>>>>>>>>>>> You cannot add non-AD user to 'default trust view', so you >>>>>>>>>>>>> will >>>>>>>>>>>>> not be >>>>>>>>>>>>> able to set up certificates to ID override which does not >>>>>>>>>>>>> exist. >>>>>>>>>>>>> >>>>>>>>>>>>> For non-'default trust view' you can add both IPA and AD >>>>>>>>>>>>> users, >>>>>>>>>>>>> so using >>>>>>>>>>>>> some other view and then assign certificate for a ID >>>>>>>>>>>>> override in >>>>>>>>>>>>> that >>>>>>>>>>>>> one. >>>>>>>>>>>>> >>>>>>>>>>>> Ok then, but anyway I would like to see API/CLI tests for this >>>>>>>>>>>> feature with proper output validation. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> How can be this tested with SSSD? >>>>>>>>>>> You need to log into the system with a certificate... >>>>>>>>>> Is this possible from test? We are logged remotely as root, is >>>>>>>>>> there any >>>>>>>>>> cmdline util which allows us to test certificate against AD user? >>>>>>>>> >>>>>>>>> You can use 'sss_ssh_authorizedkeys aduser at ad.domain' which should >>>>>>>>> return the ssh key derived from the public key in the certificate. >>>>>>>>> This >>>>>>>>> should work for certificate stored in AD as well as for overrides. >>>>>>>>> >>>>>>>>> You can also you the DBus lookup by certificate as described in >>>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>>> HTH >>>>>>>>> >>>>>>>>> bye, >>>>>>>>> Sumit >>>>>>>> >>>>>>>> Thank you Alexander and Summit for hints. >>>>>>>> >>>>>>>> Oleg I realized we don't have any other idviews integration tests >>>>>>>> >>>>>>>> So I propose to rename test file you are adding to >>>>>>>> test_idviews.py. We >>>>>>>> can add more testcases for idviews there later >>>>>>>> >>>>>>>> Martin^2 >>>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From ofayans at redhat.com Thu Oct 27 12:21:33 2016 From: ofayans at redhat.com (Oleg Fayans) Date: Thu, 27 Oct 2016 14:21:33 +0200 Subject: [Freeipa-devel] [test][patch-0057] test for ticket N 6146 (installing rules with service principals) In-Reply-To: <7d137bdf-883c-2ef9-468d-f8b7de358804@redhat.com> References: <57AAE7EA.5090604@redhat.com> <745bf2dc-18d4-9f89-b97c-980b447f2823@redhat.com> <57AB1418.60903@redhat.com> <7d137bdf-883c-2ef9-468d-f8b7de358804@redhat.com> Message-ID: <9e419344-e733-76b0-b103-77496dd1097c@redhat.com> ping for review On 10/25/2016 11:29 AM, Oleg Fayans wrote: > The patch was rebased to be able to apply on top of latest version of > certs in idoverrides patch. As before, it requires patches NN 0049 and > 0059 to apply > > On 08/10/2016 01:46 PM, Oleg Fayans wrote: >> Hi Martin, >> >> I am sorry, yes it depends on my patches 0049 and 0050. >> >> >> On 08/10/2016 12:27 PM, Martin Basti wrote: >>> >>> >>> On 10.08.2016 10:38, Oleg Fayans wrote: >>>> >>>> >>>> >>> Hello, >>> >>> I cannot apply this patch >>> error: ipatests/test_integration/test_certs_in_idoverrides.py: does not >>> exist in index >>> It probably depends on another patch (which one?) >>> >>> Please, use human readable subjects in email, I do not remember from top >>> of my head what #6146 is. >>> >>> Martin^2 >>> >>> >> > > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. From freeipa-github-notification at redhat.com Thu Oct 27 12:56:30 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 14:56:30 +0200 Subject: [Freeipa-devel] [freeipa PR#188][synchronized] Move Python build artefacts to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Author: tiran Title: #188: Move Python build artefacts to top level directory Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/188/head:pr188 git checkout pr188 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-188.patch Type: text/x-diff Size: 6752 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 27 12:57:35 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 14:57:35 +0200 Subject: [Freeipa-devel] [freeipa PR#188][edited] Move Python egg-info to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Author: tiran Title: #188: Move Python egg-info to top level directory Action: edited Changed field: title Original value: """ Move Python build artefacts to top level directory """ From freeipa-github-notification at redhat.com Thu Oct 27 13:08:13 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 15:08:13 +0200 Subject: [Freeipa-devel] [freeipa PR#188][comment] Move Python egg-info to top level directory In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/188 Title: #188: Move Python egg-info to top level directory tiran commented: """ I have changed the PR a bit * dist and build are no longer moved * as discussed on IRC ```freeipa.egg-info``` is now ```ipaserver.egg-info```. pkg_resource assumes that a egg-info directory has the same prefix as a package directory. * I added a egg_info command plugin based on https://blog.kevin-brown.com/programming/2014/09/24/combining-autotools-and-setuptools.html . My variant uses the distutils API properly and corrects a bug with ```install_egg_info``` plugin. * ipasetup now calculates the package root path based on the path of setup.py. This should be enough to enable VPATH out-of-tree builds. * By default the egg-info directories are in the top-level project dir or on top_builddir. For in-tree tests the egg-info directories must be in sys.path in order to register entry points correctly, see PR #187 """ See the full comment at https://github.com/freeipa/freeipa/pull/188#issuecomment-256635536 From mbasti at redhat.com Thu Oct 27 13:28:44 2016 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Oct 2016 15:28:44 +0200 Subject: [Freeipa-devel] Github: rebases and commits order Message-ID: <721722fe-06bd-415c-e066-8c309f4750b2@redhat.com> FYI: when you change order of commits using `git rebase` github doesn't respect this and shows commits in UI based on author date ordering. https://github.com/isaacs/github/issues/386 It is just for your information, we started using bigger amount of commits and surprise, surprise UI shows commits in PR almost random order due rebases (git show works fine locally). ipatool has been already fixed to push in correct order (please pull the latest version) Martin^2 From freeipa-github-notification at redhat.com Thu Oct 27 14:11:24 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 27 Oct 2016 16:11:24 +0200 Subject: [Freeipa-devel] [freeipa PR#166][comment] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Title: #166: WebUI: services without canonical name are shown correctly pvoborni commented: """ Works for me. Code look OK. I have only one minor nitpick: name of the adaper. Current is `SearchTableColumnFieldAdapter` imho better would be e.g. `AlternateAttrFieldAdapter`. I.e., to describe function and not place of use. IMO it can be even placed in field.js If you don't want to address that then ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/166#issuecomment-256652549 From freeipa-github-notification at redhat.com Thu Oct 27 15:01:45 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 17:01:45 +0200 Subject: [Freeipa-devel] [freeipa PR#195][opened] [WIP] Make ipaclient pip install-able Message-ID: URL: https://github.com/freeipa/freeipa/pull/195 Author: tiran Title: #195: [WIP] Make ipaclient pip install-able Action: opened PR body: """ This makes ipaclient and dependencies pip install-able by adding install requirements to all ```setup.py```. A new make target ```bdist_wheel``` creates wheel distributions. ## example ``` $ make bdist_wheel $ cp ../custodia/dist/custodia-0.2-py2.py3-none-any.whl dist/ $ virtualenv /tmp/ipaenv New python executable in /tmp/ipaenv/bin/python2 Also creating executable in /tmp/ipaenv/bin/python Installing setuptools, pip, wheel...done. $ /tmp/ipaenv/bin/pip install dist/*.whl Processing ./dist/custodia-0.2-py2.py3-none-any.whl Processing ./dist/ipaclient-4.4.90.201610271437GITd812266-py2.py3-none-any.whl Processing ./dist/ipalib-4.4.90.201610271437GITd812266-py2.py3-none-any.whl Processing ./dist/ipaplatform-4.4.90.201610271437GITd812266-py2.py3-none-any.whl Processing ./dist/ipapython-4.4.90.201610271437GITd812266-py2.py3-none-any.whl ... Installing collected packages: configparser, requests, six, idna, pycparser, cffi, pyasn1, enum34, ipaddress, cryptography, jwcrypto, custodia, qrcode, python-nss, ipaplatform, netaddr, lxml, pyldap, netifaces, decorator, gssapi, dnspython, ipapython, ipalib, ipaclient Running setup.py install for python-nss ... done Successfully installed cffi-1.8.3 configparser-3.5.0 cryptography-1.5.2 custodia-0.2 decorator-4.0.10 dnspython-1.15.0 enum34-1.1.6 gssapi-1.2.0 idna-2.1 ipaclient-4.4.90.201610271437GITd812266 ipaddress-1.0.17 ipalib-4.4.90.201610271437GITd812266 ipaplatform-4.4.90.201610271437GITd812266 ipapython-4.4.90.201610271437GITd812266 jwcrypto-0.3.1 lxml-3.6.4 netaddr-0.7.18 netifaces-0.10.5 pyasn1-0.1.9 pycparser-2.16 pyldap-2.4.25.1 python-nss-1.0.0 qrcode-5.3 requests-2.11.1 six-1.10.0 ``` ## open problems - [ ] Custodia is not yet released on PyPI (to be released soon) - [ ] dependencies are duplicated in setup.py and RPM spec - [ ] ipaplatform hard-codes the distribution on build time """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/195/head:pr195 git checkout pr195 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-195.patch Type: text/x-diff Size: 8908 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Oct 27 15:06:20 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 27 Oct 2016 17:06:20 +0200 Subject: [Freeipa-devel] [freeipa PR#195][edited] [WIP] Make ipaclient pip install-able In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/195 Author: tiran Title: #195: [WIP] Make ipaclient pip install-able Action: edited Changed field: body Original value: """ This makes ipaclient and dependencies pip install-able by adding install requirements to all ```setup.py```. A new make target ```bdist_wheel``` creates wheel distributions. ## example ``` $ make bdist_wheel $ cp ../custodia/dist/custodia-0.2-py2.py3-none-any.whl dist/ $ virtualenv /tmp/ipaenv New python executable in /tmp/ipaenv/bin/python2 Also creating executable in /tmp/ipaenv/bin/python Installing setuptools, pip, wheel...done. $ /tmp/ipaenv/bin/pip install dist/*.whl Processing ./dist/custodia-0.2-py2.py3-none-any.whl Processing ./dist/ipaclient-4.4.90.201610271437GITd812266-py2.py3-none-any.whl Processing ./dist/ipalib-4.4.90.201610271437GITd812266-py2.py3-none-any.whl Processing ./dist/ipaplatform-4.4.90.201610271437GITd812266-py2.py3-none-any.whl Processing ./dist/ipapython-4.4.90.201610271437GITd812266-py2.py3-none-any.whl ... Installing collected packages: configparser, requests, six, idna, pycparser, cffi, pyasn1, enum34, ipaddress, cryptography, jwcrypto, custodia, qrcode, python-nss, ipaplatform, netaddr, lxml, pyldap, netifaces, decorator, gssapi, dnspython, ipapython, ipalib, ipaclient Running setup.py install for python-nss ... done Successfully installed cffi-1.8.3 configparser-3.5.0 cryptography-1.5.2 custodia-0.2 decorator-4.0.10 dnspython-1.15.0 enum34-1.1.6 gssapi-1.2.0 idna-2.1 ipaclient-4.4.90.201610271437GITd812266 ipaddress-1.0.17 ipalib-4.4.90.201610271437GITd812266 ipaplatform-4.4.90.201610271437GITd812266 ipapython-4.4.90.201610271437GITd812266 jwcrypto-0.3.1 lxml-3.6.4 netaddr-0.7.18 netifaces-0.10.5 pyasn1-0.1.9 pycparser-2.16 pyldap-2.4.25.1 python-nss-1.0.0 qrcode-5.3 requests-2.11.1 six-1.10.0 ``` ## open problems - [ ] Custodia is not yet released on PyPI (to be released soon) - [ ] dependencies are duplicated in setup.py and RPM spec - [ ] ipaplatform hard-codes the distribution on build time """ From freeipa-github-notification at redhat.com Thu Oct 27 15:06:38 2016 From: freeipa-github-notification at redhat.com (apophys) Date: Thu, 27 Oct 2016 17:06:38 +0200 Subject: [Freeipa-devel] [freeipa PR#196][opened] ipatests: unresolvable nested netgroups Message-ID: URL: https://github.com/freeipa/freeipa/pull/196 Author: apophys Title: #196: ipatests: unresolvable nested netgroups Action: opened PR body: """ Adds a test case for issue in SSSD that manifested in an inability to resolve nested membership in netgroups The test case tests for direct and indirect membership. https://fedorahosted.org/freeipa/ticket/6439 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/196/head:pr196 git checkout pr196 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-196.patch Type: text/x-diff Size: 4965 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 31 07:02:01 2016 From: freeipa-github-notification at redhat.com (jcholast) Date: Mon, 31 Oct 2016 08:02:01 +0100 Subject: [Freeipa-devel] [freeipa PR#50][comment] Add cert checks in ipa-server-certinstall In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/50 Title: #50: Add cert checks in ipa-server-certinstall jcholast commented: """ ipa-4-4: https://fedorahosted.org/freeipa/changeset/f32e68349b291288c154dcf4dd17002a966195c5 """ See the full comment at https://github.com/freeipa/freeipa/pull/50#issuecomment-257226052 From freeipa-github-notification at redhat.com Mon Oct 31 08:21:01 2016 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 31 Oct 2016 09:21:01 +0100 Subject: [Freeipa-devel] [freeipa PR#197][opened] Make setup.py files PyPI compatible Message-ID: URL: https://github.com/freeipa/freeipa/pull/197 Author: tiran Title: #197: Make setup.py files PyPI compatible Action: opened PR body: """ - Use PEP 440 compatible version schema - Use correct classifiers Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/197/head:pr197 git checkout pr197 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-197.patch Type: text/x-diff Size: 2365 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 31 08:34:11 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Mon, 31 Oct 2016 09:34:11 +0100 Subject: [Freeipa-devel] [freeipa PR#166][synchronized] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Author: pvomacka Title: #166: WebUI: services without canonical name are shown correctly Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/166/head:pr166 git checkout pr166 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-166.patch Type: text/x-diff Size: 4911 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 31 08:36:08 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Mon, 31 Oct 2016 09:36:08 +0100 Subject: [Freeipa-devel] [freeipa PR#166][comment] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Title: #166: WebUI: services without canonical name are shown correctly pvomacka commented: """ Thank you for review. I moved the adapter into field.js and also renamed it. Proposed name looks better. """ See the full comment at https://github.com/freeipa/freeipa/pull/166#issuecomment-257239069 From freeipa-github-notification at redhat.com Mon Oct 31 08:43:44 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Mon, 31 Oct 2016 09:43:44 +0100 Subject: [Freeipa-devel] [freeipa PR#166][synchronized] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Author: pvomacka Title: #166: WebUI: services without canonical name are shown correctly Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/166/head:pr166 git checkout pr166 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-166.patch Type: text/x-diff Size: 5174 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 31 08:44:43 2016 From: freeipa-github-notification at redhat.com (pvomacka) Date: Mon, 31 Oct 2016 09:44:43 +0100 Subject: [Freeipa-devel] [freeipa PR#166][comment] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Title: #166: WebUI: services without canonical name are shown correctly pvomacka commented: """ I forgot to improve AlternateAttrFieldAdapter comment. Fixed now. """ See the full comment at https://github.com/freeipa/freeipa/pull/166#issuecomment-257240513 From freeipa-github-notification at redhat.com Mon Oct 31 15:17:37 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 31 Oct 2016 16:17:37 +0100 Subject: [Freeipa-devel] [freeipa PR#166][+ack] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Title: #166: WebUI: services without canonical name are shown correctly Label: +ack From freeipa-github-notification at redhat.com Mon Oct 31 15:17:39 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 31 Oct 2016 16:17:39 +0100 Subject: [Freeipa-devel] [freeipa PR#166][comment] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Title: #166: WebUI: services without canonical name are shown correctly pvoborni commented: """ new version works for me ACK """ See the full comment at https://github.com/freeipa/freeipa/pull/166#issuecomment-257322204 From freeipa-github-notification at redhat.com Mon Oct 31 15:18:39 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 31 Oct 2016 16:18:39 +0100 Subject: [Freeipa-devel] [freeipa PR#166][comment] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Title: #166: WebUI: services without canonical name are shown correctly pvoborni commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/4f760dffa011a3656b6072c74088b497ff416a8d ipa-4-4: https://fedorahosted.org/freeipa/changeset/599a7ff90d7dddc6b5804ed6844e5d3faff017ed """ See the full comment at https://github.com/freeipa/freeipa/pull/166#issuecomment-257322514 From freeipa-github-notification at redhat.com Mon Oct 31 15:18:41 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 31 Oct 2016 16:18:41 +0100 Subject: [Freeipa-devel] [freeipa PR#166][+pushed] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Title: #166: WebUI: services without canonical name are shown correctly Label: +pushed From freeipa-github-notification at redhat.com Mon Oct 31 15:18:42 2016 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 31 Oct 2016 16:18:42 +0100 Subject: [Freeipa-devel] [freeipa PR#166][closed] WebUI: services without canonical name are shown correctly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/166 Author: pvomacka Title: #166: WebUI: services without canonical name are shown correctly Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/166/head:pr166 git checkout pr166 From freeipa-github-notification at redhat.com Mon Oct 31 15:56:27 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 31 Oct 2016 16:56:27 +0100 Subject: [Freeipa-devel] [freeipa PR#198][opened] Fix missing file that fails DL1 replica installation Message-ID: URL: https://github.com/freeipa/freeipa/pull/198 Author: stlaz Title: #198: Fix missing file that fails DL1 replica installation Action: opened PR body: """ Replica installation on DL1 would fail to create a httpd instance due to missing '/etc/httpd/alias/cacert.asc'. Create this file in the setup_ssl step to avoid the error. https://fedorahosted.org/freeipa/ticket/6442 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/198/head:pr198 git checkout pr198 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-198.patch Type: text/x-diff Size: 2108 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 31 16:07:35 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 31 Oct 2016 17:07:35 +0100 Subject: [Freeipa-devel] [freeipa PR#198][synchronized] Fix missing file that fails DL1 replica installation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/198 Author: stlaz Title: #198: Fix missing file that fails DL1 replica installation Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/198/head:pr198 git checkout pr198 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-198.patch Type: text/x-diff Size: 2102 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Oct 31 16:07:40 2016 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 31 Oct 2016 17:07:40 +0100 Subject: [Freeipa-devel] [freeipa PR#198][edited] Fix missing file that fails DL1 replica installation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/198 Author: stlaz Title: #198: Fix missing file that fails DL1 replica installation Action: edited Changed field: body Original value: """ Replica installation on DL1 would fail to create a httpd instance due to missing '/etc/httpd/alias/cacert.asc'. Create this file in the setup_ssl step to avoid the error. https://fedorahosted.org/freeipa/ticket/6442 """ From abokovoy at redhat.com Mon Oct 31 16:23:42 2016 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 31 Oct 2016 18:23:42 +0200 Subject: [Freeipa-devel] [PATCH] 0221 fix trustdomain-del Message-ID: <20161031162342.47j3md6wwdn4au6s@redhat.com> See description. This is a regression since FreeIPA 4.4.0. -- / Alexander Bokovoy -------------- next part -------------- From ce6dcc38fe4b1772941b281880ab156d7ae0db7c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 31 Oct 2016 18:17:35 +0200 Subject: [PATCH 2/2] trustdomain-del: fix the way how subdomain is searched With FreeIPA 4.4 we moved child domains behind the 'trustdomain' topic. Update 'ipa trustdomain-del' command to properly calculate DN to the actual child domain and handle the case when it is missing correctly. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1389709 --- ipaserver/plugins/trust.py | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py index c0c080d..3540742 100644 --- a/ipaserver/plugins/trust.py +++ b/ipaserver/plugins/trust.py @@ -1614,13 +1614,16 @@ class trustdomain_del(LDAPDelete): # to always receive empty keys. We need to catch the case when root domain is being deleted for domain in keys[1]: - # Fetch the trust to verify that the entered domain is trusted - self.api.Command.trust_show(domain) + try: + dn = self.obj.get_dn(keys[0], domain, trust_type=u'ad') + entry = ldap.get_entry(dn) + except errors.NotFound: + if keys[0].lower() == domain: + raise errors.ValidationError(name='domain', + error=_("cannot delete root domain of the trust, " + "use trust-del to delete the trust itself")) + self.obj.handle_not_found(keys[0], domain) - if keys[0].lower() == domain: - raise errors.ValidationError(name='domain', - error=_("cannot delete root domain of the trust, " - "use trust-del to delete the trust itself")) try: self.api.Command.trustdomain_enable(keys[0], domain) except errors.AlreadyActive: -- 2.9.3