See subject... I have 3 CentOS 7 VMs running as FreeIPA Servers.
I ran a standard "yum update" as root; these packages were included as part of that update: bind.x86_64 32:9.11.4-26.P2.el7_9.16 bind-dyndb-ldap.x86_64 11.1-7.el7_9.1 bind-export-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-libs-lite.x86_64 32:9.11.4-26.P2.el7_9.16 bind-license.noarch 32:9.11.4-26.P2.el7_9.16 bind-pkcs11.x86_64 32:9.11.4-26.P2.el7_9.16 bind-pkcs11-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-pkcs11-utils.x86_64 32:9.11.4-26.P2.el7_9.16 bind-utils.x86_64 32:9.11.4-26.P2.el7_9.16
Previously, bind-dyndb-ldap had been on 11.1-7.el7 (no "_9.1" suffix) And the rest had been on the exact same versions as above, but ending in .15.
After the upgrade, named-pkcs11 crashes when started by systemctl, with the following journalctl output (server domain has been anonymized but everything else was untouched):
Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: ../../../lib/dns-pkcs11/name.c:1114: REQUIRE((target != ((void *)0) && (__builtin_expect(!!((target) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(target))->magic == (0x42756621U)), 1))) || (target == ((void *)0) && (__builtin_expect(!!((name->buffer) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(name->buffer))->magic == (0x42756621U)), 1)))) failed, back trace Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #0 0x561df47e5130 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #1 0x7fac0362b48a in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #2 0x7fac03930b7b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #3 0x7fabfb6efb78 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #4 0x7fabfb6effee in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #5 0x7fabfb6f198b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #6 0x7fabfb6f1b89 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #7 0x7fabfb6fb528 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #8 0x7fac03650713 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #9 0x7fac0365128b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #10 0x7fac01726ea5 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #11 0x7fac00799b0d in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: exiting (due to assertion failure) Jul 02 19:39:19 ipa3.example.net systemd[1]: named-pkcs11.service: main process exited, code=killed, status=6/ABRT Jul 02 19:39:19 ipa3.example.net systemd[1]: Unit named-pkcs11.service entered failed state. Jul 02 19:39:19 ipa3.example.net systemd[1]: named-pkcs11.service failed.
I was able to get named to start again by running a "yum downgrade" of the above list of bind-related packages. Obviously, now the server is "behind" on patches though. I'm not sure how to report this further to get it investigated/fixed, or if any action will even be taken at this point now that CentOS7 is EOL.
I'm happy to provide additional details if requested.
Regards, Braden McGrath braden@big-geek.net
Braden McGrath via FreeIPA-users wrote:
See subject... I have 3 CentOS 7 VMs running as FreeIPA Servers.
I ran a standard "yum update" as root; these packages were included as part of that update: bind.x86_64 32:9.11.4-26.P2.el7_9.16 bind-dyndb-ldap.x86_64 11.1-7.el7_9.1 bind-export-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-libs-lite.x86_64 32:9.11.4-26.P2.el7_9.16 bind-license.noarch 32:9.11.4-26.P2.el7_9.16 bind-pkcs11.x86_64 32:9.11.4-26.P2.el7_9.16 bind-pkcs11-libs.x86_64 32:9.11.4-26.P2.el7_9.16 bind-pkcs11-utils.x86_64 32:9.11.4-26.P2.el7_9.16 bind-utils.x86_64 32:9.11.4-26.P2.el7_9.16
Previously, bind-dyndb-ldap had been on 11.1-7.el7 (no "_9.1" suffix) And the rest had been on the exact same versions as above, but ending in .15.
After the upgrade, named-pkcs11 crashes when started by systemctl, with the following journalctl output (server domain has been anonymized but everything else was untouched):
Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: ../../../lib/dns-pkcs11/name.c:1114: REQUIRE((target != ((void *)0) && (__builtin_expect(!!((target) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(target))->magic == (0x42756621U)), 1))) || (target == ((void *)0) && (__builtin_expect(!!((name->buffer) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(name->buffer))->magic == (0x42756621U)), 1)))) failed, back trace Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #0 0x561df47e5130 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #1 0x7fac0362b48a in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #2 0x7fac03930b7b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #3 0x7fabfb6efb78 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #4 0x7fabfb6effee in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #5 0x7fabfb6f198b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #6 0x7fabfb6f1b89 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #7 0x7fabfb6fb528 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #8 0x7fac03650713 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #9 0x7fac0365128b in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #10 0x7fac01726ea5 in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: #11 0x7fac00799b0d in ?? Jul 02 19:39:19 ipa3.example.net named-pkcs11[10794]: exiting (due to assertion failure) Jul 02 19:39:19 ipa3.example.net systemd[1]: named-pkcs11.service: main process exited, code=killed, status=6/ABRT Jul 02 19:39:19 ipa3.example.net systemd[1]: Unit named-pkcs11.service entered failed state. Jul 02 19:39:19 ipa3.example.net systemd[1]: named-pkcs11.service failed.
I was able to get named to start again by running a "yum downgrade" of the above list of bind-related packages. Obviously, now the server is "behind" on patches though. I'm not sure how to report this further to get it investigated/fixed, or if any action will even be taken at this point now that CentOS7 is EOL.
I'm happy to provide additional details if requested.
Regards, Braden McGrath braden@big-geek.net
It appears that the centos 7 builds were done incorrectly. Given it is EOL it is not likely to be addressed. We have little influence in centos.
rob
Rob Crittenden wrote:
It appears that the centos 7 builds were done incorrectly. Given it is EOL it is not likely to be addressed. We have little influence in centos. rob
Ugh, that's what I was a little afraid of. Guess it's just that much more of a reason I need to migrate to new servers. I saw your post/reply elsewhere on this list to someone asking how to migrate/upgrade, linking to official RHEL8 docs.
Unfortunately my non-profit doesn't have the money for RHEL, so I was looking at either Rocky or Alma, because trying to run FreeIPA Server on top of Ubuntu/Debian just feels wrong and fraught with peril. FreeIPA-client seems to work OK-enough on .deb systems but I'd be afraid of trying to run the Server side there... or is this a completely unfounded and stupid fear? (The org is almost 100% Ubuntu, with the exception of our FreeIPA VMs and two business apps that require CentOS7.)
I'm guessing that the process to move from CentOS7 over to Alma or Rocky would be pretty similar to the "non RHEL7 to RHEL8" procedure?
Regards, Braden
On 04/07/2024 00:17, Braden McGrath via FreeIPA-users wrote:
Rob Crittenden wrote:
It appears that the centos 7 builds were done incorrectly. Given it is EOL it is not likely to be addressed. We have little influence in centos. rob
Ugh, that's what I was a little afraid of. Guess it's just that much more of a reason I need to migrate to new servers. I saw your post/reply elsewhere on this list to someone asking how to migrate/upgrade, linking to official RHEL8 docs.
Unfortunately my non-profit doesn't have the money for RHEL, so I was looking at either Rocky or Alma, because trying to run FreeIPA Server on top of Ubuntu/Debian just feels wrong and fraught with peril. FreeIPA-client seems to work OK-enough on .deb systems but I'd be afraid of trying to run the Server side there... or is this a completely unfounded and stupid fear? (The org is almost 100% Ubuntu, with the exception of our FreeIPA VMs and two business apps that require CentOS7.)
FreeIPA has a lot of complex parts and RHEL is the platform where they are most comprehensively tested together. Additionally, on RHEL you also have SELinux locking down what those components are able to do if misconfigured or exploited.
As a result, I'd definitely run FreeIPA on Alma or another RHEL derivative if I wasn't able to run it on RHEL.
As a non-profit, there may be options open to you that are cheaper than list price if you enquire. Red Hat's support has definitely paid for itself, and then some compared to if we'd gone without.
(For context, my employer is a Red Hat customer. I am not personally or professionally affiliated with Red Hat).
I'm guessing that the process to move from CentOS7 over to Alma or Rocky would be pretty similar to the "non RHEL7 to RHEL8"
Should be - I had no problem going the other way (CentOS -> RHEL) for my personal domain.
On Wed, 03 Jul 2024, Braden McGrath via FreeIPA-users wrote:
Rob Crittenden wrote:
It appears that the centos 7 builds were done incorrectly. Given it is EOL it is not likely to be addressed. We have little influence in centos. rob
Ugh, that's what I was a little afraid of. Guess it's just that much more of a reason I need to migrate to new servers. I saw your post/reply elsewhere on this list to someone asking how to migrate/upgrade, linking to official RHEL8 docs.
Unfortunately my non-profit doesn't have the money for RHEL, so I was looking at either Rocky or Alma, because trying to run FreeIPA Server on top of Ubuntu/Debian just feels wrong and fraught with peril. FreeIPA-client seems to work OK-enough on .deb systems but I'd be afraid of trying to run the Server side there... or is this a completely unfounded and stupid fear? (The org is almost 100% Ubuntu, with the exception of our FreeIPA VMs and two business apps that require CentOS7.)
If you are interested in the support, it still makes sense to talk to Red Hat people because there are often ways to get substantial discounts. IPA support is included into standard RHEL subscription support.
With Rocky or AlmaLinux I am not aware of any specific support for IPA. May be companies behind those projects provide something similar in their commercial offerings but I am not sure. The only venue you'd be open to is this mailing list. From my experience, Alma/Rocky do rebuilds of what comes from CentOS Stream or RHEL and they hardly test those rebuilds beyond basic installation. We know that because AlmaLinux 8.10 builds are broken right now as can be seen in a separate thread.
With Ubuntu or Debian it is pretty much the same or even worse because there is a single maintainer heroically uplifting the whole set of packages.
I'm guessing that the process to move from CentOS7 over to Alma or Rocky would be pretty similar to the "non RHEL7 to RHEL8" procedure?
No. AlmaLinux attempts to be RHEL compatible so you need to look into 'RHEL 7 to RHEL 8' migration documentation.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Braden McGrath -
Rob Crittenden -
Sam Morris