The LAMP stack (part one)

The LAMP is where most of it begins

It’s been such a long time I don’t write anything here. I’ve been writing, scribbling notes here and there, journaling every now and then. Taking notes, hundreds of notes for upcoming articles. But that’s about it. Nothing is coming alive. I’m sorry for that.

I took the Cloudskills Linux Cloud Engineer Bootcamp. It was a lot of fun, and I learned quite a lot. There’s a lab where you install the LAMP stack in an Azure VM. I had tried it before, but now I had it documented. Document what you’re doing! Be it easy, be it tough. Just document it!

Installing the LAMP stack is a very common exercise and you should try it yourself. You can check the exercise from the bootcamp here.

I installed the LAMP successfully, but I wanted to go a little deeper. I wanted to try to setup a real, live web server. I did some search and I found this super cool book called Web-Base Projects that Rock the Class. I still haven’t finished the book, I’m going slowly, trying, retrying and documenting my progress as I move forward.

In this article, I’ll describe the first steps I took in this project. I installed Apache, setup a very simple HTML webpage, and configured a static IP address for my network connection using Network Manager.

Let’s see how it went!

Installing Apache

The Apache web server is one of the most popular web servers out there. It’s easy to use and super flexible, because of its modular design. Apache is huge, and it’s beautiful. It’s been around for some time, and there are lots of great people that contribute to Apache being this awesome tool.

Check this documentary about the Apache Foundation.

For this project, I’m using my old and puny Lenovo laptop running Xubuntu. This is a great thing about Linux. You can still save your old machine that’s sitting forgotten in a corner. Xubuntu is a desktop distribution, not a server one, but it worked well for this home project.

The Apache software is known as apache2, and in order to install it in a Debian based machine, we run the following command.

$ sudo apt install apache2

Once installation is finished, Apache will be running already. You can check it’s really running with the systemctl command.

$ sudo systemctl status apache2

Here’s the output of this command.

This means that the web server is up and running, and ready to serve. When you first install Apache, you’ll see a default webpage. If you simply type localhost on your browser, you’ll see it, and it looks like this.

This is the directory index. If you don’t specify any specific page in the browser’s window, this is the one you’ll see. You should spend 2 minutes reading its content. It’s actually useful. I don’t know if anybody actually read it.

This file is called index.html and it’s located at /var/www/html. We can edit this file with our own content, or we can create a brand new one. To be easier, I edited this same one, and replaced it with something super simple.

I used nano to edit the hmtl file. When I started my adventures in the terminal, I wanted to use just Vim, because it looked cool. I gave up after some tries. Now nano is my editor of choice.

The web server is live, but it can be accessed just from within our own LAN. To access the server from other computers in the LAN, we need to find out the private IP address. These private IP addresses are valid only internally. To be able to access it from outside, we need to set some routings. I’ll do that later, and share it with you.

To find the computer’s IP address, we run the ip command. This command is part of the iproute2 collection of utilities. There’s the ifconfig command too, but this one’s being replaced by ip. Both do the same, basically. Maybe in the not so distant future, ifconfig will disappear. I don’t know.

$ ip a

The a in the command above means address. This is the output of the command.

In my case, the interface number 2 is the one I’m looking for, the one called wlp2s0. This is my wireless interface (my laptop doesn’t have an ethernet interface). I know it’s a wireless interface because it starts with wl.

With this IP address we can access our web server from any machine connected to the LAN. I tried it, and it really works. Check it out!

Setting a static IP address

If you want your web server to be reachable from outside your own LAN, you need to set a static IP address, one that won’t change with every reboot. The most common configuration for a workstation in a LAN is to obtain its IP address with the Dynamic Host Configuration Protocol (DHCP). When a workstation is configured with DHCP, on startup the router assigns it a new IP address, a network mask, the IP address of the default gateway (this is the router itself), and the DNS server used for performing the translations between domain names and IP addresses. When your machine boots up, it may, or may not, be assigned the same IP address as the previous bootup.

A static IP address is mandatory for a server required to be available for servers across the Internet. We’ll need to manually configure the information that is provided by DHCP. There are different ways to do that. I did it with NetworkManager, a tool used to manage network devices and connections. NetworkManager usually comes preinstalled in almost every modern distro. You can choose between the GUI version or the command-line one (called nmcli). Let’s go with the nmcli for this project.

nmcli

We can see all the network connections available to the system with the following command.

$ nmcli c

The c stands for connection. You can also type nmcli connection. It’s the same thing.

Note down the name of the connection you want to configure. We’ll need to take it down before setting things. This is the command to take the connection down.

$ nmcli connection down CONNECTION_NAME

We can now edit the connection. To do this we’ll use the nmcli editing environment. Like that.

$ nmcli connection edit CONNECTION_NAME 

We’re now inside the nmcli editor, where we can make configuration changes to our network connection. This is the screen that greets us. We can see the groups we can edit, ipv4 being one of them. That’s the one we’ll edit.

To see the IPv4 properties we can edit, we run this command.

nmcli> print ipv4

The output of this command looks like this.

Notice the first line, ipv4.method. It says manual now, because I had changed it already before taking the screenshot. Yours probably says auto, which means it’s using DHCP. To change the method from auto to manual, we use the following command.

nmcli> set ipv4.method manual

We’ll now set an IP address, like so.

nmcli> set ipv4.addresses 192.168.1.46/24

I chose this specific IP address for no particular reason, just because it was the one DHCP had assigned to the workstation when I was editing these settings.

To provide a gateway, we follow the same pattern. NetworkManager will use this gateway data to build a default route for us.

nmcli> set ipv4.gateway 192.168.1.1

We can provide a DNS server, but this optional at this point. When you’re done, write save to save all the changes.

nmcli> save

To go back to the command-line, just type quit.

Back in the command-line, we need to bring the connection back up, like this.

$ nmcli connection up CONNECTION_NAME

We now have a static IP address configured.

This is the first step towards global dominance!

We now have static private IP address, and we’re ready to move beyond our LAN!

I enjoyed this exercise because I got to learn a bit more about networking, a fundamental thing to learn. There are lots of ways to do networking things on Linux, but one important distinction is that there are the temporary changes to network settings, and the permanent ones. We can use the iproute2 set of commands to make changes to our network, but these changes will last just as long as the machine is running. To make the changes stick, we need to use network configuration management tools, such as NetworkManager. Two other tools that serve this purpose are ifupdown and systemd-networkd. I don’t know much about these, but it will be a good idea to learn.

Another interesting tool to learn about is udev, the Linux subsystem for managing device events. It’s the code that detects when you have things plugged into your computer, like a network card, external hard drives (including USB thumb drives), mouses, keyboards, joysticks and gamepads, DVD-ROM drives, and so on. It’s udev who gives the names to the network interfaces once it detects them.

Next stop: managing Apache processes, logs, adding PHP functionalities, and making our web page available to the world.

I’m sure I missed something here. Please let me know if you found any mistakes, or if there’s another, more straightforward, way to achieve these results. That’s what’s cool about Linux. There are different ways to achieve the same results.

See you next time!