The CentOS 7 AMI in Amazon comes with Cloud-Init (
cloud-init-0.7.5-10.el7.centos.1.x86_64). This is quite handy as it assists in automating several bootup tasks. One of these tasks is to install and bootstrap Chef. Unforunately, when SELinux is installed the Chef handler will fail.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
This proved to be most frustrating. It was obviously failing while it was fixing the SELinux parameters under
/var/lib, but it was not clear why. There were no denied messages in the audit log. Of course
/var/lib/chef is a default directory listed in
Adding in several debug statements led to determining that the issue was specific to
/var/lib/nfs/rpc_pipefs. The file existed and had no special permissions, although it had a generic SELinux label as opposed to a nfs-specific value. Further investigation showed that the root of the issue was in libselinux, which is looking up the intended label in
The selinux python library is expecting a label as above, and returns a Errno 2 ‘No such file or directory’ if it hits the ‘none’ value. This error is returned to cloud-init and causes the chef handler to bomb out.
Adding a label to the file_contents file works around the issue but likely breaks NFS (if it were in use). The better approach would be for
util.py to ignore the case where a new label cannot be found. If CentOS7 updated to the latest cloud-init there is a decent chance this is fixed.