November 2017 - FreeIPA-devel - Fedora mailing-lists

[freeipa PR#1304][opened] Fix grammar in login screen
by tiran 12 Dec '17

12 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1304 Author: tiran Title: #1304: Fix grammar in login screen Action: opened PR body: """ https://pagure.io/freeipa/issue/7263 Signed-off-by: Christian Heimes <cheimes(a)redhat.com> """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1304/head:pr1304 git checkout pr1304

1 1

[freeipa PR#1232][opened] Making ipa-ca-install more resilient
by frasertweedale 11 Dec '17

11 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1232 Author: frasertweedale Title: #1232: Making ipa-ca-install more resilient Action: opened PR body: """ , or: *Proactively run ipa-certupdate for great good!* These commits fix a couple of issues that can occur after a deployment has been promoted from CA-less to CA-ful, and the admin does not follow up with `ipa-certupdate`. (And why should they have to?) ``` a9ad3b5ab (Fraser Tweedale, 6 days ago) Run certupdate after promoting to CA-ful deployment After installing a CA in a CA-less installations (using ipa-ca-install), the new CA certificate is not installed in /etc/httpd/alias. This causes communication failure between IPA framework and Dogtag (it cannot verify the Dogtag server certificate). Perform a CertUpdate as the final step when promoting a CA-less deployment to CA-ful. Fixes: https://pagure.io/freeipa/issue/7230 21fbf7088 (Fraser Tweedale, 7 days ago) ipa-ca-install: run certupdate as initial step When installing a CA replica, perform a certupdate to ensure that the relevant CA cert is present. This is necessary if the admin has just promoted the topology from CA-less to CA-ful but didn't manually run ipa-certupdate afterwards. Fixes: https://pagure.io/freeipa/issue/6577 9520781fb (Fraser Tweedale, 7 days ago) CertUpdate: make it easy to invoke from other programs The guts of ipa-certupdate are useful to execute as part of other programs (e.g. as a first step of ipa-ca-install). Refactor ipa_certupdate.CertUpdate to make it easy to do that. In particular, make it possible to use an already-initialised API object. Part of: https://pagure.io/freeipa/issue/6577 ``` """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1232/head:pr1232 git checkout pr1232

2 1

[freeipa PR#1320][opened] ipatest: automation for bz-1493145
by mrizwan93 11 Dec '17

11 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1320 Author: mrizwan93 Title: #1320: ipatest: automation for bz-1493145 Action: opened PR body: """ This fix adds automation for above mentioned bugzilla. Fixes: https://pagure.io/freeipa/issue/7276 Signed-off-by: Mohammad Rizwan Yusuf <myusuf(a)redhat.com> """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1320/head:pr1320 git checkout pr1320

2 7

[freeipa PR#1347][opened] Prevent set_directive from clobbering other keys
by frasertweedale 08 Dec '17

08 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1347 Author: frasertweedale Title: #1347: Prevent set_directive from clobbering other keys Action: opened PR body: """ `set_directive` only looks for a prefix of the line matching the given directive (key). If a directive is encountered for which the given key is prefix, it will be vanquished. This occurs in the case of `{ca,kra}.sslserver.cert[req]`; the `cert` directive gets updated after certificate renewal, and the `certreq` directive gets clobbered. This can cause failures later on during KRA installation, and possibly cloning. Match the whole directive to avoid this issue. Fixes: https://pagure.io/freeipa/issue/7288 ----- Cause: corner case. How to test: 1. ensure `ca.sslserver.certreq=<base64 CSR>` exists in `ca/CS.cfg`. 2. resubmit Certmonger tracking request for `Server-Cert cert-pki-ca` Dogtag system cert. 3. verify that `ca.sslserver.certreq=<base64 CSR>` still exists in `ca/CS.cfg`. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1347/head:pr1347 git checkout pr1347

1 1

[freeipa PR#1294][opened] Trust avoid mitkrb trust
by abbra 07 Dec '17

07 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1294 Author: abbra Title: #1294: Trust avoid mitkrb trust Action: opened PR body: """ Quite often users choose wrong type of trust on Active Directory side when setting up a trust to freeIPA. The trust type supported by freeIPA is just a normal forest trust to another Active Directory. However, some people follow old internet recipes that force using a trust to MIT Kerberos realm. This is a wrong type of trust. Unfortunately, when someone used MIT Kerberos realm trust, there is no way to programmatically remote the trust from freeIPA side. As result, we have to detect such situation and report an error. To do proper reporting, we need reuse some constants and trust type names we use in IPA CLI/Web UI. These common components were moved to a separate ipaserver/dcerpc_common.py module that is imported by both ipaserver/plugins/trust.py and ipaserver/dcerpc.py. Fixes https://pagure.io/freeipa/issue/7264 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1294/head:pr1294 git checkout pr1294

1 1

[freeipa PR#1352][opened] [Backport][ipa-4-6] test_batch_plugin: fix py2/3 failing assertion
by tiran 07 Dec '17

07 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1352 Author: tiran Title: #1352: [Backport][ipa-4-6] test_batch_plugin: fix py2/3 failing assertion Action: opened PR body: """ This PR was opened automatically because PR #1345 was pushed to master and backport to ipa-4-6 is required. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1352/head:pr1352 git checkout pr1352

1 1

Re: [Freeipa-users] ipa-client-install (3.0.2 on Wheezy) fails after root certificate change via ipa-cacert-manage
by Harald Dunkel 06 Dec '17

06 Dec '17

repost on freeipa-devel: Hi folks, its always worth reading the code. ipa-client-install of freeipa 3.0.2 uses wget http://ipa1.example.de/ipa/config/ca.crt to grab the CA certificate. It seems that ipa-cacert-manage (CentOS 7.3) did not upgrade /usr/share/ipa/html/ca.crt on the servers when I migrated to the new root CA. Would anybody mind to fix? Thanx very much Harri On 11/16/17 9:28 AM, Harald Dunkel via FreeIPA-users wrote: > Hi folks, > > a few months ago I had replaced the externally signed root > certificate on my servers (CentOS 7.3) using ipa-cacert-manage. > Problem: > > ipa-client-install on a freshly bootstrapped Debian 7 (Wheezy, > freeipa 3.0.2) fails. Apparently it stumbles over the old root > certificate: > > # ipa-client-install --domain=example.de --realm=EXAMPLE.DE --no-ssh --no-sshd --no-ntp > Discovery was successful! > Hostname: pobde7i001.vs.example.de > Realm: EXAMPLE.DE > DNS Domain: example.de > IPA Server: ipa1.example.de > BaseDN: dc=example,dc=de > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. > Password for admin(a)EXAMPLE.DE: > Enrolled in IPA realm EXAMPLE.DE > Created /etc/ipa/default.conf > Domain example.de is already configured in existing SSSD config, creating a new one. > The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm EXAMPLE.DE > trying https://ipa1.example.de/ipa/xml > cert validation failed for "CN=ipa1.example.de,O=example AG,C=DE" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) > trying https://ipa2.example.de/ipa/xml > cert validation failed for "CN=ipa2.example.de,O=example AG,C=DE" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) > Cannot connect to the server due to generic error: cannot connect to Gettext('any of the configured servers', domain='ipa', localedir=None): https://ipa1.example.de/ipa/xml, https://ipa2.example.de/ipa/xml > Installation failed. Rolling back changes. > > > /etc/ipa/ca.crt on the client shows it somehow picked up the old > certificate. On the servers /etc/ipa/ca.crt is the new root cert. > "getcert list" on the servers shows only certificates based upon > the new root ca, too. I wonder where ipa-client-install picked up > the unwanted certificate? > > Of course I tried putting the new ca.crt into place before running > ipa-client-install, but it was overwritten. > > Of course there is no such problem for ipa 4.4.4 on Stretch. > > > Every heplful hint is highly appreciated > Harri > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org >

2 4

[freeipa PR#1338][opened] [Backport][ipa-4-6] tests: Mark failing tests as failing
by Tiboris 06 Dec '17

06 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1338 Author: Tiboris Title: #1338: [Backport][ipa-4-6] tests: Mark failing tests as failing Action: opened PR body: """ This PR was opened automatically because PR #1120 was pushed to master and backport to ipa-4-6 is required. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1338/head:pr1338 git checkout pr1338

1 1

[freeipa PR#1047][opened] Use the user-provided CA chain file in connections & check for file existence
by rcritten 04 Dec '17

04 Dec '17

URL: https://github.com/freeipa/freeipa/pull/1047 Author: rcritten Title: #1047: Use the user-provided CA chain file in connections & check for file existence Action: opened PR body: """ The user now may provide their own CA chain to the make API commands but it isn't honored. The value is also not checked for existence throwing a generic "no such file" error rather than "file <foo> doesn't exist" """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1047/head:pr1047 git checkout pr1047

1 1

[freeipa PR#1345][opened] test_batch_plugin: fix py2/3 failing assertion
by Rezney 30 Nov '17

30 Nov '17

URL: https://github.com/freeipa/freeipa/pull/1345 Author: Rezney Title: #1345: test_batch_plugin: fix py2/3 failing assertion Action: opened PR body: """ When running "test_batch_plugin" with Py2 against Py3 server we got assertion error due to a command trying to run as bytes. E.g.: unknown command 'b'ping'' ` E AssertionError: assert_deepequal: dict keys mismatch. E 0000: batch: Batch ping E missing keys = ['summary'] E extra keys = [u'error_code', u'error_kw', u'error_name'] E expected = {'error': None, E 'summary': Fuzzy('IPA server version .*', <type 'unicode'>, None)} E got = {u'error': u"unknown command 'b'ping''", E u'error_code': 905, E u'error_kw': {u'name': u"b'ping'"}, E u'error_name': u'CommandError'} E path = ('results', 0) ` """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1345/head:pr1345 git checkout pr1345

2 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-devel November 2017