Comments

996 Comments

This update is not installable on top of current stable F29:

Problem: package crypto-policies-20190527-1.git0b3add8.fc29.noarch conflicts with nss < 3.44.0 provided by nss-3.43.0-1.fc29.x86_64 - cannot install the best update candidate for package nss-3.43.0-1.fc29.x86_64 - cannot install the best update candidate for package crypto-policies-20190211-2.gite3eacfc.fc29.noarch

It should have been included in the NSS update (https://bodhi.fedoraproject.org/updates/FEDORA-2019-e2f5e10754 ) rather than being submitted as a separate update, or not submitted until that update went stable.

Please do not push this until that update has gone stable.

This breaks the installer in live images with initial-setup included. Most live respins rebuilt with this version will be broken.

Ah, OK - if you were already on top of this, that's fine, I just wanted to be sure :)

For future reference: when creating an update through the webUI you can include multiple builds when you create it, and/or you can also edit an existing update and add new builds to it, so long as those builds are not already in another update. I'm not sure offhand how to do it with the CLI as I don't usually create updates that way, but it's probably possible.

karma

This and https://bodhi.fedoraproject.org/updates/FEDORA-2019-afc9c91690 (the corresponding 'fuse' package update) should not have been submitted separately, as this creates a dependency problem if that update is pushed stable before this one. They should have been submitted together. I am -1ing both updates to ensure they cannot be submitted for stable automatically in the wrong order. Please ensure you push this one stable manually first, then once it has gone stable, push the fuse update stable.

karma

This and https://bodhi.fedoraproject.org/updates/FEDORA-2019-3b403286dc (the corresponding 'fuse' package update) should not have been submitted separately, as this creates a dependency problem if that update is pushed stable before this one. They should have been submitted together. I am -1ing both updates to ensure they cannot be submitted for stable automatically in the wrong order. Please ensure you push this one stable manually first, then once it has gone stable, push the fuse update stable.

This and https://bodhi.fedoraproject.org/updates/FEDORA-2019-723856770a (the corresponding 'fuse3' package update) should not have been submitted separately, as this creates a dependency problem if this update is pushed stable before that one. They should have been submitted together. I am -1ing both updates to ensure they cannot be submitted for stable automatically in the wrong order. Please ensure you push the other one stable manually first, then once it has gone stable, push this fuse update stable.

karma

This and https://bodhi.fedoraproject.org/updates/FEDORA-2019-2dbe0563ea (the corresponding 'fuse3' package update) should not have been submitted separately, as this creates a dependency problem if this update is pushed stable before that one. They should have been submitted together. I am -1ing both updates to ensure they cannot be submitted for stable automatically in the wrong order. Please ensure you push the other one stable manually first, then once it has gone stable, push this fuse update stable.

karma

This and https://bodhi.fedoraproject.org/updates/FEDORA-2019-78fff2916e (the corresponding 'fuse3' package update) should not have been submitted separately, as this creates a dependency problem if this update is pushed stable before that one. They should have been submitted together. I am -1ing both updates to ensure they cannot be submitted for stable automatically in the wrong order. Please ensure you push the other one stable manually first, then once it has gone stable, push this fuse update stable.

karma

This and https://bodhi.fedoraproject.org/updates/FEDORA-2019-44ac6082f0 (the corresponding 'fuse' package update) should not have been submitted separately, as this creates a dependency problem if that update is pushed stable before this one. They should have been submitted together. I am -1ing both updates to ensure they cannot be submitted for stable automatically in the wrong order. Please ensure you push this one stable manually first, then once it has gone stable, push the fuse update stable.

karma

openQA test failures indicate a genuine bug in this update: the 'fuse' package is not installable.

- nothing provides fuse-common >= 3.4.2-4 needed by fuse-2.9.9-7.fc29.x86_64

Either the fuse and fuse3 packages should have been included in a single update, or this one should not have been submitted till the fuse3 update was pushed stable. Pending updates are meant to be internally complete, they should not interdepend like this.

karma

Appears to be missing a pykickstart build:

"- nothing provides python3-kickstart >= 3.19 needed by lorax-29.28-1.fc29.x86_64"

Or else, of course, that dependency is not accurate for this update, and so the dependency should be changed. Either way, the package is not installable.

Test Case lorax netinst

"Do not obsolete createrepo on Fedora < 31"

This change does not exactly have the intended effect. There is still createrepo_c-0.12.2-1.fc29 in the stable F29 repo which does obsolete and provide createrepo. So if you have createrepo installed and you upgrade to F29...it still gets removed and replaced with createrepo_c-0.12.2-1.fc29. Then on the next update, that package will be updated to this version...so the change is sort of a no-op.

karma

I think this actually broke FreeIPA. See the openQA test results: there are several failures. Now it's been pushed stable, I've seen the tests fail for another update, a Firefox update which clearly couldn't be breaking tests that don't involve a browser: https://openqa.fedoraproject.org/tests/overview?distri=fedora&version=28&build=Update-FEDORA-2019-34f798420a&groupid=2 . It seems that login as a test user at a console (which should work) fails. Will look into it a bit more.

karma

openQA tests look a lot like FEDORA-2019-f791948895 broke FreeIPA on upgrade from F29 to F30, and this fixes it. So, giving it +1.

With my web font fix in -3, the openQA tests now pass. Still, is it really appropriate to send a 4.8 pre-release as an update to F30, now F30 is a stable release?

https://openqa.stg.fedoraproject.org/tests/533861/file/role_deploy_domain_controller_check-named.run is a named.run from a run of this test, not sure if it contains what you need. Note that the server logs are being uploaded sort of while the client tests are running; for boring openQA implementation reasons it is difficult to get the logs after the client tests fail. The logs may be from just after one of the clients tries to enrol, or just before; I'll check timestamps and figure out which this was in a bit.

because why put log files into /var/log, that would be so boring and conventional...sigh

Adding --no-dnssec-validation does not seem to help. Exact command tested was ipa-server-install -U --realm=DOMAIN.LOCAL --domain=domain.local --ds-password=monkeys123 --admin-password=monkeys123 --setup-dns --reverse-zone=2.0.10.in-addr.arpa --allow-zone-overlap --forwarder=10.5.126.21 --forwarder=10.5.126.22 --no-dnssec-validation. Client tests still failed. Will get that log file.

The server claims to be running fine, but the client claims not to be able to register with it. Someone's lying! Client logs show this:

Apr 29 17:00:52 client003.domain.local systemd[1]: Started Realm and Domain Configuration.
Apr 29 17:00:52 client003.domain.local realmd[900]: claimed name on bus: org.freedesktop.realmd
Apr 29 17:00:52 client003.domain.local realmd[900]: client using service: :1.19
Apr 29 17:00:52 client003.domain.local realmd[900]: holding daemon: :1.19
Apr 29 17:00:52 client003.domain.local realmd[900]: Using 'r477.897' operation for method 'Discover' invocation on 'org.freedesktop.realmd.Provider' interface
Apr 29 17:00:52 client003.domain.local realmd[900]: Registered cancellable for operation 'r477.897'
Apr 29 17:00:52 client003.domain.local realmd[900]:  * Resolving: _ldap._tcp.ipa001.domain.local
Apr 29 17:00:52 client003.domain.local realmd[900]:  * Resolving: _ldap._tcp.ipa001.domain.local
Apr 29 17:00:52 client003.domain.local realmd[900]: Resolving ipa001.domain.local failed: No DNS record of the requested type for “_kerberos._udp.ipa001.domain.local”
Apr 29 17:00:52 client003.domain.local realmd[900]: No DNS record of the requested type for “_ldap._tcp.ipa001.domain.local”
Apr 29 17:00:52 client003.domain.local realmd[900]:  * Resolving: ipa001.domain.local
Apr 29 17:00:52 client003.domain.local realmd[900]:  * Resolving: ipa001.domain.local
Apr 29 17:00:52 client003.domain.local realmd[900]: Resolving ipa001.domain.local failed: No DNS record of the requested type for “_kerberos._tcp.ipa001.domain.local”
Apr 29 17:00:52 client003.domain.local realmd[900]:  * Performing LDAP DSE lookup on: 10.0.2.100
Apr 29 17:00:52 client003.domain.local realmd[900]:  * Performing LDAP DSE lookup on: 10.0.2.100
Apr 29 17:00:52 client003.domain.local realmd[900]: Searching  for (objectClass=*)
Apr 29 17:00:52 client003.domain.local realmd[900]: Got defaultNamingContext: dc=domain,dc=local
Apr 29 17:00:52 client003.domain.local realmd[900]: Searching dc=domain,dc=local for (objectClass=*)
Apr 29 17:00:52 client003.domain.local realmd[900]: Couldn't read default naming context
Apr 29 17:00:52 client003.domain.local realmd[900]:  ! Couldn't lookup domain name on LDAP server
Apr 29 17:00:52 client003.domain.local realmd[900]:  ! Couldn't lookup domain name on LDAP server
Apr 29 17:00:52 client003.domain.local realmd[900]: client gone away: :1.19
Apr 29 17:00:52 client003.domain.local realmd[900]: released daemon: :1.19

Server logs show more or less a successful server deployment, but also these errors...

Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: unsupported operation: object class in resource record template DN 'idnsname=_ldap._tcp,idnsname=domain.local.,cn=dns,dc=domain,dc=local' changed: rndc reload might be necessary
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: unsupported operation: object class in resource record template DN 'idnsname=_kerberos._tcp,idnsname=domain.local.,cn=dns,dc=domain,dc=local' changed: rndc reload might be necessary
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: unsupported operation: object class in resource record template DN 'idnsname=_kerberos._udp,idnsname=domain.local.,cn=dns,dc=domain,dc=local' changed: rndc reload might be necessary
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: unsupported operation: object class in resource record template DN 'idnsname=_kerberos-master._tcp,idnsname=domain.local.,cn=dns,dc=domain,dc=local' changed: rndc reload might be necessary
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: unsupported operation: object class in resource record template DN 'idnsname=_kerberos-master._udp,idnsname=domain.local.,cn=dns,dc=domain,dc=local' changed: rndc reload might be necessary
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: unsupported operation: object class in resource record template DN 'idnsname=_kpasswd._tcp,idnsname=domain.local.,cn=dns,dc=domain,dc=local' changed: rndc reload might be necessary
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: unsupported operation: object class in resource record template DN 'idnsname=_kpasswd._udp,idnsname=domain.local.,cn=dns,dc=domain,dc=local' changed: rndc reload might be necessary
Apr 29 16:59:42 ipa001.domain.local named-pkcs11[8441]: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown class/type
Apr 29 16:59:42 ipa001.domain.local systemd[1]: Reloading.
...
Apr 29 16:59:44 ipa001.domain.local generate-rndc-key.sh[8691]: /usr/libexec/generate-rndc-key.sh: line 3: /etc/rc.d/init.d/functions: No such file or directory
Apr 29 16:59:44 ipa001.domain.local systemd[1]: named-setup-rndc.service: Succeeded.
Apr 29 16:59:44 ipa001.domain.local systemd[1]: Started Generate rndc key for BIND (DNS).

which I guess may be related here? It does seem like some kind of DNS problem.

Fails openQA testing - see links on Automated Tests tab. I haven't investigated the cause yet.