Lab 5: Webserver and PHP Installation and Use

Open an SSH remote terminal session to your Linux server’s IP address

Login with your standard user’s username and password

Because we are going to start actually using our Linux Server to provide some services we are going to want to make sure the IP address of the server doesn’t change any more. To do this we will change from using a dynamic or DHCP IP address to a static IP address which we will manually set on the server.

As all the servers in the class are located on the same network each server must be assigned a unique IP address. To prevent any conflicts you will use your server ID letter in the chart below to determine what IP address your server should be set to.

All of the servers will share some of the same network settings:

For many years Debian has used the /etc/network/interfaces file for storing the configuration of network interfaces but this is expected to be replaced (and already has when using a GUI) by other, more modern and flexible, methods in the future. In this lab we will use one of those newer methods, the systemd.network method, for configuring a static IP address.

Use your favorite text editor, such as nano, to create a new file /etc/systemd/network/10-primary.network with the contents below. You will need to do this as the root user. Be sure to replace xxx.xxx.xxx.xxx with the correct static IP address for your system ID based on the table above!

[Match]
Name=ens192

[Network]
Address=xxx.xxx.xxx.xxx/23
Gateway=172.17.50.1
DNS=172.17.50.1
IPv6PrivacyExtensions=false
IPv6AcceptRA=true

The two IPv6 lines enable SLAAC IPv6 addressing for your server if the network is configured to provide IPv6 router advertisements.

Because we are changeing from the old-style network configuration we need to specifically enable the Networkd service using the systemctl enable systemd-networkd command and disable the old-style network configuration with the systemctl disable networking command. You will need to do this as the root user.

To apply the changes to our network configuration run the systemctl restart systemd-networkd command as the root user.

You will also want to stop the old-style network configuration with the systemctl stop networking command as the root user.

Rename the /etc/network/interfaces file so you still have a backup but it is no longer going to start automatically. You can do this by running the mv /etc/network/interfaces /etc/network/interfaces.bak command as the root user.

You should notice that your SSH connection to your server becomes unresponsive shortly after running this command. That is because the IP address has changed and your SSH connection is still to the old IP address. Start a new SSH connection to your new static IP address (this is the address you will use for connecting to your server going forward).

[Match]
Name=ens192

[Network]
DHCP=ipv4

Although we set nameservers in the /etc/systemd/network/10-primary.network file they are not actually in use yet. DNS servers have traditionally be stored in the /etc/resolv.conf file which is edited manually when they need to be changed. However, this presents a problem for mobile devices which may need to frequently change DNS servers as they are connected to different networks. While there have been multiple schemes for doing this in the past including having the DHCP client software edit the /etc/resolv.conf file or using an intermediate software package such as openrsolv or resolfconf to manage this file with new-style networkd configuration there is also a new way to manage DNS settings using the systemd-resolved program.

Make sure that you can SSH to your Linux server’s new static IP address and that you can ping google.com from your Linux server (press CTRL+C to stop the ping).

The most popular web server software on the Internet was long the Apache web server. It still remains quite popular but in recent years has decreased in popularity as more and more servers have started running Nginx (pronounced 'engine-x') which started in 2004. While Apache does still have some advantages in certain situations it is not usually considered as fast or desirable for serving modern web applications to large numbers of users.

On your administrative PC open a web browser and try accessing the new static IP address of your Linux server by putting it in the address bar. You should see some kind of unreachable error because there is no web server running on your Linux server yet.

Use the appropriate apt command to install the nginx package on your Linux server.

Once the installation process for Nginx is complete you should be able to go back to your administrative PC and try visiting the IP address of your Linux system in a web browser again or reloading the page. You should now see a basic welcome page which indicates you have a webserver up and running on your Linux system. Obviously we haven’t done anything exciting with the page yet or setup much security but it really is that simple to turn a Linux system into a basic webserver.

Use your administrative PC to navigate to the /var/www/html directory on your Linux server and list the files in the directory.

Use a text editor or another utility for viewing text files (such as less) to view the index.nginx-debian.html file. This file should contain the HTML code which makes up the web page you were just viewing in the browser of your administrative PC.

Make a copy of the index.nginx-debian.html file in the same directory named index.html and open the new file in a text editor.

Make some changes to the index.html file to personalize it such as adding your name, or other information and save your changes. If you are unfamilar with HTML it may be a good idea to review a basic HTML tutorial to know what you can change.

Refresh the web browser on your administrative PC to see if your changes are showing up.

This is all a basic web server does. It takes files from a directory on a server (such as /var/www/html in our case) and provides them to web browser clients that ask. All of the rendering of the HTML code on the web site into a graphical display is actually handled by your web browser and not the server.

Try creating a directory inside of /var/www/html named test and put a new index.html file in that directory which contains some different HTML code. Again, if you are unfamilar with HTML it may be a good idea to review a basic HTML tutorial to learn how to construct a basic HTML file with at least a few lines of text.

Try changing the address in your web browser bar to http://172.17.xx.xx/test (replacing the IP address with the static IP address of your Linux server) and see what you find.

Hopefully you see the new index.html file which you stored in the /var/www/html/test directory. The webserver just hands out the files starting from a base directory for the site and the /test on the end of the URL just tells the webserver to look for files in the test directory inside of that base location.

But why do the index.html files show up in your web browser without needing to type a URL like http://172.17.xx.xx/index.html or http://172.17.xx.xx/test/index.html? The reason for this is to make the web a more user friendly place the we server software will automatically serve certain files (called index files) if it finds them and no specific filename is specified in the URL. The exact name of the files can be configured in the web server configuration files but index.html and index.htm are historically common.

Other files can be served by the webserver too though. For example, if you put a copy of the shakespeare.tar.gz file from your home directory into /var/www/html/ you should be able to download it on your administrative PC from your web server at http://172.17.xx.xx/shakespeare.tar.gz

Of course the same user permissions apply to the web server files as all other areas of your Linux system. The web server software itself usually runs as a special www-data user (in the www-data group too) on Debian Linux systems so only files which can be read by that user or group can be accessed by users through their web browser. Try changing permissions on one of your files in /var/www/html to see how this works. Be sure to change them back so the www-data user can access them once you are done.

There are many times when you want to serve a dynamic web page rather than a static one. A common use for this is to run some kind of web application instead of just delivering fixed web pages. This could be anything from content management or blog software, to a photo gallery, database application, discussion forums, or many other web applications. All of these types of web applications need to execute at least some code on the web server itself instead of just in the web browser on the client computer. While almost any programming language can be used to make a web application one of the most popular historically, and one that really grew up along with the web is PHP. In fact, the name PHP stands for PHP Hypertext Preprocessor. With hypertext being a part of HTML (hypertext markup language). So, it is really designed to modify hypertext before it is sent out from the webserver.

Because Nginx is desinged to be a very efficient web server it does not include a lot of extra code that all users may not want, such as support for PHP. This is one way that it is different than the Apache webserver. Instead, Nginx is designed to call on other programs that should process certain types of files that you designate and then can take the output from those programs and deliver it to client web browsers. So, in order to process dynamic PHP files we need some kind of program to sit between Nginx and PHP. There are a few different ways to set this up but the most popular way today is to use a piece of software called php-fpm which allows PHP to execute the PHP files and return the data (usually as HTML code) to Nginx where it can be sent on to the client web browser that requested the page.

Install the php-fpm package on your Linux server using the appropriate apt command. Pay attention to the version number of PHP that gets installed on your system, you’ll need to know it later.

Now that we have the software installed we need to configure Nginx to send requests for PHP files to the php-fpm software instead of just sending the requested PHP file to the client web browser. When you only have one web site on a server (it is possible to have multiple web sites on the same server using a technique called VirtualHosts) the configuration for Nginx is stored in the /etc/nginx/sites-available/default file. Like most Linux configuration files it is a text file so you’ll want to open it in a text editor.

In Nginx configuration files (and many different Linux configuration files) lines that start with a # are considered comments (that can help you remember what different things do) and are ignored by the software. If you look at just the lines in this file that do not have a \# at the front you should see something like this:

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name _;
        location / {
                try_files $uri $uri/ =404;
        }
}

Inside of the server block the first two lines tell Nginx what server IP addresses and pot numbers to listen for connections on (in this case all IPv4 and IPv6 addresses on port 80, the default HTTP port). You’ll also notice that every lonfiguration line ends in a ; which indicates the end of the line. The root line tells Nginx what directory to use as the web root location (the directory containing the web site, in our case /var/www/html is the default). The index line indicates what files (and in what order of preference) are to be served automatically from a directory if the web browser doesn’t specify a file name. The last part, the location block is probably the most confusing but is also going to be important when telling Nginx to do something different with PHP files. The try_files line it contains tells Nginx to try looking in the web root for the file name requested by the web browser (the $uri) and then to try looking for the same file but as a directory (with the extra slash on the end). If neither of those turns up a file that Nginx can deliver it should send a 404 error back to the web browser which is the HTTP code for a "file not found" error.

The first thing we need to do is to tell Nginx to do something different with PHP files. We can use a special location ~ \.php$ block to tell Nginx that any file name ending in .php should be handled differently. Inside this block we’ll need to put a few things, but perhaps most importantly is the location of the socket file that php-fpm will use to connect with Nginx.

To find this socket file location close the Nginx configuration and open the php-fpm configuration file in your text editor from somewhere like /etc/php/8.2/fpm/pool.d/www.conf note that the exact location depends on the version of php-fpm that you installed with apt (mine is 8.2). If you didn’t catch the version when it was installed you’ll need to change to the /etc/php/ directory and list the contents to see what the latest version number listed there is and substitute that in the location above.

You’ll see there are some similarities between Linux configuration files, there is almost always a way to leave comments in the files but instead of lines beginning with a \# like Nginx used for comments, php-fpm uses lines beginning with a ; to indicate comments. Also, php-fpm uses square brackets like this [name] to indicate sections of the configuration file instead of the blocks with curly-braces {} like Nginx. You’ll want to look for a line that starts with listen = something.

On my system that line looks like listen = /run/php/php8.2-fpm.sock. Again, this is going to vary depending on the specific version of php-fpm you have installed on your system. This is the location of the socket file that php-fpm will use to talk to Nginx. Save this location somewhere so you can paste it into your Nginx configuration.

Re-open your Nginx configuration file at /etc/nginx/sites-available/default in a text editor. You’ll want to add a few things to verious lines as well as a location block to handle .php files. A sample (again with comments removed to save space, but you can leave them in yours) is below along with an explanation:

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        index index.php index.html index.htm index.nginx-debian.html;
        server_name _;
        location / {
                try_files $uri $uri/ =404;
        }
        location ~ \.php$ {
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass unix:/run/php/php8.2-fpm.sock;
            fastcgi_index index.php;
            include fastcgi.conf;
    }
}

First, notice that we have added index.php to the beginning of the index line? That will allow Nginx to use any index.php file in a directory as the default file if the web browser doesn’t specify some other specific file.

Second, we have added that special new location ~ \.php$ block which will handle all files ending in .php. All of the details that are in this block are outside the scope of this introductory server administration course, but note that the line fastcgi_pass unix:/run/php/php8.2-fpm.sock; includes the socket file location we found in the php-fpm configuration file. Note that you will need to modify this line based on the exact name of your own php-fpm socket file and that the line must end with a ; or you will have an error in your configuration that will prevent Nginx from loading.

One of the ways Nginx provides for checking your configuration files for errors is to run nginx -t as the root user. While this may not catch everything that could go wrong (such as a mistake in the location of the socket file). It will catch things that would prevent the Nginx server from starting at all. Output from this command should look similar to the output below if things are correct and is a good way to do a basic check before applying the configuration changes.

root@2480-Z:/home/ben# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Restart the Nginx server software to apply the configuration changes using the systemctl restart nginx command. You can check to make sure there were no errors in the configuration that prevented Nginx from restarting by using the systemctl status nginx command and checking the output to ensure it says Active: active (running). It would also be a good idea to make sure that the web browser on your administrative PC can still access your Linux server web site.

Once you are sure that Nginx has started properly and is serving pages create a new file named phptest.php in /var/www/html with a text editor. Put the following code into that file:

<?php
  phpinfo();
?>

This PHP code (the phpinfo(); command inside the <?php and ?> section) will be expanded out by PHP into a bunh of HTML code that your web browser can display about the status of PHP on your system. Try accessing the page you just created at http://172.17.xx.xx/phptest.php on the web browser on your administrative PC and make sure you can see the PHP diagnostic information page.

Let’s try and setup a very simple example of a PHP web application which can take a user’s name from a form and display it back to them on a web page. For this example we will need to create two files on our web server. One of the files will be an HTML form which collects the name of the user and the other is a PHP script which receives the name of the user from the form when the user submits it and displays a welcome message back to them.

First, create a form.html file in /var/www/html with a text editor. Put the following code into that file:

<html>
<body>

<h2>HTML Forms</h2>
<p>Please Enter Your Name Below</p>
<form action="/welcome.php" method="POST">
  <label for="name">Name:</label><br>
  <input type="text" id="name" name="username"><br>
  <input type="submit" value="Submit">
</form>

</body>
</html>

This will give the user a place to enter their name onto the web page using an HTML form. When the user presses the "Submit" button the contents of the form will be sent from their browser to the welcome.php page on the server using an HTTP POST method. The welcome.php script will then need to process them (and in our case respond with a welcome message) so now create a welcome.php file in /var/www/html with a text editor. Put the following code into that file:

<html>
<body>

<h1>Welcome to my website <?php echo $_POST["username"]; ?>!</h1>

</body>
</html>

You can see that this page is mostly HTML but contains some PHP inside of the <?php and ?> section which gets the name received in the HTTP POST message and outputs it in that spot.

Try accessing http://172.17.xx.xx/form.html and make sure your form and PHP welcome page work correctly with your name.

There is obviously a lot more to coding more complex PHP applications including being able to store and recall information from databases, important security considerations, performance considerations if a large number of users are accessing the site, and more. Luckily, there are many tutorials on the Internet where you can learn more about coding PHP now that you understand the basics and how to setup a Nginx server to serve PHP files.

Close the SSH session

If you are using the Administrative PC in Netlab instead of your own computer as the administrative computer you should also shut down that system in the usual way each time you are done with the Netlab system and then end your Netlab Reservation. You should do these steps each time you finish using the adminsitrative PC in future labs as well.