fetch-crl does not work on EL9 due to hidden dependency

[rptaylor]

Hi @dlgroep Are there still any supported RPM-based operating systems that do not use systemd, or that do use SysV ? I see that fetch-crl still relies on SysV init scripts.

On EL9 it does not work:

$ sudo systemctl status fetch-crl-cron
× fetch-crl-cron.service - LSB: Run the certificate revocation lists update periodically via cron
     Loaded: loaded (/etc/rc.d/init.d/fetch-crl-cron; generated)
     Active: failed (Result: exit-code) since Wed 2023-09-20 11:26:28 PDT; 2min 49s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 19827 ExecStart=/etc/rc.d/init.d/fetch-crl-cron start (code=exited, status=1/FAILURE)
        CPU: 7ms

Sep 20 11:26:28 server.hostname systemd[1]: Starting LSB: Run the certificate revocation lists update periodically via cron...
Sep 20 11:26:28 server.hostname fetch-crl-cron[19827]: /etc/rc.d/init.d/fetch-crl-cron: line 22: /etc/rc.d/init.d/functions: No such file or directory
Sep 20 11:26:28 server.hostname systemd[1]: fetch-crl-cron.service: Control process exited, code=exited, status=1/FAILURE
Sep 20 11:26:28 server.hostname systemd[1]: fetch-crl-cron.service: Failed with result 'exit-code'.
Sep 20 11:26:28 server.hostname systemd[1]: Failed to start LSB: Run the certificate revocation lists update periodically via cron.
$ sudo dnf whatprovides /etc/rc.d/init.d/functions
Last metadata expiration check: 0:12:21 ago on Wed 20 Sep 2023 11:17:02 AM PDT.
initscripts-10.11.5-1.el9.x86_64 : Basic support for legacy System V init scripts
Repo        : baseos
Matched from:
Filename    : /etc/rc.d/init.d/functions

It pulls in the legacy chkconfig package as a dependency, but also requires the legacy initscripts package which provides /etc/rc.d/init.d/functions. Actually initscripts depends on chkconfig too. But I suppose fetch-crl should depend on both.

[dlgroep]

For EL9+, it is actually packaged in EPEL including the SystemD unit files. Does that help?

[rptaylor]

@dlgroep thanks for the quick reply. I was using this repo:

[fetch-crl]
baseurl = https://dist.eugridpma.info/distribution/util/fetch-crl/
enabled = 1
gpgcheck = 1
gpgkey = https://repository.egi.eu/sw/production/cas/1/GPG-KEY-EUGridPMA-RPM-3
name = fetch-crl

So what is the relationship between the fetch-crl packages in the EUGRIDPMA and EPEL9 repos? Are the packages in dist.eugridpma.info upstream of the EPEL ones? Is EPEL the preferred one to use?

We have EL7, 8 and 9 servers to manage, with fetch-crl on all of them so it would be good to have one cohesive way. What would you recommend?

The EPEL version looks slightly different, using a systemd timer instead of a cron.

Thanks!

[dlgroep]

This GitHub source is an upstream of all EPEL (and Debian) packages. The packagers for EPEL and Debian are informed when there are updates and usually repackage quickly. For production use I recommend the EPEL ones, actually.

[rptaylor]

Okay thanks for the recommendation. I had also noticed the dependencies of this fetch-crl seem pretty large: 224 packages, 333 MB, including devel stuff like make, gcc, mailcap .... ; whereas the EPEL one is much more lightweight and streamlined (29 packages, 3 MB), 111 times smaller!

I'll try to switch all our servers over to the EPEL version and hopefully that will address the issue for me. Thanks!

That being said, surely the RPM should still depend on initscripts, if the .noarch means that it should work (and dnf allows installation) on any OS.

[dlgroep]

FYI: I reviewed the dependencies of the RPM shipped from https://dl.igtf.net/distribution/util/fetch-crl/, but the dependencies are manual and limited. Maybe chkconfig attempts to draw in a lot of other packages, but the basic 'requires' is limited to what is absolutely needed (it does not include perl-IO-Socket-SSL for example, since CRL distribution over plain http should still be possible):

manual: openssl
manual: perl
manual: perl(LWP)
manual: perl(POSIX)
manual: perl(File::Temp)
manual: perl(Sys::Syslog)
manual: perl(strict)
manual: perl(vars)
post: chkconfig
preun: chkconfig
post,interp: /bin/sh
preun,interp: /bin/sh
rpmlib: rpmlib(FileDigests) <= 4.6.0-1
rpmlib: rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib: rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib: rpmlib(PayloadIsXz) <= 5.2-1

I hoped the EPEL version did solve the issue for you. Meanwhile, I'll close this issue, but feel free to re-open if you still encounter issues.

[rptaylor]

Yes I'm using the EPEL version and it works nicely, thanks. That solves the problem for me. However I think the output you pasted shows that the igtf.net version relies on chkconfig in the pre/post scripts but is missing an explicit dependency.