On 2017-02-10 05:01, Konstantin Olchanski wrote: > Reporting more selinux borkage. (to remember main selinux feature is > commands > executed from root shell work differently from commands run by cron > or sshd & co. Clearly this is introduced to simplify testing stuff). > > This time, broken is letsencrypt certificate renewal using certbot. > > "certbot renew" works just fine from command line, but not from > a cron job: selinux prevents httpd access to files > /var/lib/letsencrypt. > > (BTW, the certbot packages does not even include any cron jobs, > "manual automatic renewal", please patent it quick!) > > Bug reports for this: > > https://community.letsencrypt.org/t/certbot-via-cron-writes-files-unreadable-by-apache-selinux-centos-7/24792 > (auto-closed after 30 days, no old stale bugs in that operation!) > > https://bugzilla.redhat.com/show_bug.cgi?id=1385167 > https://bugzilla.redhat.com/show_bug.cgi?id=1377312 This wouldn't be accepted as an upstream bug - mainly because its not a RHEL shipped package. It could be lodged against EPEL, but there'd be no priority for anyone to fix anything. > Since I will learn selinux after I learn ldap after our current > high-priority > project ships to CERN in September, I do not see any solution other > than disabling > selinux until this is fixed (presumably by the EPEL package certbot > incuding > correct selinux policy kludges). BTW, on the machines where selinux is > disabled > due to the ZFS bug, letsencrypt renewal works just fine. I would approach it by putting selinux in permissive mode. From the CLI 'setenforce 0' and to make permanent, edit /etc/sysconfig/selinux. From there, use the setroubleshoot-server package to use audit2allow and / or sealert to create a policy to allow it. I'm thinking of writing up a blog post on my site regarding an automatic troubleshooter for selinux, but I'm not quite there yet. -- Steven Haigh Email: [log in to unmask] Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897