homebrewserver.club Yes We're Config!™
The homebrewserver.club principles

Promote approaches, not apps

We privilege general approaches over particular software applications. We try to contextualize our technical choices socially, politically and economically to provide in-depth understanding and prevent The Best Way™ solutionism. For these reasons we like free and open source software as a starting point and try to provide documentation for others to learn as well.

Take the ‘home’ in homebrewserver.club literally and the ‘self’ in self-hosting figuratively

That means we try to host from our homes rather than from data centers - a.k.a. ‘the cloud’ - and we try to host for and with our communities rather than just for ourselves.

Make space for learning together

Primarily the homebrewserver.club wants to be a space for learning together. This either means that you are knowledgable about a topic and willing to share or that you are curious and willing to learn. We are all about the long route that provides grounded understandings instead of mindlessly copy pasting things into the terminal to install software via $current_hip_framework.

Yes, We’re Config™

We try help each other out out but we can’t do the work for you. We’re Config, meaning we’re comfy with figuring things out and making mistakes. We take pleasure in researching configurations and in the struggle of getting things working. We gladly lend you a helping hand, but we won’t be able to hold your hand through the whole process.

Serve from constraints

Having a homebrew server means owning up to the fact that you are serving from constraints. You don’t have the fastest connection. You use as little power as possible. Your server is some spare laptop you had lying around. You want as little maintenance or worrying as possible. You’re not on 24/7 stand by if there is an issue. All of that is perfectly ok. Knowing this influences our choices in terms of what to run and how.

Be an amateur

What works for data centers and the industry does not necessarily work for homebrew servers. As such, the homebrewserver.club documentation won’t be exhaustive. We rather intend to add to existing on-line knowledge, particularly from the perspective of the homebrew server admin.

Embrace the Feminist Server Manifesto

We subscribe to the principles of the Feminist Server Manifesto forwarded by our friends at Constant, a non-profit, artist-run organisation based in Brussels active in the fields of art, media and technology.

Aspire to broaden participation

By publishing guides and tutorials, we hope to facilitate the means for diverse communities to learn how to set up and run their server according to their needs, goals and principles. For us, this means our channels of communication are an harassment-free experience for everyone, regardless of gender, gender expression, race, ethnicity, religion, sexual orientation, sexual characteristics, disability, age or technological ability. Individuals promoting bigotry will be removed from the channels.

Homebrewserver.club.pdf
homebrewserver.club Yes We're Config!™
Considerations for server hardware

Introduction

You want to get started with self-hosting. This means you will need a computer that will be your server. But what makes a good server?

First, while dedicated server equipment does exist, in the case of the homebrew server it is more helpful to think of a ‘server’ as a function rather than as a special machine.

Why? Because dedicated servers are expensive, loud, specialized and power hungry devices. At the same time any spare computer with a network port running GNU/Linux can become a server.

It really depends what exactly you plan to do with it, but the odds are that 10 year old laptop you have lying around is more than up to the task of hosting light personal websites, a chat server, mail and more!

Considerations for servers

One of the main strategies of the homebrewserver.club is re-use. You re-use your existing internet connection at home and likewise you can also re-use old equipment you have as a server.

In general there are a few things you want to take in consideration when determining what hardware to use.

Power usage

All computers use power, but some use more than others. The function of the server is to be on-line and on the network 24/7 (although that is not always necessary). That means power usage is an important consideration, not only because it will cost you money but also because it will have an environmental impact.

You can get an approximation of power usage of a machine by looking at the power rating on the power supply or AC adapter. This value is usually expressed in Watt (or W). That number represents the theoretical maximum draw of that system, it might use less but not more. The laptop this article is written on is rated 65W but average consumption is about 10W.

So how to calculate what that costs for a year of usage? First let’s asume that this value is indeed the Watt per hour (Wh). Multiply that number by 24 to get the usage in a day.

10 Wh * 24 hours = 240Wh or 0.24KWh

Having the KWh figure will let you use that value to compare against your utilities bill.

Multiply it by the number of days in a year to get a sense of the costs on a yearly basis.

240 Wh * 365 days = 87600 Wh or 87.6 KWh

The price for electricity where I am is €0,24 per KWh so on a yearly basis that is €21 euros. On a monthly basis that is €1,75.

Considering power consumption at extreme ends.

A PC tower made for gaming that needs a 300 Watt supply can use up to 2,628 KWh of electricity a year, which would cost up to €630. That is only a little less than the average inhabitant of this planet uses in total during a year1. At the same time a Single Board Computer (like this one uses a maximum of 1.3 Watt (without peripherals). That comes down to 11.3 KWh or €3,20 on a yearly basis. Now these are both rough measures and power usage will likely be lower. However, this calculation does indicate that the choice of hardware and resulting power consumption do matter.

Energy consumption vs embodied energy.

While older equipment will use more power for the same (or less) performance as newer equipment this should not be your only consideration, especially when running on renewable power sources. In fact, the overwhelmingly largest part of energy usage of digital technology comes from manufacture and not usage. Environmentally, it can make more sense to reuse an older, less energy efficient, device rather than investing in a newer energy efficient device.

Benefits and disadvantages of laptops as servers

Laptops make good homebrew servers since they are widely available, relatively powerful and energy efficient. Aside from that they have the benefit of having a screen, keyboard and battery.

If you are just starting out with running a server and are not yet so comfortable with the command line and ssh it can be a real benefit as you can work on the machine directly. Aside from that the laptop battery can mitigate sudden power outages, so that the laptop can shut itself down gracefully if power runs out.

Laptops will also have the ability to hold one or more harddisks and plenty of USB ports for connecting multiple peripherals.

It is not unlikely that you have one lying around or will be able to find one in a thriftstore or on the second hand market.

Disadvantages can be size, sound, heat generation and power consumption (in particular if you don’t tune the power management to turn off the screen).

Single Board Computers

Arguably the ideal homebrew server hardware is the Single Board Computer (SBC). These are often very small computers on a single chip. They are aimed at hobbyists and meant for prototyping. Popular brands are RaspberryPi, BeagleBone, Hardkernel and Olimex.

They typically use the same ARM processors as used in smart phones meaning they are extremely energy efficient, using only a few Watts of energy under full load. Most models don’t use active cooling so they make no sound, which is a boon in domestic environments. They can also be very cheap, ranging from €10 to €50.

The disadvantages are that, compared to a laptop, they are relatively ‘incomplete’. You will need at the very least get an SD card and 5V charger to use them. They don’t have a battery meaning that a power outage will shut it off without warning, possibly corrupting the SD-card. In terms of performance they usually have less RAM available than a laptop. Their bus bandwith to read/write disks they can also be lacking.

Having said that there are some boards which are really well optimized for homebrew server usage, such as the Olimex boards. These have SATA ports (for connecting HDDs), are able to use Li-Po batteries, Gigabit Ethernet ports and decent amounts of RAM. You will also find many SBCs on the second hand market.

In general there are quite some Free Software distributions optimized for single board computers such as Armbian.

Virtual Private Server

Sometimes it is not possible to take the ‘home’ in homebrewserver.club literally because your Internet Service Provider may be blocking certain ports or types of traffic.

A possible alternative is then to consider a Virtual Private Server (VPS). These are servers, that for all practical purposes (including root access) are usable in the same way as a physical server. These VPSes are usually located in datacenters and offered by hosting companies. They are software only, hence virtual, and usually multiple VPSs share a single physical machine.

They can be found for as little as €3 a month.

The great advantage of a VPS is that you won’t have port restrictions, traffic shaping and generally a fast uplink. Aside from that, a VPS means no hardware maintenance and it’s not your personal IP-address.

The downsides are that you are essentially renting, storage space tends to be relatively expensive, you might not always have full control over the kernel and OS. For the paranoid it might mean that since your entire system is running in a physical machine’s RAM, it is possible to retrieve your sensitive data without you knowing.

Costs of the homebrew server

One of the things that might hold one back are the costs involved in the whole undertaking.

As an example one can take my personal setup which I have been running since 2014. At the time I paid around €75 for a new Olimex Micro (2ghz, 2 cores, 1GB ram) including peripherals, such as a high performance SD card and power supply. Later I spent another €80 for a 2TB HDD. In terms of energy usage the upper bound is at 10Wh meaning €21 yearly.

So in total €75 + €80 + €105 (€21x 5 years) = €260. Per year this means €52 or about €4,30 a month maximum. So while the upfront cost can be substantial, the cost over time is really manageable. Especially if you share it with a bunch of friends!

If you can reuse old equipment the costs would be only for electricity, since you’ve already been paying for your ISP connection and reuse hardware.

As for a VPS, if one compares the processing power of lower-tier VPS providers one can get 1 core 2Ghz and 2GB RAM for about €3. This is equivalent to low-end SBCs but if one starts to add storage to the VPS, the price quickly ramps up.


  1. See per capita electricity consumption for the world population: https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption 

choosing-a-homebrew-server.pdf
homebrewserver.club Yes We're Config!™
Demystifying SSH

Introduction

Some of the essential things that separate a server from other computers is that first they are usually not where you are and second that often come without screen and keyboard. With homebrewservers this is particularly the case when using Single Board Computers (SBC).

In order to use a server you need to connect to it over the network using the command-line interface or shell. This is usually done with a program called SSH which stands for Secure Shell.

One of the more important and foundational skills needed for experimenting and maintaining servers is understanding, using and troubleshooting SSH.

Setting up and using SSH can be a challenge at first. There are many moving parts to consider. Working with SSH means knowing something about user accounts, permissions, public key cryptography, protocols, clients, servers and agents. And yet despite so much to consider, SSH is praised as something easy to use and quite often presupposed knowledge between peers.

With this in mind, there is a need to demystify SSH. In this guide we aim to show how to setup an SSH client and server as well as discuss common issues and approaches for day to day use and troubleshooting.

Prerequisites

A basic understanding of the command-line is required.

The SSH ecosystem is very well established. It is available on all modern GNU/Linux distributions, MacOS and Windows. You can use your home server or if you don’t have one yet you can use your own personal laptop to experiment (in this case, your laptop will play the role of both the server and client as explained later).

The commands shown in this guide were run on a Debian Stretch distribution but the actual tool names should be the same on other distributions.

SSH and OpenSSH

The term “SSH” can refer to a number of different but related things.

SSH stands for the Secure Shell which is a protocol for describing how to provide a secure channel of communication from a client to a server. However, it more typically refers to the OpenSSH suite of tools which are the programs you will install and use when dealing with SSH.

The OpenSSH tools are an implementation of the SSH protocol. This means that these tools follow the behaviour described in the documents of the protocol.

Installing the SSH server and client

It is important to understand the client/server architecture of SSH. If you are remotely connecting to your home server from your laptop, then your laptop is the client and the home server is the server.

There are two packages which contain all the tools that the OpenSSH tool suite provides. The openssh-server and openssh-client packages.

To install the SSH server on your home server, run:

$ sudo apt install -y openssh-server

And on your client, run:

$ sudo apt install -y openssh-client

Creating a user account on the server

In order for your client to connect to the server, a user account must be created on the server. This can be done with the following command (where homebrewer is the new user account):

$ sudo useradd --create-home --shell /bin/bash homebrewer

You should then set a password for this new user:

$ sudo passwd homebrewer

This password will be used in the following step.

Logging in for the first time

You can now SSH into the server from your client. Assuming that you have a DNS entry which points to your home server (myhomebrewserver.com) then you can log in with:

$ ssh homebrewer@myhomebrewserver.com

On first connection to a new server, you will be shown a fingerprint and asked if you would like to continue connecting. For now, choose to continue without validating the fingerprint.

You should then be asked for the password that you entered when creating the account. If you have any issues at this point, please see the Troubleshooting SSH section.

Passwords, keys and security

As we have seen so far, connecting to an SSH server using password authorisation is relatively simple. However, password authorisation is typically recommended against due to security considerations.

Security is relative and you may not be concerned with defending against a brute-force attack. However, since other methods of authorisation are so commonly used and often the source of of problems when dealing with SSH connectivity, we will also cover this topic also.

The alternative to password authorisation is public key cryptography. The idea is to generate two keys, one public and the other private. The public key part can be shared publicly and will be registered with the SSH server. The private key part cannot be shared with anyone else and will be used on the client side for authentication.

For those not familiar with public key encryption, a brief and pragmatic introduction is provided by this ssd.eff.org guide.

Validating server host keys

When logging into your server you were asked to validate a key fingerprint:

The authenticity of host 'myhomebrewserver (666.666.666.666)' ed.
ECDSA key fingerprint is SHA256:lUhBmQXjkOL0zyoDNarUIbhd3RXo7X
Are you sure you want to continue connecting (yes/no)?

When an SSH server is installed, key pairs are generated on the server. The design of SSH is such that when you make a secure connection you should be sure that where you are connecting to is the server you expect.

On the server, you can validate that this is the fingerprint you expect:

$ sudo ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key
256 SHA256:lUhBmQXjkOL0zyoDNarUIbhd3RXo7X root@myhomebrewserver (ECDSA)

These values should match the ones you were first shown. Where the ECDSA in the first message corresponds to the key file name in /etc/ssh/. The SSH server will generate key pairs for each algorithm it supports.

As you have accepted your server host key fingerprint, the public key of the server will be placed in your $HOME/.ssh/known_hosts file on your client where it will be remembered for future connections.

If the host key ever changes, you will see something like:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
...

This simply means that that the host key you accepted for this host has changed and you should first figure out why this is the case before making a secure connection.

Dealing with SSH keys

Generating a public and private key pair

Now that we understand the idea of host keys, we should generate client keys. On your client, run the following:

$ ssh-keygen -t ed25519

This uses the currently preferred algorithm for generating keys. The key generation will ask you to enter a passphrase. It is typically recommended use a strong passphrase (see diceware) for the reason that if someone else gets your private key part, they still will still not be able to use it because they also need to know the passphrase.

You should now have two keys in your $HOME/.ssh folder. A id_ed25519 (private key part) and a id_ed25519.pub file (public key part).

Your public key part might look something like:

$ cat $HOME/.ssh/id_ed25519
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOTWIy+Em89QR/Xs6RUmr+0U0F3GVXY/UA2MXs9MoqdY myuser@myhost

You can then start an ssh-agent instance and register the private key part:

$ eval "$(ssh-agent -s)"
$ ssh-add $HOME/.ssh/id_ed25519

The ssh-agent should ask for your passphrase. The agent is useful because it will store the passphrase of your key and re-use it the next time you log into the server. This can be particularly useful later on when you need to use multiple SSH keys.

You can confirm that the ssh-agent has loaded this key by running:

$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOTWIy+Em89QR/Xs6RUmr+0U0F3GVXY/UA2MXs9MoqdY myuser@myhost

And finally, you can then configure your client to use this key. Create a $HOME/.ssh/config file and put something like the following configuration into it (remember to replace with your server details):

Host myhomebrewserver
  Hostname myhomebrewserver.com
  User homebrewer
  Port 22
  IdentityFile ~/.ssh/id_ed25519

This is useful because it allows you to only type:

$ ssh myhomebrewserver

And the correct hostname, user, port and key will be chosen. However, before connecting, you must register your public key part on the server.

Register the public key with the server

On the server, you should register the public key. This is achieved by putting the public key part of the key into the /home/homebrewer/.ssh/authorized_keys file.

You can do this like so (replace the public key part with the one you generated):

$ sudo -su homebrewser
$ cd $HOME && mkdir .ssh
$ echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOTWIy+Em89QR/Xs6RUmr+0U0F3GVXY/UA2MXs9MoqdY myuser@myhost" > .ssh/authorized_keys

You must then ensure that your SSH server is accepting keys as a method of authentication. You should edit the /etc/ssh/sshd_config file which is the main configuration file for the SSH server.

You need to ensure the following is present:

PubkeyAuthentication yes

After editing the file, save your changes and then validate the configuration:

$ sudo sshd -t

No output should be shown if everything is validating correctly. This is important to do before restarting the SSH server in case you lock yourself out of the server.

You can restart the SSH server with:

$ sudo systemctl restart sshd

Now it should be possible to connect from your client with:

$ ssh myhomebrewserver

If you have any issues, please see the Troubleshooting SSH section.

Troubleshooting SSH

Despite our best intentions, we are often confronted with a failed login attempt:

$ ssh myhomebrewserver
Permission denied (publickey).

This is not the most helpful message. In order to go about solving this issue, we need to focus our detective work on the client/server architecture and try to discover which side is responsible for the problem. Hopefully the following tips can help you in this process.

On the server

Here are some questions to ask yourself:

  • Is your public key registered on the server in the $HOME/.ssh/authorized_keys folder?
  • Are the $HOME/.ssh permissions correct? (see here)
  • Is the SSH server running?
  • Is the /etc/ssh/ssd_config correct?
  • What does sudo tail -f /var/log/auth.log say?

On the client

Here are some questions to ask yourself:

  • What does ssh -vvvvv myhomebrewserver tell you?
  • Are the $HOME/.ssh folder permissions correct? (see here)
  • Is the SSH server available at the port you expect?
  • Is your $HOME/.ssh/config correct?
  • What is registered with the local ssh-agent?

Conclusions

As we can see, SSH is no simple topic! There are many moving parts and a number of topics which require familiarity in order to be able to get remote access to your server.

Further Reading

demystifying-ssh.pdf
homebrewserver.club Yes We're Config!™
Port Forwarding configuration for your home router

Introduction

The whole premise of the homebrewserver.club is the simple — yet often overlooked — fact that your home internet subscription theoretically also allows you to host services. The internet is in its essence a bi-directional medium. Anyone with an internet connection can not only look up on-line content but also host it!

In times of ‘cloud providers’ and ‘virtual private servers’ it is an easy thing to forget, and internet service providers don’t make it easy on you either, but a homebrew server can be as simple as an old laptop connected directly to your home router. However, you do need to change some settings on the router to make that happen!

Requirements

To begin serving from home you need the following:

  • Make sure you have physical access to your home router.
  • Get to know the password of the admin user (this is usually provided in the box or written on the label on the underside of the router).
  • Have an available power socket next to your router.
  • Have a homeserver with a web server and open SSH server running on it.
  • An ethernet cable to connect your server to the router.

Port forwarding theory

A schematic representation depicting network address translation between a local area network and a wide area network, where ports are being forwarded from the WAN to home server on the LAN

By default home routers have configured the firewall so that the devices behind your router are inaccessible to the internet. This is to prevent your private network from being public.

Machines behind your router (called your local area network or LAN) can make connections to the wider internet (known as WAN), but not the other way around.

However, when hosting a server at home, we do want that server to be reachable from the internet. In order to do that we need to open so-called network ports.

Ports are logical ‘gates’ that are open or closed to connections. These ports have numbers and are standardized for specific protocols or applications. For example, HTTP traffic from a website would default to port 80. HTTPS defaults to 443 and SSH defaults to port 22.

To make our server accessible over the internet we need to open the ports on the router and forward them to our server. This is called port-forwarding.

The exact method (and terminology) of port-forwarding differs from router to router. However, it always follows a similar scheme where you designate inbound traffic on a certain port to be forwarded to the your server’s IP-address and port on the local area network.

For this you need to have access to the administrative panel of your router.

Find your router

To access the administrative panel of your router you need to find it’s IP-address. You can do this by connecting to that router via Ethernet or Wi-Fi and then finding out what your own IP-address is.

On Debian based systems this is done like this in the terminal:

$ ifconfig

If you get a command not found warning try this:

$ ip address

This will return information on your network connection. Look for the line saying inet

3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether ac:ab:00:00:ac:ab brd ff:ff:ff:ff:ff:ff
inet 192.168.1.11/24 brd 192.168.1.255 scope global wlp3s0
   valid_lft forever preferred_lft forever
inet6 fe80::eab1:fcff:acab:374e/64 scope link
   valid_lft forever preferred_lft forever

In this case the IP-address is 192.168.1.11 as a rule of thumb you can then change the last digit to either 1 or 254 to find the router.

Log in to your home router and get to know your LAN

Using a web browser navigate to the IP-address you found above to reveal the router’s admin panel. It should provide you with a log in field where you can enter the router’s admin details to get access to the control panel.

There you will see a lot of possible settings. Look at the options “LAN”, “DHCP Leases” or “Network” to get an overview of all the devices.

Connect your home server

Use an ethernet cable to connect your home server to your router. In case that it has ethernet ports in different colors/markings make sure you take something that says either LAN or INET.

Have a look at your router’s interface again and look for the IP-address that your server was assigned. In this guide I’ll assume it was 192.168.1.10.

Next try to find an option called “Static (DHCP) Lease” or “DHCP Binding” or something similar in your LAN view. Then make sure to assign your server a static DHCP lease. This will make sure that the server is always reachable under the same IP-addres.

Forward the ports

Once you’ve set up a static lease to your home server you can start port forwarding. Depending on the make of the router it can be also be called Port Sharing or Traffic Forwarding. Again, depending on the make of the router, it can be found under the tabs ‘security’, ‘access control’ or ‘internet’.1

The basic process is to determine which external port to open and to which IP address on the LAN and which port to forward it to.

You might be asked a few things, including the name of the rule, the protocol (TCP, UDP or both), the external port and the internal port. Sometimes you are given the option to open a range of ports.

To open the ports for the web server, we’re opening two separate ports, one for plain HTTP and one for secure HTTP.

Open the external port 80 for plain HTTP and redirect it to the local IP-address of the homeserver:

 Name: "HTTP Homeserver"
 Protocol: TCP
 Device: 192.168.1.10
 External Port: 80
 Port to device: 80

Open the external port 443 for HTTPS and redirect it to the local IP-address of the homeserver:

 Name: "HTTPS Homeserver"
 Protocol: TCP
 Device: 192.168.1.10
 External Port: 443
 Port to device: 443

Lastly we will open a port for SSH. The change here is that we open the external port 9999 and map that to 22 internally. Setting SSH on a non-standard port is a low-level way to prevent automated scripts gaining access to your homeserver. TODO add link to basic security

Name: "SSH Homeserver"
Protocol: TCP
Device: 192.168.1.10
External Port: 9999
Port to device: 22

Concluding

Now that you have opened the corresponding ports you should be able to type your external IP-address in your browser and should be automatically redirected to the website on your home server.

How to find out which ports to open?

While a majority of applications will work on 80 and 443 you might need to open different port for different applications. For example in the series describing self-hosted chat over XMPP ports 5000, 5222, 5269 and 5281 are opened and forwarded.

Most installation guides for software will tell you whether you need to open ports. However it is also possible to see what applications are listening to what port using:

$ netstat -tulp.


  1. https://portforward.com/ has a large list of routers and visual instructions on how to set up port forwarding on them. 

fundamentals-port-forwarding.pdf
homebrewserver.club Yes We're Config!™
Setting up a web server

Introduction

Ever wanted to host your own website from the comfort of your house? Ever wondered how to achieve this? Search no further! This guide will help you with the installation and configuration of web server software, which is what allows a computer to start handling HTTP requests and serve web content in response.

Besides helping you with the installation, this guide will help you getting the right certificates, configuring your server and publishing your homebrew served website.

Some background knowledge

First off: what is the web, what is a web site and what is a web server?

The web is the single most known part of the internet. Because of that, it often happens that ‘the web’ and ‘the internet’ become conflated. Therefore, it often becomes a bit hazy to state what the difference is between the internet and the web.
Generally speaking ‘the web’ is only the part of the internet that we interact with with a web browser. More technically speaking, the web is the part of the internet that runs on port 80 and port 443 and that uses the HTTP and HTTPS protocols.

Websites are text documents that are formatted through HTML, CSS and JS. These three technologies tell the web browser what the structure of the page is, how it should be laid out and what kind of interactions are possible. Websites are transmitted using Hyper Text Transfer Protocol, which is why we usually type them like so http://homebrewserver.club.

A web server is a piece of software which listens for and responds to HTTP requests.

So in essence the web is a network of webservers which runs on top of the internet and through which websites can be retrieved.

Requirements

  • A spare computer.
  • A basic understanding of the command line.
  • An ssh server and client installed.
  • A registered domain name.
  • Have an available power socket next to your router.
  • An ethernet cable to connect your server to the router.

The instructions on this guide were run on a Debian Stretch distribution.

Installing Apache

The Apache HTTP server is a free and open-source web server software and it has been around since 1995, being the most widely used server software in the world. Because of this, documentation is plentiful and the support community is very large, meaning that help is quite easy to get for any of your web server issues.
For this reason, Apache has been selected for this guide.

There are, of course, other web server software available, the most popular of which being Nginx. Nginx, which is also free and open-source software, arrived on the scene circa 2004, and it also became a favourite for its resource efficiency.

If you want to geek out further about the differences between Apache and Nginx, this article will give you an overview.

So, without further ado, open a terminal window and let’s get started:

First, make sure you update your packages list:

$ sudo apt update

Then, install the Apache HTTP server software:

$ sudo apt install apache2

If all went well, Apache should have been started immediately after installation. To double check this, run:

$ sudo systemctl status apache2

Example output:

 apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset:
   Active: active (running) since Sat 2019-06-22 21:29:51 UTC; 6s ago
 Main PID: 18398 (apache2)
      CPU: 573ms
   CGroup: /system.slice/apache2.service
           ├─18398 /usr/sbin/apache2 -k start
           ├─18402 /usr/sbin/apache2 -k start
           ├─18403 /usr/sbin/apache2 -k start
           ├─18404 /usr/sbin/apache2 -k start
           ├─18405 /usr/sbin/apache2 -k start
           └─18406 /usr/sbin/apache2 -k start

Jun 22 21:29:50 supermuch systemd[1]: Starting The Apache HTTP Server...
Jun 22 21:29:51 supermuch systemd[1]: Started The Apache HTTP Server.

Configuration Time

You can find Apache’s configuration files in the following location: /etc/apache2/sites-available.

The 000-default.conf file should look a little something like this:

ServerAdmin webmaster@localhost
<VirtualHost *:80>
        
        # ServerName example.org

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

For ease of use, and in case you would like to have several websites/services running behind a single server, copy this file into another, easily identifiable one, for example, calling it something like “mydomain.conf”.

$ sudo cp 000-default.conf mydomain.conf

Using your favourite text editor, uncomment the ServerName line and change it to reflect your domain name:

ServerAdmin webmaster@localhost
<VirtualHost *:80>
        ServerName mydomain.org

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/mydomain.error.log
        CustomLog ${APACHE_LOG_DIR}/mydomain.access.log combined

</VirtualHost>

Enable this configuration by running:

$ sudo a2ensite mydomain.org

Restart Apache to load the new configuration:

$ sudo service apache2 restart

HTTPS

HTTPS, which stands for hypertext transfer protocol secure, is an extension of the HTTP protocol. As its name suggests, it adds a layer of security to the data exchanged between client and server. By adding an encryption layer to the exchanged packets, it seeks to avoid man-in-the-middle attacks, eavesdropping, etc. While HTTP uses port 80 by default, HTTPS uses port 443.

As part of its bigger goal to “encrypt the entire Internet”, the Electronic Frontier Foundation developed Certbot, a free and open source tool for automating the server-side deployment of Let’s Encrypt Certificates, thus enabling HTTPS.

Let’s get down to it! Again, these instructions are specific to Debian 9 (Stretch), but detailed instructions for installation on other distros can be found on Certbot’s website.

First, add backports to your packages list and update it:

$ echo deb http://deb.debian.org/debian stretch-backports main | sudo tee -a /etc/apt/sources.list && sudo apt update

Now, install Certbot:

$ sudo apt install certbot python-certbot-apache -t stretch-backports

Run Certbot to get the right certificates for your domain:

$ sudo certbot certonly -d myserver.org

After following the process, and if all went well, you should now see the following message:

- Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/mydomain.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/mydomain.org/privkey.pem
   Your cert will expire on 2019-09-24. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Now, it is time to edit your /etc/apache2/sites-available/mydomain.conf file accordingly:

<VirtualHost *:80>
        ServerName mydomain.org

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/mydomain.error.log
        CustomLog ${APACHE_LOG_DIR}/mydomain.access.log combined
</VirtualHost>

#NEW CONFIG STARTS HERE
<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName mydomain.org

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/mydomain.error.log
        CustomLog ${APACHE_LOG_DIR}/mydomain.access.log combined

    SSLEngine on
  #PATH TO YOUR CERTIFICATES (note: don't forget to replace mydomain.org with your actual domain name!)
    SSLCertificateFile /etc/letsencrypt/live/mydomain.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.org/privkey.pem
</VirtualHost>
</IfModule>

In case you didn’t notice, there is now an if statement that evaluates true in case a certain module is present. In this case, it evaluates to true if mod_ssl is present. Apache modules can be installed as following:

$ sudo a2enmod modulename

To verify which modules are already running on your server, type:

$ sudo apache2ctl -M

If the required ssl_module is not listed, run:

$ sudo a2enmod ssl

Certificate renewal

Your certificates expire after a period of time. You can, however, automate renewal by adding a cron job that schedules when the specific renewal command should be run.

Start by running:

sudo crontab -e

Add the following:

5 55 0 * 5  /usr/bin/certbot renew

This means the certificates will be renewed every week on Friday at 05:55. You can of course edit these times according to your preferences! Save your changes and exit the editor.
Time to restart Apache and load all of these changes!

index.html

At this point, when typing https://mydomain.org into your browser, you should be greeted with a page that looks a little something like this:

Default apache on debian index.html page

If you cd into your /var/www/html folder, you will find this default index.html. As recommended by this page itself, you should edit this file before continuing operations on your webserver.
Open it on your favourite text editor and let’s get started on a bare-bones “Hello Homebrew World”! webpage.

<!doctype html>

<html lang="en">
<head>
  <meta charset="utf-8">
  <title>My first homebrewed webpage</title>
</head>

<body>
  <h1>Hello Homebrew World!</h1>
</body>
</html>

Open your browser again and savour the fruits of your hard work.

That was it! Now you are ready to have hours of endless fun sailing the vast sea of HTML, CSS, JavaScript, etc.

fundamentals-webserver-website.pdf
../