Most of us have a love-hate relationship with SELinux.
In an administrator’s quest to get stuff done, SELinux tends to get in the way. It is being perceived as a nuisance rather than a feature and this happens mostly for only one reason: setting correct SELinux labels requires the ability to figure out the appropriate SELinux security contexts. Here is how to do it.
Your users want to access a web server instance as a staging or production environment for DevOps… They want access to the web server document root of the sites they manage. Your job is to maintain the integrity of the whole system in terms of cyber security.
If you happen to be running a web server on Linux—for example in EC2 on Amazon AWS—and need to provide site owners remote access in a secure and responsible manner, here is how to do it.
When updating MariaDB, the popular successor to MySQL, you may, once upon a time, hit a roadblock which you won’t be able to track down in the error log. Even though web visitors get to see the plain text complaint “Can’t connect to the database”, the MariaDB server will be running just fine. Silent errors should be reason enough to suspect SELinux, the oftentimes dreaded and despised but equally popular Security-Enhanced Linux kernel module.
Some WordPress installations stubbornly refuse requests for a password reset link, showing the user this error message instead:
The email could not be sent. Possible reason: your host may have disabled the mail() function.
WordPress’ error massage is anything but insightful. The underlying cause usually involves SELinux. Let us introduce you to an easy fix that does not involve plug-ins or external email services. Buckle up.