Comments

77 Comments
User Icon abbra commented & provided feedback on krb5-1.17-46.fc31 12 days ago
karma

FreeIPA-specific tests passed just fine -- there were AVCs in the upgrade path but these are related to abrtd daemon and seems to be independent of either Kerberos update or FreeIPA operations.

Thank you, @adamwill, new build works fine.

I'm flying back to Finland from USA tonight and most likely will not have time to do the fix myself (on the phone now). Feel free to submit the fix upstream (and add it to the fedora builds), we'll handle that next week.

karma
BZ#1698384 ipa-kra-install fails due to fs.protected_regular=1
BZ#1699109 Occasional 'whoami.data is undefined' error in FreeIPA web UI
BZ#1731433 ipa service-find does not list cifs service created by ipa-client-samba
BZ#1746557 ipa-client-install calls "authselect select sssd --force" at uninstall time before restoring user-nsswitch.conf
BZ#1746882 dnf builddep freeipa, wrong libdir for current arch
BZ#1759495 No SELinux context for /etc/named directory
BZ#1759495 No SELinux context for /etc/named directory
karma

LGTM

User Icon abbra commented & provided feedback on jss-4.6.2-2.fc30 3 months ago
karma

works for me.

BZ#1766451 Intermittent null pointer exception in JSS during FreeIPA deployments

FreeIPA 4.8 pre-release went through extensive testing in past three months in upstream PR-CI. The tests we saw failing here were the only ones we didn't test. We had intention to add FreeIPA 4.8 to Fedora 30 since the very beginning.

I backed off the change that set default for minimum SSF value to 56. With it, realmd was unable to validate IPA server discovery as it uses only anonymous LDAP connection.

In order to get more insights what happens, we need /var/named/data/named.run log. It is not included into artifacts, unfortunately.

I think this failure is due to the test running with DNSSEC validation but named-pkcs11 failing to validate the path to root nameservers and disabling it:

Apr 29 17:02:26 ipa001 named-pkcs11[1071]: insecurity proof failed resolving 'arm.fedoraproject.org/A/IN': 10.5.126.21#53
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: insecurity proof failed resolving 'arm.fedoraproject.org/AAAA/IN': 10.5.126.21#53
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: insecurity proof failed resolving 'arm.fedoraproject.org/A/IN': 10.5.126.22#53
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: insecurity proof failed resolving 'arm.fedoraproject.org/AAAA/IN': 10.5.126.22#53
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: validating fedoramagazine.org/A: no valid signature found
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: validating fedoramagazine.org/AAAA: no valid signature found
Apr 29 17:02:26 ipa001 named-pkcs11[1071]:  validating getfedora.org/SOA: no valid signature found
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: validating getfedora.org/A: no valid signature found
Apr 29 17:02:26 ipa001 named-pkcs11[1071]:  validating getfedora.org/NSEC: no valid signature found
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: validating creativecommons.org/A: no valid signature found
Apr 29 17:02:26 ipa001 named-pkcs11[1071]: validating creativecommons.org/AAAA: no valid signature found
Apr 29 17:06:17 ipa001 named-pkcs11[1071]: validating getfedora.org/A: no valid signature found

It doesn't allow external clients to resolve through itself then. You need to add --no-dnssec-validation to ipa-server-install to disable DNSSEC validation.

@mtasaka thanks! I've rebuilt against -14.fc30

@mtasaka I added a Samba rebuild that should fix this problem.

@lslebodn, freeipa-4.2.7-8.fc30 should solve your problem with #1696963.

BZ#1691115 Samba's testsuite requires python subunit.tests
BZ#1691115 Samba's testsuite requires python subunit.tests

Both this and F29 update failed in OpenQA because somehow packages weren't installed for a test -- openqa did download them and built a local repository but dnf didn't consider them for upgrade. This is pretty weird because they should have been upgraded at least from rpm point of view:

$ rpmdev-vercmp 
  Epoch1: 0
  Version1: 4.7.2
  Release1: 1.fc28
  Epoch2: 0
  Version2: 4.7.2
  Release2: 1.1.fc28
  0:4.7.2-1.fc28 < 0:4.7.2-1.1.fc28

The actual issue can be seen at this step: https://openqa.fedoraproject.org/tests/354931#step/_advisory_update/29