Administering the LAMP Stack for Effective Web Hosting Solutions January 12, 2014 Defining a set of best practices to be used as the foundation for hosting websites can be challenging when the volume of new sites is high and the range of requirements disparate. As effective administration can often depend on finding commonality among diversity, it is important to understand where website requirements overlap to be able to plan a hosting strategy that encompasses all requests, minimizes overhead and increases productivity. When making such choices, what can appear to be a simple decision about a basic setting can impact related systems negatively if the entire environment is not taken into account. For example, if configuring the Apache “Directory” directive with `Options -Indexes`, excluding the `-` symbol means “If a URL which maps to a directory is requested, and there is no Directory Index (e.g., index.html) in that directory, then mod_autoindex will return a formatted listing of the directory” (see http://httpd.apache.org/docs/current/mod/core.html for specifics). This is not necessarily desirable, as the entire folder contents can potentially be viewed over http and because of that, introduce security and privacy risks. Or consider updating a folder’s ownership to allow Apache the ability to write files to that folder. If a site login becomes compromised whereby executable scripts can be added to those folders via a content management system, with no other checks and balances in place, you could be facing the compromise of the site and environment through various exploits. With so many factors to take into account, the importance of making the correct decisions initially cannot be overstated and should never be taken for granted. To help sort through these details, a continued analysis over time can allow a set of commonalities to emerge; commonalities which can be used to form the foundation for future website hosting deployments, and help form a suite of standards and practices for responsible website hosting. The goal of this post is to initiate a multi-post series about LAMP stack administration, the purpose of which is to provide administrators with the basic knowledge needed to complete typical website hosting requests. The target audience initially is the entry level LAMP stack administrator looking for a more complete picture of the options available. It is not intended to encompass all possible options as that would require volumes. Instead, the aim is to share some of the knowledge we have gained for common scenarios in the hope it can be used to eliminate some of the questions you may have as you venture further into the finer details of the LAMP stack. Five Best Practices for Administering the LAMP Stack Configuration Files Know the location of the configuration files for the software you use. It’s important to realize that all server components and processes are configured and administered via specific configuration files. Understanding where those files are and what options they contain is essential for effective administration of your hosting solution. Some common examples include: Apache :: /etc/httpd/conf/httpd.conf – fine to edit when command line administration is being practiced exclusively VSFTPD :: /etc/vsftpd/vsftpd.conf – known as the “very Secure FTP Daemon” PHP :: /etc/php.ini MySQL :: /etc/my.cnf Access control :: /etc/hosts.allow and /etc/hosts.deny Server Logs Understand where a server stores its logs and understand how to read and administer those logs. This will assist you when performing time sensitive troubleshooting and is one of the first places to check when issues arise. For example, typical log locations are /var/log, but understand that most software can be reconfigured to store logs elsewhere (and commonly is). RedHat Apache :: /var/log/httpd/ VSFTPD :: /var/log/vsftpd.log PHP :: /var/log/php-errs.log MySQL :: /var/log/mysqld.log and /var/log/mysqld/ Access control :: see the above log files, and potentially /var/log/secure Log Rotation Log Rotation via the logrotate process, provides a flexible mechanism to automatically manage log files on systems which generate many log file entries. Logs can be re-created at desired intervals with older logs compressed and deleted after a period of time, and emailed to recipients. The value of these features cannot be overstated. On busy web servers for example, the access logs and error logs, if allowed to grow indefinitely, can become time consuming to parse, utilize large amounts of disk space and eventually decrease system performance. Unused Services Enable only the services you require and disable all other services or modules. The goal should be to provide the least number of access points to your servers by minimizing the risks to those servers from external sources. For services which are enabled, determine if access can be further restricted via a firewall, hosts.allow or hosts.deny, .htaccess or httpd.conf, reverse proxies services such as squid, and basically any and all means to potentially minimize access. Be sure to educate yourself on the specifics of the software you use to understand how access can be managed. The UMASK Understand and Define the UMASK. On a typical web server, common operations include the creation of files and directories by a user. The user is typically the Linux administrator, the Apache user, and the FTP or SSH user. Be aware that a UMASK of 022 results in file mode of 644 and directory mode of 755. This is a reasonably secure setting for typical files and directories owned by the root user and can safely be implemented for the standard web server. Shell Scripts Utilize shell scripts to automate recurring tasks. If you find yourself completing the same tasks regularly, create scripts to automate the work for you. For example, perhaps you have a number of web servers which you would like to know basic statistics for, such as load average, disk space utilization, httpd service status, and log file growth and/or contents. Perhaps you wish to automate MySQL backups or perform operations across groups of servers, like copy files or view file contents. These tasks can all be scripted via the Linux shell. And if you find that the scripts you create are being executed regularly, add them to the /etc/crontab file to execute at regular intervals. Deciding where to end the discussion is the difficult part, so we leave you with these basic ideas with the hope it encourages discussion here and elsewhere. Next we’ll discuss Apache and how it can be leveraged to compliment these ideas.
