FEDORA-2020-e9e815177e — bugfix update for freeipa

stable

freeipa-4.8.10-5.fc33

FEDORA-2020-e9e815177e created by abbra 4 years ago for Fedora 33

Upstream release FreeIPA 4.8.10

Release notes: https://www.freeipa.org/page/Releases/4.8.10

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2020-e9e815177e

This update has been submitted for testing by abbra.

4 years ago

This update's test gating status has been changed to 'ignored'.

4 years ago

This update's test gating status has been changed to 'waiting'.

4 years ago

This update's test gating status has been changed to 'ignored'.

4 years ago

abbra commented & provided feedback 4 years ago

Greenwave fails but OpenQA started testing this update as https://openqa.fedoraproject.org/tests/677717#. There is one failure in DNS upgrade code for which I filed upstream issue https://pagure.io/freeipa/issue/8518

abbra edited this update.

New build(s):

freeipa-4.8.10-2.fc33

Removed build(s):

freeipa-4.8.10-1.fc33

Karma has been reset.

4 years ago

abbra commented & provided feedback 4 years ago

A build freeipa-4.8.10-2.fc33 with PR https://github.com/freeipa/freeipa/pull/5153 succeeded in OpenQA where previous build freeipa-4.8.10-1.fc33 did fail.

This update has been pushed to testing.

4 years ago

abbra edited this update.

New build(s):

freeipa-4.8.10-3.fc33

Removed build(s):

freeipa-4.8.10-2.fc33

Karma has been reset.

4 years ago

This update has been submitted for testing by abbra.

4 years ago

This update has been pushed to testing.

4 years ago

cheimes commented & provided feedback 4 years ago

karma

FreeIPA server installation works for me.

Client-only installation does not pull in FreeIPA server packages.

systemd-resolved integration does not work correctly. resolved ignores the new drop-in configuration file.

# cat /etc/systemd/resolved.conf.d/zzz-ipa.conf 

# auto-generated by IPA installer
[Resolve]
# use local BIND instance
DNS=127.0.0.1
# make local BIND default DNS server, add search suffixes
Domains=~. ipa.example

resolvectl does neither show default DNS server 127.0.0.1 nor ipa.example default search domain.

# resolvectl 
Global
       LLMNR setting: resolve             
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
Fallback DNS Servers: 1.1.1.1             
                      8.8.8.8             
                      1.0.0.1             
                      8.8.4.4             
                      2606:4700:4700::1111
                      2001:4860:4860::8888
                      2606:4700:4700::1001
                      2001:4860:4860::8844
...

DNS lookup of ipa-ca alias with default resolver systemd-resolved does not work either:

# dig +nocomments ipa-ca.ipa.example.

; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc33 <<>> +nocomments ipa-ca.ipa.example.
;; global options: +cmd
;ipa-ca.ipa.example.            IN      A
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Sep 28 05:45:42 EDT 2020
;; MSG SIZE  rcvd: 47
# dig +nocomments @127.0.0.1 ipa-ca.ipa.example.

; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc33 <<>> +nocomments @127.0.0.1 ipa-ca.ipa.example.
; (1 server found)
;; global options: +cmd
;ipa-ca.ipa.example.            IN      A
ipa-ca.ipa.example.     86400   IN      A       10.0.139.100
ipa.example.            86400   IN      NS      host-10-0-139-100.ipa.example.
host-10-0-139-100.ipa.example. 86400 IN A       10.0.139.100
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Sep 28 05:46:01 EDT 2020
;; MSG SIZE  rcvd: 139

# rpm -qa systemd freeipa-server
systemd-246.4-2.fc33.x86_64
freeipa-server-4.8.10-3.fc33.x86_64

BZ#1880628 FreeIPA server doesn't get along well with systemd-resolved (need to manually disable it)

BZ#1883005 freeipa-selinux drags in server components on client

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

4 years ago

cheimes commented & provided feedback 4 years ago

/etc/systemd/resolved.conf.d was not accessible by systemd-resolved. PR https://github.com/freeipa/freeipa/pull/5156 fixes the problem.

abbra edited this update.

New build(s):

freeipa-4.8.10-4.fc33

Removed build(s):

freeipa-4.8.10-3.fc33

Karma has been reset.

4 years ago

This update has been submitted for testing by abbra.

4 years ago

This update has been pushed to testing.

4 years ago

abbra commented & provided feedback 4 years ago

This is not a full fix, sadly. Restoring SELinux context on a generated config file does not work. I added details to https://pagure.io/freeipa/issue/8518

abbra edited this update.

New build(s):

freeipa-4.8.10-5.fc33

Removed build(s):

freeipa-4.8.10-4.fc33

Karma has been reset.

4 years ago

This update has been submitted for testing by abbra.

4 years ago

This update has been pushed to testing.

4 years ago

This update can be pushed to stable now if the maintainer wishes

4 years ago

adamwill commented & provided feedback 4 years ago

As noted in the bug report, openQA tests passing was not indicative of the update working, because I had already put a workaround for the systemd-resolved problem in the openQA tests themselves: we simply check if systemd-resolved is enabled and disable it if so, reverting to how things worked before F33.

I've temporarily hacked the tests to skip that workaround if we're testing this specific update, and am re-running them. That should give us more useful results.

adamwill commented & provided feedback 4 years ago

karma

So looks like the replica test fails much the same way it did before I added the workaround :( That's with freeipa-4.8.10-5.fc33 .

BZ#1880628 FreeIPA server doesn't get along well with systemd-resolved (need to manually disable it)

abbra commented & provided feedback 4 years ago

Actually, the resolved support on the replica works just fine -- it is able to resolve master and communicate to it. What fails is resolution of the replica hostname from master:

Execute check on remote master
Check connection from master to remote replica 'ipa003.domain.local':
ERROR: Port check failed! Unable to resolve host name 'ipa003.domain.local'

Sadly, the logs we have collected from master do not include anything from /var/log or /etc/ so there is no way to understand what is broken.

abbra commented & provided feedback 4 years ago

Checking through the replica logs, it seems that master itself is not capable to talk to own DNS server (connection check runs on replica and asks to run the remote check from master too), so when a connection check is executed on master, that process didn't resolve replica hostname. I wonder if this was a master upgrade and perhaps systemd-resolved did its upgrade after IPA scripts were run, so actual upgrade in IPA didn't trigger migrating configuration to resolved.

adamwill commented & provided feedback 4 years ago

No. It's not an upgrade test. It's a fresh deployment test. This is exactly how it failed before you tried to deal with resolved. I know the failure is on the master, I think I mentioned that initially in the bug report.

Note, we have an ancillary problem now - upgrade from F32 to F33 doesn't work any more because F32's freeipa is now newer than F33's. We may have to push this anyway just to fix that problem.

adamwill commented & provided feedback 4 years ago

Filed https://bugzilla.redhat.com/show_bug.cgi?id=1886205 for that problem. Assuming it's accepted as a blocker (as it should be) I'd suggest we should edit this update so it's marked as fixing that bug but not fixing the resolved bug, and go ahead and push it.

abbra edited this update.

4 years ago

cheimes commented & provided feedback 4 years ago

karma

+1 for Adam's last proposal. Let's land this update while we work on a new update for #1880628

BZ#1883005 freeipa-selinux drags in server components on client

BZ#1886205 FreeIPA server upgrade from F32 to F33 doesn't work any more because F32's FreeIPA is newer

cheimes provided feedback 4 years ago

karma

This update has been submitted for stable by abbra.

4 years ago

abbra commented & provided feedback 4 years ago

I added bug 1886205 and submitted this to stable to unblock F32 to F33 situation. We'll do FreeIPA 4.8.11 release today/tomorrow that includes all fixes for systemd-resolved we done (more than this build contains).

fcami provided feedback 4 years ago

karma

adamwill commented & provided feedback 4 years ago

karma

With some tweaks to the test code (especially not touching resolv.conf) the replica tests do pass, so changing my feedback to positive. Let's just push this stable and pretend everything's fine!

BZ#1880628 FreeIPA server doesn't get along well with systemd-resolved (need to manually disable it)

BZ#1886205 FreeIPA server upgrade from F32 to F33 doesn't work any more because F32's FreeIPA is newer

This update has been pushed to stable.

4 years ago

Please login to add feedback.

Metadata

Type

bugfix

Severity

low

Karma

Signed

Content Type

RPM

Test Gating

ignored

Builds

freeipa-4.8.10-5.fc33

Settings

Unstable by Karma

-3

Stable by Karma

disabled

Stable by Time

disabled

Dates

submitted

4 years ago

in testing

4 years ago

in stable

4 years ago

modified

4 years ago

BZ#1880628 FreeIPA server doesn't get along well with systemd-resolved (need to manually disable it)

BZ#1883005 freeipa-selinux drags in server components on client

BZ#1886205 FreeIPA server upgrade from F32 to F33 doesn't work any more because F32's FreeIPA is newer

freeipa-4.8.10-5.fc33

Automated Test Results

ignored