For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!
I want to validate the column in IG when I modify the column value for update. For example I have Column in the name Amount in IG. When I change the amount value and click save button need to check the amount column value should exit 500.
Ok something is wrong with the following packges:
bind-pkcs11-9.11.4-26.P2.el8.x86_64.rpm
bind-pkcs11-libs-9.11.4-26.P2.el8.x86_64.rpm
bind-pkcs11-utils-9.11.4-26.P2.el8.x86_64.rpm
Using the Oracle 8.1 rpms produces this error using strace:
Can't load PKCS#11 provider: dlopen("pkcs11") failed: /lib64/pkcs11: cannot read file data: Is a directory
I make a force install of the CentOS Version of this rpm packages and the dlopen error went away.
"Exiting (due to fatal error)" is arguably not very useful information to work with. Programs often have fallback routines an these can show up as errors in "strace", but it does not necessarily mean that is causing your problem, unless it's the reason the software aborted. No one can look over your shoulder to see what you see or do exactly, or guess what Centos packages you have installed to make it work.
What kernel are you using? If you are using the UEK6 kernel, perhaps you should try using the RHEL 4.18 kernel to see if the problem persists. PKCS stands for "Public Key Cryptography Standard".
If you have Oracle Linux support, please open an SR for this so engineering can investigate.
Hi,
i am not using the UEK Kernel. Stock OL 8.1 Minimal Server install with IDM:DL1 Modulestream enabled. Because this issue is repeatable in every installation and not having a service contract i switched to CentOS for my IPA Servers. Under CentOS FreeIPA deployment is working.
I'm sorry to hear that. I will raise a bug for this internally myself though. Thanks for reporting it.
Perhaps you can share what instructions you used. I did the following and it also failed, albeit for a different reason or so it seems.
# uname -r
4.18.0-147.5.1.el8_1.x86_64
# yum -y update
# reboot
(this took quite a while)
4.18.0-147.8.1.el8_1.x86_64
# echo "10.0.80.101 ipa.example.com ipa" >> /etc/hosts
# hostnamectl set-hostname ipa.example.com
# yum -y module enable idm:DL1
# for SERVICES in ntp http https ldap ldaps kerberos kpasswd dns; do firewall-cmd --permanent --add-service=$SERVICES; done
# yum install freeipa-server ipa-server-dns
# systemctl restart chronyd
# ipa-server-install --setup-dns
Checking DNS domain example.com., please wait ...
DNS zone example.com. already exists in DNS and is handled by server(s): a.iana-servers.net., b.iana-servers.net.
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
2020-04-17T20:41:00Z DEBUG File "/usr/lib/python3.6/site-packages/ipapython/admintool.py", line 179, in execute
return_value = self.run()
File "/usr/lib/python3.6/site-packages/ipapython/install/cli.py", line 340, in run
return cfgr.run()
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 358, in run
self.validate()
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 368, in validate
etc....
Dude! wrote:Checking DNS domain example.com., please wait ...DNS zone example.com. already exists in DNS and is handled by server(s): a.iana-servers.net., b.iana-servers.net.The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
Dude! wrote:
You can't using an existing domain name (or if you do, your VM shouldn't be able to resolve it). example.com is a valid, real domain name on the Internet.
You'll also want to disable the ol8_UEK6 repo that's enabled by default after the dnf update, to avoid getting the newer user space packages that are required for UEK6.
I have reproduced the bug internally. I'll log it for engineering. Thanks!
This has been logged as Bug 31194343 internally. Thanks again for your contribution.
To add to this thread, the reported packages aren't the problem.
I've reinstalled the rpm bind-pkcs11-9.11.4-26.P2.el8.x86_64.rpm from CentOS-repository and that fixed it. Now named-pkcs11 starts succesfully.
Yes, the internal bug is logged against our build of bind-pkcs11. Thanks Andreas.
@Avi Miller Thank you very much!
@Dude! if you want to use existing domains or reverse zones you can use the --skip-overlap-check option to avoid the checks, i use this in split dns scenarios.
Perhaps it's also possible to use example.local or example.info, instead of example.com, but I simply tried to reproduce the error following your example.
Btw, posting a conclusion when reporting a problem is often not very useful. It is usually necessary to reproduce the error and analyze with own eyes. So info how you installed the software to reproduce the exact same error will help to find a solution.
@"Avi Miller-Oracle": Any updates on this bug? As Oracle Linux 8.2 has been released yesterday, I'd like to know if I can update to 8.2 or not or that I need to wait for CentOS 8.2 also.
I actually asked about this yesterday. The developer that was investigating was reassigned to a blocker bug for OL8U2 which (as you said) was released, so will now come back to looking at this, I believe. I don't have more details than that at this stage.
Any updates on the bug?
I've just tested this in a Virtual Box instance and Oracle 8.2 still fails with the same error unfortunately:
May 27 18:24:32 default-oracle-82 named-pkcs11[50102]: ----------------------------------------------------
May 27 18:24:32 default-oracle-82 named-pkcs11[50102]: adjusted limit on open files from 262144 to 1048576
May 27 18:24:32 default-oracle-82 named-pkcs11[50102]: found 2 CPUs, using 2 worker threads
May 27 18:24:32 default-oracle-82 named-pkcs11[50102]: using 1 UDP listener per interface
May 27 18:24:32 default-oracle-82 named-pkcs11[50102]: using up to 21000 sockets
May 27 18:24:32 default-oracle-82 named-pkcs11[50102]: initializing DST: no PKCS#11 provider
May 27 18:24:32 default-oracle-82 named-pkcs11[50102]: exiting (due to fatal error)
May 27 18:24:32 default-oracle-82 systemd[1]: named-pkcs11.service: Control process exited, code=exited status=1
May 27 18:24:32 default-oracle-82 systemd[1]: named-pkcs11.service: Failed with result 'exit-code'.
May 27 18:24:32 default-oracle-82 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.
[root@default-oracle-82 log]# /usr/sbin/named-pkcs11 -u named -c /etc/named.conf -d 5 -f
[root@default-oracle-82 log]# uname -r
5.4.17-2011.2.2.el8uek.x86_64
[root@default-oracle-82 log]# cat /etc/oracle-release
Oracle Linux Server release 8.2
[root@default-oracle-82 log]#
No updates yet. I have raised the priority of the bug internally.
New Security Update for bind including bind-pkcs11-9.11.13-5.el8_2.x86_64.rpm. Still broken
Sven Jansen wrote:New Security Update for bind including bind-pkcs11-9.11.13-5.el8_2.x86_64.rpm. Still broken
Sven Jansen wrote:
Yeah, I was afraid of that. Time for me to start sending more emails.
Any updates on this matter?
Yes, we released bind-pkcs11-9.11.13-5.0.1.el8_2 about 6 hours ago which resolves this issue. You posted about an hour before it was published.
Hi Avi,
i justed updated bind* on all my IPA Servers and i can confirm its working now! \o/
Sven Jansen wrote:i justed updated bind* on all my IPA Servers and i can confirm its working now! \o/
Awesome, glad to hear that. This took a surprising amount of time to debug, I'll be honest. It turned out to be an issue with our build environment that is configured to use our FIPS-validated OpenSSL libraries at all times, which confused the build of bind because having certain OpenSSL libraries available during build of bind-pkcs means it attempts to use those instead of its own and so-on and so-forth. We had to rebuild our build environments specifically for bind to accommodate it. Sorry about the delay!
I can also confirm it's working. Just updated my 2 IPA-servers and running OL8.2 now.
Thanks for following up on this and getting it fixed!
You're welcome! Thanks for your patience.
Regarding incomplete or not working IPA-packages and/or installation(s): there is something fishy about the ipa-healthcheck-package after installing OL8.2.
The package ipa-healthcheck-core in 8.2 obsoletes the package ipa-healtchcheck. But inside the (new) ipa-healthcheck 0.4 is the actual binary/script ipa-healthcheck missing. So upgrading ipa-healthcheck to 0.4 is uninstalling ipa-healtcheck (0.4) and installing ipa-healthcheck-core. But in the latter package, the actual check is missing, because it is located in ipa-healthcheck-0.4 (which is obsoleted by ipa-healthcheck-core-0.4. I guess there is missing a version in the obsoletes of ipa-healthcheck, because manually installing the ipa-healthcheck-0.4-RPM is fixing it.
So before:
ipa-healthcheck-0.3-4.module+el8.1.0+5409+d30b476c.noarch.rpm
After:
ipa-healthcheck-core-0.4-4.module+el8.2.0+5596+233bd6ae.noarch.rpm
During installation:
Installing group/module packages:
ipa-healthcheck-core noarch 0.4-4.module+el8.2.0+5596+233bd6ae ol8_appstream 49 k
replacing ipa-healthcheck.noarch 0.3-4.module+el8.1.0+5409+d30b476c
Missing:
ipa-healthcheck-0.4-4.module+el8.2.0+5596+233bd6ae.noarch.rpm
Trying to install it with dnf:
dnf install ipa-healthcheck
Last metadata expiration check: 0:22:26 ago on Fri 26 Jun 2020 02:16:16 PM CEST.
Package ipa-healthcheck-core-0.4-4.module+el8.2.0+5596+233bd6ae.noarch is already installed.
But downloading the RPM manually and installing it works perfectly fine and the command ipa-healthcheck is available again. Also installing the direct binary /usr/bin/ipa-healthcheck pulls it in...
dnf install /usr/bin/ipa-healthcheck
Dependencies resolved.
============================================================================================================================================================================================================================================
Package Architecture Version Repository Size
Installing:
ipa-healthcheck noarch 0.4-4.module+el8.2.0+5596+233bd6ae ol8_appstream 85 k
Transaction Summary
Install 1 Package
Clearing the dnf cache isn't fixing it. Anybody else having this issue?
Yeah, this is something we're inheriting from upstream, it seams. Looking at the .spec file, the new ipa-healthcheck-core package obsoletes ipa-healthcheck < 0.4. I'm guessing this is meant to be installed via a module update (it's 4:50am here, so I haven't had enough coffee to work through the process).
andreas.dijkman wrote: The package ipa-healthcheck-core in 8.2 obsoletes the package ipa-healtchcheck. But inside the (new) ipa-healthcheck 0.4 is the actual binary/script ipa-healthcheck missing. So upgrading ipa-healthcheck to 0.4 is uninstalling ipa-healtcheck (0.4) and installing ipa-healthcheck-core. But in the latter package, the actual check is missing, because it is located in ipa-healthcheck-0.4 (which is obsoleted by ipa-healthcheck-core-0.4. I guess there is missing a version in the obsoletes of ipa-healthcheck, because manually installing the ipa-healthcheck-0.4-RPM is fixing it.
andreas.dijkman wrote:
I'm assuming this is a weird upgrade side effect, because a new install pulls in the right packages, i.e. running the following gives me both the ipa-healthcheck and ipa-healthcheck-core packages installed:
# dnf module enable 389-ds pki-core pki-deps# dnf module install idm:DL1/server
# dnf module enable 389-ds pki-core pki-deps
# dnf module install idm:DL1/server
Perhaps you need to switch streams for the idm module?
Aside: I've noticed an issue with our module metadata for the adtrust, dns and server profiles of the idm:DL1 module stream that prevents "dnf module install idm:DL1/server" from working correctly. I've logged a bug internally, but you can workaround the issue by running "dnf module enable pki-core pki-deps 389-ds" first.
Correct. In RHEL 8.3 it's even a known issue: https://bugzilla.redhat.com/show_bug.cgi?id=1852244
Weirdly, it's fixed in CentOS 8. I tested that first and raised the internal bug based on that test, but then found our metadata matched RHEL so it's not actualy a regression from upstream.
I'm getting this in 8.5. Is this still a known issue?