Comments
amessina
I wish I was unable to provide additional detail, but after a day or so of running I've also had two Intel NUC machines x86_64 hit what seems like the arbitrary total lockup--machines not pingable, no logs or kernel oops' retreivable. I look forward to trying 5.14.8.
Update functions well. Noted duplication of HoldQuarantinedMessages section before and after IgnoreAuthenticatedClients in /etc/opendmarc.conf
## HoldQuarantinedMessages { true | false }
## default "false"
##
## If set, the milter will signal to the mta that messages with
## p=quarantine, which fail dmarc authentication, should be held in
## the MTA's "Hold" or "Quarantine" queue. The name varies by MTA.
## If false, messsages will be accepted and passed along with the
## regular mail flow, and the quarantine will be left up to downstream
## MTA/MDA/MUA filters, if any, to handle by re-evaluating the headers,
## including the Authentication-Results header added by OpenDMARC
#
# HoldQuarantinedMessages false
@kalvinist -- you are right -- thank you for the link.
New 1:30 boot delay noticed with this upgrade, though it may not be specifically related to the kernel. Occurs on Thinkpad X1 and several Intel NUCs:
Jul 02 21:33:36 systemd[1]: Found device /dev/mapper/fedora_ws1m-root.
Jul 02 21:33:36 systemd[1]: Reached target Initrd Root Device.
Jul 02 21:35:06 dracut-initqueue[895]: WARNING: D-Bus notification failed: Transport endpoint is not connected
Jul 02 21:35:06 systemd[1]: Found device /dev/mapper/fedora_ws1m-swap.
No negative Karma as otherwise general function seems unaffected.
Fixes #1943870
The multilib patch is missing the ending ":
which causes
/usr/bin/taglib-config: line 51: unexpected EOF while looking for matching `"'
@kevin I have been running the web interface for a number of years with a public cert (LetsEncrypt). Since Fedora 14, I had used a Kerberos-enabled Koji infrastructure rather than one based on certificates so I only needed the cert for the public interfaces (web, kojihub, etc.)
I'm just noting that KojiHubCA wasn't required before (even when using TLS) and now it is.
Generally functional, but is seems now that the web.conf KojiHubCA option is now required after: https://pagure.io/koji/c/74061d5d710155c0888c155df0ac3c0c40a96d41?branch=master
Maybe a sane default if not provided, like /etc/pki/tls/cert.pem would be nice.
The upgrade from freeipa-4.9.1-1.fc33 (https://bodhi.fedoraproject.org/updates/FEDORA-2021-f9332084e0) processed smoothly. I received the following afterward:
ns-slapd[3564]: [16/Feb/2021:14:51:42.716922896 -0600] - ERR - set_krb5_creds - The server will use the external SASL/GSSAPI credentials cache [FILE:/tmp/krb5cc_389]. If you want the server to automatically authenticate with its keytab, you must remove this cache. If you did not intend to use this cache, you will likely see many SASL/GSSAPI authentication failures.
Then restarted both of my FreeIPA instances and I haven't seen this again.
I confirm this resolves the high cpu issue on an upgraded F32->f33 FreeIPA system. Thank you.
Thank you!
Monitoring, but have not encountered the issue reported by @agurenko in #2055362. In my case, my NFS server is on kernel-5.16.9-200.fc35.x86_64, my NFS clients are on kernel-5.16.10-200.fc35.x86_64, and both server and clients have nfs-utils-2.5.4-2.rc3.fc35.x86_64.