Description of problem: Nagios will not start with SELinux enabled. Version-Release number of selected component (if applicable): nagios-4.4.3-1.fc29.x86_64 selinux-policy-3.14.2-48.fc29.noarch How reproducible: Every time. Steps to Reproduce: 1. `systemctl start nagios` Actual results: [root@host ~]# systemctl start nagios Job for nagios.service failed because the control process exited with error code. See "systemctl status nagios.service" and "journalctl -xe" for details. [root@host ~]# systemctl status nagios ● nagios.service - Nagios Core 4.4.3 Loaded: loaded (/usr/lib/systemd/system/nagios.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sun 2019-02-10 14:44:33 GMT; 6s ago Docs: https://www.nagios.org/documentation Process: 6827 ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd (code=exited, status=0/SUCCESS) Process: 6826 ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg (code=exited, status=254) Process: 6825 ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg (code=exited, status=0/SUCCESS) Feb 10 14:44:33 host.example.com nagios[6825]: Checked 6 timeperiods Feb 10 14:44:33 host.example.com nagios[6825]: Checking global event handlers... Feb 10 14:44:33 host.example.com nagios[6825]: Checking obsessive compulsive processor commands... Feb 10 14:44:33 host.example.com nagios[6825]: Checking misc settings... Feb 10 14:44:33 host.example.com nagios[6825]: Total Warnings: 0 Feb 10 14:44:33 host.example.com nagios[6825]: Total Errors: 0 Feb 10 14:44:33 host.example.com nagios[6825]: Things look okay - No serious problems were detected during the pre-flight check Feb 10 14:44:33 host.example.com systemd[1]: nagios.service: Control process exited, code=exited status=254 Feb 10 14:44:33 host.example.com systemd[1]: nagios.service: Failed with result 'exit-code'. Feb 10 14:44:33 host.example.com systemd[1]: Failed to start Nagios Core 4.4.3. Expected results: Nagios starts OK, as it used to do (last time I rebooted this machine was 6 Jan, and it started then). Both nagios and selinux-policy have been updated since I last booted. Additional info: If I `setenforce 0` it starts OK (and if I subsequently `setenforce 1` it continues to run without problems). These lines are in the journal: Feb 10 14:50:05 host.example.com kernel: audit: type=1400 audit(1549810205.473:1097): avc: denied { dac_override } for pid=10633 comm="nagios" capability=1 scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1 Feb 10 14:50:05 host.example.com kernel: audit: type=1300 audit(1549810205.473:1097): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=558acca75c30 a2=20442 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null) Feb 10 14:50:05 host.example.com kernel: audit: type=1400 audit(1549810205.474:1098): avc: denied { chown } for pid=10633 comm="nagios" capability=0 scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1 Feb 10 14:50:05 host.example.com kernel: audit: type=1300 audit(1549810205.474:1098): arch=c000003e syscall=93 success=yes exit=0 a0=3 a1=1e3 a2=1d3 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null) Feb 10 14:50:05 host.example.com audit[10633]: AVC avc: denied { dac_override } for pid=10633 comm="nagios" capability=1 scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1 Feb 10 14:50:05 host.example.com audit[10633]: SYSCALL arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=558acca75c30 a2=20442 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null) Feb 10 14:50:05 host.example.com audit[10633]: AVC avc: denied { chown } for pid=10633 comm="nagios" capability=0 scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1 Feb 10 14:50:05 host.example.com audit[10633]: SYSCALL arch=c000003e syscall=93 success=yes exit=0 a0=3 a1=1e3 a2=1d3 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null)
Just looking deeper into the logs, I noticed this: Feb 10 14:34:41 host.example.com nagios[1774]: Warning: Cannot open log file '/var/log/nagios/nagios.log' for writing I assume that's what the SELinux errors relate to.
Same on RHEL 7 with nagios-4.4.3-1.el7.x86_64 and nagios-selinux-4.4.3-1.el7.x86_64.
I didn't seem to get these emails til today. I am trying to figure out why my test systems didn't catch this. Can you do the following for me on yours: ls -lZ /var/log/nagios/ /var/spool/nagios/ /var/run/nagios/ also does restorecon -n -r -v /var/log/nagios /var/spool/nagios /var/run/nagios show any files that would be changed?
To comment #3: # ls -lZ /var/log/nagios/ /var/spool/nagios/ /var/run/nagios/ /var/log/nagios/: insgesamt 900 drwxr-x---. 2 nagios nagios system_u:object_r:nagios_log_t:s0 12288 22. Feb 00:00 archives -rw-r--r--. 1 nagios nagios system_u:object_r:nagios_log_t:s0 97002 22. Feb 01:29 nagios.log -rw-------. 1 nagios nagios system_u:object_r:nagios_log_t:s0 808216 22. Feb 01:29 retention.dat /var/run/nagios/: insgesamt 0 /var/spool/nagios/: insgesamt 476 drwxrwx---. 2 nagios nagios system_u:object_r:nagios_spool_t:s0 4096 22. Feb 02:33 checkresults drwxrwsr-x. 2 nagios nagios system_u:object_r:nagios_spool_t:s0 4096 22. Feb 01:29 cmd -rw-r--r--. 1 nagios nagios system_u:object_r:nagios_spool_t:s0 477918 11. Feb 13:06 objects.cache # restorecon -n -r -v /var/log/nagios /var/spool/nagios /var/run/nagios # systemctl restart nagios Job for nagios.service failed because the control process exited with error code. See "systemctl status nagios.service" and "journalctl -xe" for details. # systemctl status nagios ● nagios.service - Nagios Core 4.4.3 Loaded: loaded (/usr/lib/systemd/system/nagios.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2019-02-22 14:28:21 CET; 1min 53s ago Docs: https://www.nagios.org/documentation Process: 6303 ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd (code=exited, status=0/SUCCESS) Process: 6302 ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg (code=exited, status=254) Process: 6301 ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg (code=exited, status=0/SUCCESS) Feb 22 14:28:21 myhost.example.com nagios[6301]: Checking obsessive compulsive processor commands... Feb 22 14:28:21 myhost.example.com nagios[6301]: Checking misc settings... Feb 22 14:28:21 myhost.example.com nagios[6301]: Total Warnings: 0 Feb 22 14:28:21 myhost.example.com nagios[6301]: Total Errors: 0 Feb 22 14:28:21 myhost.example.com nagios[6301]: Things look okay - No serious problems were detected during the pre-flight check Feb 22 14:28:21 myhost.example.com nagios[6302]: Failed to obtain lock on file /var/run/nagios/nagios.pid: Permission denied Feb 22 14:28:21 myhost.example.com nagios[6302]: Bailing out due to errors encountered while attempting to daemonize... (PID=6302) Feb 22 14:28:21 myhost.example.com systemd[1]: nagios.service: Control process exited, code=exited status=254 Feb 22 14:28:21 myhost.example.com systemd[1]: nagios.service: Failed with result 'exit-code'. Feb 22 14:28:21 myhost.example.com systemd[1]: Failed to start Nagios Core 4.4.3. From journalctl: Feb 22 14:28:21 audit[6302]: AVC avc: denied { dac_override } for pid=6302 comm="nagios" capability=1 scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=0 Feb 22 14:28:21 nagios[6302]: Failed to obtain lock on file /var/run/nagios/nagios.pid: Permission denied Feb 22 14:28:21 audit[6302]: AVC avc: denied { dac_override } for pid=6302 comm="nagios" capability=1 scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=0 Feb 22 14:28:21 audit[6302]: AVC avc: denied { dac_override } for pid=6302 comm="nagios" capability=1 scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=0 Feb 22 14:28:21 nagios[6302]: Bailing out due to errors encountered while attempting to daemonize... (PID=6302) Feb 22 14:28:21 systemd[1]: nagios.service: Control process exited, code=exited status=254 Feb 22 14:28:21 systemd[1]: nagios.service: Failed with result 'exit-code'. Feb 22 14:28:21 systemd[1]: Failed to start Nagios Core 4.4.3. Feb 22 14:28:21 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nagios comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Feb 22 14:28:24 dbus-daemon[1178]: [system] Activating service name='org.fedoraproject.Setroubleshootd' requested by ':1.5' (uid=0 pid=1091 comm="/usr/sbin/sedispatch " label="system_u:system_r:auditd_t:s0") (using servicehelper) Feb 22 14:28:25 dbus-daemon[1178]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd' Feb 22 14:28:25 setroubleshoot[6306]: SELinux is preventing nagios from using the dac_override capability. For complete SELinux messages run: sealert -l 7bf4f44b-fb5d-40c9-a8fd-de15858bf598 Feb 22 14:28:25 python3[6306]: SELinux is preventing nagios from using the dac_override capability. ***** Plugin dac_override (91.4 confidence) suggests ********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that nagios should have the dac_override capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'nagios' --raw | audit2allow -M my-nagios # semodule -X 300 -i my-nagios.pp Feb 22 14:28:25 setroubleshoot[6306]: SELinux is preventing nagios from using the dac_override capability. For complete SELinux messages run: sealert -l 7bf4f44b-fb5d-40c9-a8fd-de15858bf598 Feb 22 14:28:25 python3[6306]: SELinux is preventing nagios from using the dac_override capability. ***** Plugin dac_override (91.4 confidence) suggests ********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests ************************** If you believe that nagios should have the dac_override capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'nagios' --raw | audit2allow -M my-nagios # semodule -X 300 -i my-nagios.pp
OK those perms match my system.. so something must be wrong on my side (aka either i or something else added a perm I missed). Could I ask one more step ausearch -c 'nagios' --raw | audit2allow -M smooge-missed-a-big-thing and attach the .te file? I would not install the semodule as hopefully I will push an update which will fix this.
Created attachment 1537581 [details] File requested by comment #5
Thanks. That is saying that selinux is not letting this run because the process permissions aren't right somewhere. Adding the dac_override would be an atomic bomb which would cover up the real problem. [Basically if it is allowed dac_override it over rides all permissions and would make everything 7777 to nagios.] The basic discretionary access controls on the file look all correct 640 and user/group nagios. So we need to see what it thinks it is running at. Could I ask for one more? This is what I have on the working box [root@noc01 ~][PROD]# systemctl cat nagios.service # /usr/lib/systemd/system/nagios.service [Unit] Description=Nagios Network Monitoring After=network.target Documentation=https://www.nagios.org/documentation/ [Service] Type=forking User=nagios Group=nagios PIDFile=/var/run/nagios/nagios.pid # Verify Nagios config before start as upstream suggested ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg ExecStop=/bin/kill -TERM ${MAINPID} ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd ExecReload=/bin/kill -HUP ${MAINPID} [Install] WantedBy=multi-user.target [root@noc01 ~][PROD]# ls -l /usr/lib/systemd/system/nagios* -rw-r--r--. 1 root root 542 Nov 20 2017 /usr/lib/systemd/system/nagios.service
Thanks, Stephen. Of course, if it helps to solve the problem, I will try to help if I can. # systemctl cat nagios.service # /usr/lib/systemd/system/nagios.service [Unit] Description=Nagios Core 4.4.3 Documentation=https://www.nagios.org/documentation After=network.target local-fs.target [Service] Type=forking ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg ExecStop=/usr/bin/kill -s TERM ${MAINPID} ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd ExecReload=/usr/bin/kill -s HUP ${MAINPID} [Install] WantedBy=multi-user.target # ls -l /usr/lib/systemd/system/nagios* -rw-r--r--. 1 root root 442 17. Jan 01:32 /usr/lib/systemd/system/nagios.service
Oh for the love of ... ok so the problem is that we lost the User=nagios Group=nagios and my test roll out replaced that file with one that had it.. so I had a working box and everyone else didn't.. I don't know what the testers who said it worked for them had.. I will roll out an update to updates-testing shortly.
I checked with the testers and they do not have the User= , have selinux running and are not seeing the issue. Could I ask one more thing while I try to figure this out on your box so I make sure I am fixing the right thing: 1. DO the following: [root@noc01 ~][PROD]# ps axo euser,fuser,group,fgroup,command | grep sbin/nagios root root root root grep --color=auto sbin/nagios nagios nagios nagios nagios /usr/sbin/nagios -d /etc/nagios/nagios.cfg nagios nagios nagios nagios /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh nagios nagios nagios nagios /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh nagios nagios nagios nagios /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh nagios nagios nagios nagios /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh nagios nagios nagios nagios /usr/sbin/nagios -d /etc/nagios/nagios.cfg 2. Test if doing the following fixes the problem on your box cp -av /usr/lib/systemd/system/nagios.service /usr/lib/systemd/system/nagios.service.temp edit /usr/lib/systemd/system/nagios.service and add the User and Group # /usr/lib/systemd/system/nagios.service [Unit] Description=Nagios Core 4.4.3 Documentation=https://www.nagios.org/documentation After=network.target local-fs.target [Service] Type=forking User=nagios Group=nagios ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg ExecStop=/usr/bin/kill -s TERM ${MAINPID} ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd ExecReload=/usr/bin/kill -s HUP ${MAINPID} [Install] WantedBy=multi-user.target # systemctl daemon-reload # systemctl restart nagios If that gets it working again then I can be sure my fix will work. You can put back the original file afterwords as needed.
There is no nagios process running, because it didn't start previously. After adding User and Group options to nagios.service, nagios starts again. I don't find SELinux error logs about nagios in the logs. So I think this solves the problem. Thanks!
Oh sorry I thought that you had one running from a setenforce 0 and then starting it.
Stephen, can't you easily reproduce this on a fresh Fedora or RHEL install?
nagios-4.4.3-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-431b7a7aa8
I probably could but it would be next week before I had time to set up said environments. Asking questions while dealing with the other fires seemed at the time useful.. but I can see where everyone else getting yet another update would get tired of it. Packages should be in EPEL and F2x testing in the next 48 hours. Please test and if you have a Fedora Account give karma so it doesn't sit for 2-3 weeks before it gets pushed.
It's not tiring, just seems like it would be easier if you reproduce the problems and test the changes yourself rather than guessing. Just a quick default Fedora install using GNOME Boxes or "virt-install --name fedora --memory 8192 --disk size=10 --cdrom ~/Downloads/Fedora-Server-netinst-x86_64-29-1.2.iso --virt-type kvm --os-variant fedora26 --network bridge=br0" would do it.
nagios-4.4.3-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d3112aae3
nagios-4.4.3-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb
nagios-4.4.3-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb
nagios-4.4.3-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-431b7a7aa8
nagios-4.4.3-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d3112aae3
As mentioned at https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment-900273 now there are new SELinux denials with nagios-4.4.3-4.el7, possibly related to Bug #1592594: SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/spool/nagios/status.dat. type=AVC msg=audit(1551152845.860:270): avc: denied { getattr } for pid=2176 comm="httpd" path="/var/spool/nagios/status.dat" dev="dm-3" ino=2114580 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nagios_spool_t:s0 tclass=file SELinux is preventing /usr/sbin/httpd from read access on the file /var/spool/nagios/status.dat. type=AVC msg=audit(1551152845.861:271): avc: denied { read } for pid=2176 comm="httpd" name="status.dat" dev="dm-3" ino=2114580 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nagios_spool_t:s0 tclass=file SELinux is preventing /usr/lib64/nagios/cgi-bin/statusjson.cgi from read access on the file /var/spool/nagios/objects.cache. type=AVC msg=audit(1551152846.15:272): avc: denied { read } for pid=2391 comm="statusjson.cgi" name="objects.cache" dev="dm-3" ino=2114578 scontext=system_u:system_r:nagios_script_t:s0 tcontext=system_u:object_r:nagios_spool_t:s0 tclass=file
Correction to my previous comment: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment-900327 These "new" SELinux denials happened for me because in my testing of nagios-4.4.3-4.el7, I didn't include updated selinux-policy packages.
(In reply to Kenyon Ralph from comment #23) > Correction to my previous comment: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment- > 900327 > > These "new" SELinux denials happened for me because in my testing of > nagios-4.4.3-4.el7, I didn't include updated selinux-policy packages. Correction again. Even using the selinux-policy packages from RHEL 7.5, still getting denials with nagios-4.4.3-4.el7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment-900328 So my testing environment for nagios-4.4.3-4.el7 is exactly the same as my environment where nagios-4.3.4-5.el7 works fine. So something is still wrong about the SELinux policy coming from nagios-4.4.3-4.el7.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
nagios-4.4.5-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ba137d7748
FEDORA-EPEL-2020-dbdd968fc0 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-dbdd968fc0