Hide Forgot
Paul reported this problem to me. The %post script of ca-certificates calls the ca-legacy utility, which uses "ln". Because of the circular dependency, Paul said, ln is missing. Paul, you didn't say how exactly you noticed this issue, and what symptoms you saw. Are you able to provide more details? Did this happen at system install time? Do you have a broken system? Did you see errors on upgrading/downgrading? Please, any additional details will be helpful to understand what workarounds might be necessary to production systems. The purpose of ln as used by legacy is to select between two alternative installed subsets of the shipped CAs, by setting a symbolic link to the file containing the selected choice. If ln doesn't work at install time, no symbolic link will be set, and none of the CAs having the legacy status will be used on the system. I think the problem is fixed any time the package gets installed or updated again. So the question really is: Can we find any system, particularly immediately after installing, where the following file (link) doesn't exist? /etc/pki/ca-trust/source/ca-bundle.legacy.crt
NI for Paul: See the prev comment. How did you discover the bug? What symptoms did you see? Any other details?
NI for Hubert: Could QE help to check if on a newly installed RHEL 7.2 system, or RHEL 6.7 system, if the following is missing? /etc/pki/ca-trust/source/ca-bundle.legacy.crt
And another question is, what can I use as a workaround, if it's broken? ln should have minimal deps. ln shouldn't depend on crypto libs.
I was informed by Tuomo, whom I have added to the CC: to answer the question.
My findings originate on this mock root.log line: DEBUG util.py:393: /usr/bin/ca-legacy: line 38: ln: command not found After some debugging I found out ca-certificates is indirect dependency of coreutils so ca-certificates can't depend on coreutils - and that means it's %post scriptlet can't use any command from coreutils because that would create a cyclic dependency loop. coreutils depends on openssl-libs which depends on ca-certificates. This %post scriptlet hack by Kim Heino <b> works around the problem: %post -p <lua> if posix.access("/usr/bin/ln", "x") then os.execute("/usr/bin/ca-legacy install") else if not posix.access("/etc/pki/ca-trust/source/ca-bundle.legacy.crt", "r") then posix.symlink("/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt", "/etc/pki/ca-trust/source/ca-bundle.legacy.crt") end end os.execute("/usr/bin/update-ca-trust")
Could OrderWithRequires: be used to hide this?
(In reply to Pat Riehecky from comment #7) > Could OrderWithRequires: be used to hide this? Never mind, I should read more closely. OrderWithRequires will not help.
Thanks Hubert. So, why does it work anyway? :-) Maybe the system installation runs the rpm scripts multiple times?
Looking at the logfiles that Hubert provided. On RHEL 6.8, coreutils and coreutils-libs don't require crypto. At the time ca-certificates got installed, coreutils were already installed. On the RHEL 7.2 machine, I couldn't find an installation logfile.
Tuomo, thanks a lot for providing that workaround!
Hubert, do you know where a RHEL 7 machine has a logfile of the package installation process?
I looked at Tuomo's suggestion from comment 6 more closely. The suggestion was, if "ln" is missing: duplicate functionality from the ca-legacy script into the ca-certificates.spec script. I don't like the idea to have functionality in multiple places. So, my first idea was to change ca-legacy to instead call a standalone lua script. But the posix call seems to require an additional lua-posix package on Fedora, and having to add more dependencies seems unfortunate. After more searching, I found a potentially better workaround. I found that the glibc package contains a minimal "sln" utility, which is statically linked, and is intended for minimal environments. I suggest to change the ca-legacy script to use sln (not ln).
Besides the %post script, the "ln" command is also used directly in the %install script. I guess it's better to use sln everywhere. I see that the "sln" command also overwrites preexisting files. The ca-legacy utility forces link creation, "ln -sf", so using sln directly is trivial. The ca-certificates.spec file uses soft creation. So, in order to not change existing behavior, I'll change the %install script to test if a file already exist, and only if no file exists yet, run sln.
(In reply to Kai Engert (:kaie) from comment #19) > > The ca-certificates.spec file uses soft creation. So, in order to not change > existing behavior, I'll change the %install script to test if a file already > exist, and only if no file exists yet, run sln. I realize that's not necessary, because that's used to install links inside the buildroot, so we can just use sln unconditionally.
Out of curiosity, why OrderWithRequires won't help here? Circular dependencies are IMHO not a problem as simple Requires doesn't imply that the package will be installed before its consumer. That's the purpose of OrwerWithRequires. My understanding of the situation is: coreutils requires openssl-libs openssl-libs requires ca-certificates ca-certificates requires coreutils AFAIK such dependencies would just imply that all 3 packages are added into a transaction in "not really deterministic" order. Therefore sometime it could work and sometimes not (depends also on other packages within the same transaction). The only package out of the above that really needs the other packages to be installed (due to its scriptlet) is ca-certificates. Therefore OrderWithRequires: coreutils in the ca-certificates package should do the job. Or am I missing something?
Hi Kai, after thinking a bit about the topic I am not sure whether the fix is appropriate. You have removed the dependency on coreutils but actually you are using other commands (such as rm) in the postuninstall scriptlet anyway and in the SPEC file too. As I can't imagine a running system without the coreutils package this probably won't be a real problem. Also "test" command is shipped in coreutils, OTOH the bash built in function is used primarily so this is not an issue. I will leave it up on to your judgement whether you want to alter the fix as the current solution could be the best what we can do ATM anyway.
Hi Karel, thanks for your review. After a bit of review and asking around: The use of "rm" in the spec file is limited to the package build parts %prep, %install, %clean and in the package build environment, I may assume that coreutils is present, without listing it as a requirement. But the use of "test" that you identified is indeed an issue, because it's currently used by the %pre script, and could face the same issue as "ln". I should be able to eliminate the use of "test" by using the equivalent bash expressions.
More good news. The "test" command is built-in to bash. I believe the "if test" expressions in the %pre script are executed by bash directly, without involving/starting the /bin/test program. That also explains, why no problems with "test" have been reported. Karel, you you please set to VERIFIED again?
(In reply to Kai Engert (:kaie) from comment #26) > The "test" command is built-in to bash. I believe the "if test" expressions > in the %pre script are executed by bash directly, without involving/starting > the /bin/test program. I know. I did say it, didn't I? :-) > Karel, you you please set to VERIFIED again? Done.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2320.html