We recently looked at the Caddy web server. Today we’re going to secure things a bit and look at the A from the classic LAMP stack: the Apache web server.
Apache has a bad reputation for being old, crispy and underperforming. However, this idea is mainly based on the persistence of old instructions that still show users how to set them up in an extremely antiquated way. In this guide, we at Digital Ocean will set up an Ubuntu 20.04 droplet with an Apache web server that is properly set up and can handle serious amounts of data.
After launching a new VM for $ 5 a month (Digital Ocean calls them “droplets”), the first thing we will do is what everyone should do with a brand new Linux server. We then check and install upgrades and restart the server because one of them was a new Linux kernel version.
root@apache:~# apt update root@apache:~# apt dist-upgrade root@apache:~# shutdown -r now
It’s time to install Apache itself and the PHP language that most web applications need.
root@apache:~# apt install apache2 php-fpm
Friends don’t let friends use mod_php inappropriately
I want to make it incredibly clear what we have Not installed – we have not installed it and will not install it
mod_php Apache module.
root@apache:~# apt policy libapache2-mod-php libapache2-mod-php: Installed: (none) Candidate: 2:7.4+75 Version table: 2:7.4+75 500 500 http://mirrors.digitalocean.com/ubuntu focal/main amd64 Packages
mod_php The module was once the preferred method to integrate PHP support into your web server. It largely replaced the older Common Gateway Interface (CGI) method, in which the files with the specified extensions were passed to another application to be processed – the one most commonly used in those days was Perl.
Mod_php does things differently – instead of a separate executable PHP file that processes PHP code, the PHP language is directly embedded in the Apache process itself. This is an extremely efficient method of processing PHP code. However, for a server that is expected to process non-PHP content, this sucks because each individual Apache process must bring with it an entire PHP execution environment, increasing the number of available Apache processes is severely limited due to memory gas.
mod_php also means that Apache has to run with older people
prefork MPM (Multi Process Module), which cannot be scaled to as many available worker processes as the modern standard MPM,
event. The reason
prefork– There is still the possibility that they are very suitable for a pure application service, a 100% PHP workload, in which all CSS, static HTML, image etc. are outsourced to another server or other servers will.
Php-fpm is the right choice for a multi-purpose web server
Instead, we installed that
php-fpm, the PHP FastCGI Process Manager. In this model, Apache does not incorporate PHP handling functions into the Apache processes themselves. Instead, Apache passes the code execution requirements to a pool of dedicated PHP employees, who in turn return the results to Apache.
By outsourcing PHP execution tasks to a set of dedicated PHP worker threads, Apache can use its more modern and better scaling
event MPM handler. This also means that every single Apache thread can be started without the bulk of a PHP execution environment, which drastically reduces the amount of RAM required for each thread.
The front page of my personal blog contains 31 separate HTTPS requests. Ten of them relate to other domains – fonts.googleapis.com, fonts.gstatic.com and my own Matomo instance. Index.php itself is different, and the remaining twenty are static files provided by the same server.
RAM is certainly the most valuable resource on this VM – and now that we know that I provide static files with a ratio of around 20: 1 to dynamic pages, I should of course not waste my work process on every Apache RAM in a full PHP environment !
Activate php-fpm and install the remaining support packages
Most real web applications require a number of additional PHP modules. For example, if we want to install WordPress, we would like the following laundry list with PHP extensions:
root@apache:~# apt install php-fpm php-common php-mbstring php-xmlrpc php-soap php-gd php-mysql php-xml php-intl php-mysql php-cli php-ldap php-zip php-curl
Angry. If you are not familiar with the use of the backslash there, you can force a line break in the terminal without affecting the code execution. So this is actually just one big line in which all additional PHP extensions are installed that WordPress needs.
If these are installed, we have to activate them
php-fpm even with the following commands:
root@apache:~# a2enmod proxy_fcgi root@apache:~# a2enconf php7.4-fpm.conf root@apache:~# systemctl restart apache2
That was ‘s – we have now created our complete, WordPress-enabled web server environment. The next step is to create a MySQL database for WordPress that looks like this:
root@apache:~# mysql -u debian-sys-maint -p mysql> create database wordpress; mysql> create user 'wordpress'@'localhost' identified by 'supersecretpassword'; mysql> grant all on wordpress.* to 'wordpress'@'localhost'; mysql> quit;
Now we are ready to create a new one
vhost– virtual host – to contain the new WordPress site. We could Just use the default vhost configuration, but we won’t do it – we’ll do this as follows Professionals and be ready to manage a multi-site environment.
Configuration of the Apache site, module and configuration (this is not a typo!)
What I enjoy most about using Apache rather than competing web servers is the highly segmented approach it uses for configuration management. In the old days – which I don’t remember very well – a server had a single monolith
httpd.conf File that can easily be thousands of lines long and contains global configurations for the server as well as all individual configurations for each site on the waiter. Yuck!
Fortunately, Apache finally introduced that
Include Directive that allowed the main Apache configuration file to be linked to other configuration files – and especially to directories that were expected to be full from Configuration files. This allowed site administrators to create one person short Configuration file for each site and – simply by copying it into the corresponding directory – let the configurations of this site after a automatically add to the existing server configuration
systemctl reload apache2 (or on non-system controlled computers,
The fine people at Debian took this concept and ran it. If you install Apache on a modern, Debian-derived system like Ubuntu, the following directories will be created automatically:
/etc/apache2 /etc/apache2/sites-available /etc/apache2/sites-enabled /etc/apache2/mods-available /etc/apache2/mods-enabled /etc/apache2/conf-available /etc/apache2/conf-enabled
So let’s say you want to add a module – how
php-fpm itself – to Apache. You don’t have to mess around with the global configuration file
/etc/apache2/apache2.conf, because the
php-fpm The package simply deletes its configuration and loads files into it
/etc/apache2/mods-available. They have not yet taken effect because they are only in
mods-enabled– But remember when we executed the command
a2enmod proxy_fcgi in the last part?
root@apache:~# a2enmod proxy_fcgi Considering dependency proxy for proxy_fcgi: Enabling module proxy. Enabling module proxy_fcgi. To activate the new configuration, you need to run: systemctl restart apache2
What this command actually did was
symlink the configuration file
/etc/apache2/mods-enabled/proxy_fcgi.load. And the next time we restart Apache as requested, Apache will do it
Include all files in
mods-enabled– including our new friend,
proxy_fcgi.load– and we therefore have the FastCGI proxy available.
If you remember, we executed another command immediately afterwards:
root@apache:~# a2enconf php7.4-fpm Enabling conf php7.4-fpm. To activate the new configuration, you need to run: systemctl reload apache2
This command is linked
/etc/apache2/conf-enabled/php7.4-fpm.confand Apache becomes similar
Include everything it finds
conf-enabledThe following required configuration instructions are now activated at every start:
root@apache:/etc/apache2/conf-available# cat php7.4-fpm.conf # Redirect to local php-fpm if mod_php is not available # Enable http authorization headers SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1 <filesmatch ".+.ph(ar|p|tml)$"=""> SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost" <filesmatch ".+.phps$"=""> # Deny access to raw php sources by default # To re-enable it's recommended to enable access to the files # only in specific virtual host or directory Require all denied # Deny access to files without filename (e.g. '.php') <filesmatch "^.ph(ar|p|ps|tml)$"=""> Require all denied
If you don’t see the beauty in it … I don’t know what to say to you. If you’re not sure how Apache deals with PHP files when they encounter them, you have one single File in which you can search for these configuration lines, and just these configuration lines. You can view it without being confused and annoyed by hundreds or thousands of other configuration lines, and you can to edit This is necessary without fear of accidentally messing up the other hundreds or thousands of configuration lines you are not touching because you are only working in this single standalone file.
This does not only apply to configuration lines provided by the system – nothing prevents you from writing your own configuration lines for a specific purpose and storing them there
a2enconfas required. Would you like to get to know all activated modules?
ls /etc/apache2/mods-enabled. Would you like to see if more are available?
mods-available. The same applies to configurations in
conf-availableand website (
vhost) Configurations in
That makes my sysadmin heart sing, it really does.