🇵🇱 Przejdź do polskiej wersji tego wpisu / Go to polish version of this post

In my previous post, I described how to get free access to a pretty good VPS – Oracle Cloud Free Tier. Today, I’ll present one of my proposals for what can be done with it, specifically showing how to turn such a server into a center for running self-hosted solutions in a simple way. We will install on it a tool, or rather a system, called YunoHost, which is used to run services and stands out for its very user-friendly graphical interface that allows even non-technical people to dive into the world of self-hosting. YunoHost is open-source software that, under a clear visual layout, has very well-written code that takes care of the proper technical configuration and security of the services that will be run on it.

EDIT: One of the readers rightly pointed out that not everyone wants to install YunoHost in the Oracle cloud and are here to learn how to do it, for example, on a machine that already has the Debian operating system installed. I recommend these people skip straight to the YunoHost Installation section.

Preparation

As I mentioned in the introduction, in the further part of this post, we will need a server in Oracle Cloud, which I wrote about in the post Free VPS with 4 OCPU, 24GB RAM and 200GB disk. Writing this tutorial, I assume that you, dear Reader, have already created an account on Oracle Cloud, launched an instance on it as I described, opened ports 80 and 443, enabled IPv6 support, and know how to connect via SSH. As always, I recommend using the convenient and free (for what we need) tool Termius.

Meeting the above conditions, we can get to work!

Installing Debian on the Oracle instance

If your created instance is 100% as I described, it means that you have installed the Ubuntu system on it. YunoHost only works on Debian, which is not on the list of available systems from Oracle. It’s not a big problem, just an additional step to convert our Ubuntu to Debian. We will use a ready-made script available on GitHub at this link.

UPDATE 2023-11-05: I have determined that it is important to add in this place that the above script will not work on every VPS! It works correctly on Oracle, but there has been a case where a remote server (not on Oracle) was completely killed using this script (the server did not recover after a restart, and it had to be rebuilt from scratch). Please keep this in mind.

Let’s connect to our VPS via SSH. Then let’s download the aforementioned script:

curl -fLO https://raw.githubusercontent.com/bohanyang/debi/master/debi.sh

Let’s give it permissions to execute:

chmod a+rx debi.sh

Now we need to perform an important step that is necessary for the proper execution of later actions. We need to share our SSH public key, which we use to log in to this server, and which will be able to be downloaded and used by the installer. We need to provide the installer with the key that will be placed on the newly installed Debian system. Without this, after completing the installation and conversion from Ubuntu to Debian, we would lose access to our server! There are many ways to do this, but I will present one that requires only an account on GitHub.

Instructions on how to add an SSH public key to your server on GitHub:

• If you don’t have an account on GitHub yet, you need to create one.
• After logging in, click on your avatar in the upper right corner and select Settings from the dropdown menu.
• In the Access section on the left, select SSH and GPG keys, and then on the right, click the green New SSH key button.
• In the window that appears, enter any name you want to identify this key in the Title field, leave Authentication Key as the Key type, and in the Key text field, enter your public SSH key.
• Important: Make sure to upload your public, NOT private key! The public key can be openly shared with anyone on the internet and poses no security risk to your server. However, the private key should be kept confidential and never shared anywhere, as it is the key that provides access to your server.
• Confirm by clicking the green Add SSH key button.

For clarity, I am presenting below the format of a sample public key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCvYkO7T45XKg95Jhj69xvzO+E74hdzO+KTeNLOsA2RwzAEeKkZCLGT1l3tWNZ57BuK0Umt5qbHOye/gTOAsY+kekIsyN27bzTlKx4O7GfmYIYNsByX0nj76JBCfcxazUwLCxIu6TC8Q+/1KGpwqfBV8rwLD0MEbFVm5ruSaEFDWw== blogtomaszdunia

The SSH key that has been shared will be available at:

https://github.com/<Your_GitHub_login>.keys

Now that we have shared our public SSH key, we can proceed with the installation of Debian on our server. We run the script:

sudo ./debi.sh --version 11 --authorized-keys-url https://github.com/<Your_GitHub_login>.keys

Note that you need to modify the content of this command by changing the phrase <Your_GitHub_login> to the appropriate value corresponding to your GitHub account name.

Now that everything is ready, we can start the installation by restarting the machine with the following command:

sudo shutdown -r now

We will of course be disconnected from the server. The process may take a few minutes, so be patient if you can’t connect to it immediately. In the meantime, we will also need to change the login details for SSH, as we will now be logging in to a completely different system. The username we will log in with will change. The old user was named ubuntu, and the new one is debian.

PS: If you feel the need to do so, after completing the installation, you can remove your public SSH key from GitHub.

YunoHost Installation

Once the configuration of Debian is completed, we can connect to the server. From this moment on, the instructions are universal for any device with Debian installed. First of all, update the system and its packages:

sudo apt update
sudo apt upgrade -y

Then, install the necessary components:

sudo apt install htop curl unzip tmux -y

Next, we will use the tmux (Terminal Multiplexer) tool, which in short allows for creating and managing multiple virtual terminals. Start a tmux session:

tmux new -s yuno

We switch to the root account:

sudo -i

We download the YunoHost installation script and start the installation:

curl https://install.yunohost.org | bash

The installation process is simple and there is practically nothing to do during it, so I won’t describe it in detail. After it is finished, we will receive a message that further configuration will take place through the browser by going to the following address:

https://<server_ip>/

This is how we do it, meaning we open the browser, enter the appropriate address, and confirm. We should see a warning that the connection may not be secure. This is a familiar behavior of the browser, which is dictated by the fact that we do not have an SSL certificate installed for this domain. At this stage, it is not important. We click through this warning, looking for a button that says I accept the risk and want to continue or something similar, the exact wording depends on the browser you are using.

We will see the YunoHost welcome screen, which congratulates us on a successful installation and encourages us to further configure it. So we click the Start button [1]. In the main domain settings, we define the alias under which this administrative panel (and user panel) will be available, so we set up the alias that will allow us to avoid using the server’s IP address as a link to our YunoHost. There are two options: you can attach your external domain (or subdomain) here or use subdomains provided by YunoHost. They may end with:

• nohost.me
• noho.st
• ynh.fr

To avoid complications, we will use the second option, so we select the I don’t own a domain… option [2], type in the chosen character string in the Domain name text field [3], and confirm with the Next button [4]. On the next page, we create an administrator account. We fill in the fields: username [5], Full name [6], and enter the password twice [7]. We confirm with the Next button [8]. I probably don’t need to remind anyone here that the password should be strong enough as it is the only protection for our administrative panel against unauthorized access, and this whole infrastructure is available on the open Internet. Finally, we will be asked to confirm with the OK button [9]. After all this, we just have to wait for the process to finish, and we will be taken to the main control panel.

It is important that from now on, you should connect to the server using the credentials provided during the administrator account creation. Therefore, do not log in as the user debian but as the newly created user and use the new password instead of the SSH key. After the first login, it is good to return to logging in using SSH keys. I described how to do it here. It is also important to disable password authentication through the YunoHost web interface by going to (Main control panel) -> Tools -> YunoHost settings -> SSH section -> Password authentication -> change it to No, not by editing the sshd_config file as described in this post. Of course, both methods will work the same, but by editing the file from the terminal, YunoHost will later report it as an error that it has detected its modification, which can cause configuration conflicts.

Basic configuration – preparing to work

After entering the main control panel of YunoHost, I recommend that you first go to System update. The system will be immediately scanned for packages that can be updated. After scanning is completed, confirm by clicking the green Update all packages button at the bottom. After starting the first services, it will also be possible to update them from this menu. After seeing two messages – All system packages are up to date! and All programs are up to date! – return to the main panel.

Next, the place we should check is Diagnostics. It is a smart YunoHost tool whose task is to scan our configuration and check if everything is set correctly. After the scan is complete, we will see four types of markers:

• Blue – informational, presenting important information but not requiring action,
• Green – confirming that a certain parameter is set correctly,
• Yellow – indicating that something is not set correctly, but it is not a critical function,
• Red – critical, indicating that something important is set incorrectly and thus something may not work properly.

It is reasonable to address the issues marked in red first. In my case, the diagnostic tool reported a problem that I have correctly opened ports 22, 80, and 443, but opening posts 25, 587, 993, 5222, and 5269 is also required for proper operation. The other red markers were in the Email section, but we will not worry about them now because they are caused by the fact that port 25 is currently closed.

We were pointed out which ports to open, so let’s do it. I have described how to do it in Oracle Cloud quite extensively here (using the example of ports 80 and 443). The only difference is that we need to make the changes only from the Oracle interface (add appropriate Ingress Rules), because YunoHost will take care of everything from the server side. Remember to also open ports in the IPv6 addressing range. After making the changes, we run the diagnostic process again.

In my case, there were still two red markers related to mail handling. Both indicate a problem with sending mail, because despite opening port 25, it seems closed, and there is also a problem with reverse DNS. This is probably due to the fact that some cloud service providers block the ability to send mail from their offered servers, and it seems that Oracle belongs to this group. It can be bypassed by using an appropriate relay, but we will not deal with it today.

Since we have the biggest problems under control, let’s move down a level and pay attention to the yellow markers. In my case, the first problem reported in yellow was the issue of enabling the backports repositories in the package manager. Backports repositories are special repositories that contain newer software versions originally developed for newer versions of Linux distributions. They are used to provide users of older Linux distributions with access to newer software without the need to update the entire operating system to a newer version. Installing software from the backports repository can lead to instability or conflicts, so YunoHost suggests that we do not use them, and we will follow this advice and disable them from the package manager list.

First of all, let’s determine which repositories we are dealing with:

sudo grep -nr backport /etc/apt/sources.list* 

In response to this command, I received the following result:

/etc/apt/sources.list:10:# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
/etc/apt/sources.list:14:# bullseye-backports, previously on backports.debian.org
/etc/apt/sources.list:15:deb http://deb.debian.org/debian bullseye-backports main
/etc/apt/sources.list:16:deb-src http://deb.debian.org/debian bullseye-backports main

As we can see, the keyword backport, which we are looking for, appears four times in the file /etc/apt/sources.list in lines 10, 14, 15, and 16, of which the first two are commented out, so to speak, disabled, but without removing them from the list. We need to do the same with lines 15 and 16 of this file. So let’s go to the package manager repository list file and add the # symbol where needed:

sudo nano /etc/apt/sources.list

Save the file and exit it.

For security purposes, let’s scan the system again using a diagnostic tool. In my case, it looks like no more issues were found, so the system seems ready for further actions.

Base Backup

Basic configuration completed. At this stage, it’s a good practice to make a backup of a clean system, which can be easily restored if needed. I always make such a backup, and in addition to periodic backups, I also make extra copies before launching each new service (application).

Backups are performed in the (Main control panel) -> Backup -> Local archives (local) -> green button on the right +New backup. The backup can be downloaded from the graphical web interface or from the terminal, e.g., through some automation. The backups are stored on the server under the path – /home/yunohost.backup/archives/<backup_creation_date>.tar.

What’s next?

I will talk about what can be done next using YunoHost on another occasion. The purpose of this post was only to show how to install YunoHost and I think it is a good basis for future posts, in which I will describe in more detail how to run various services in such a configured environment. The list of applications (services) that can be run using YunoHost is available here and it must be admitted that it is extensive. Some of the more interesting options include:

• code-server – self-hosted version of Visual Studio Code editor,
• Discourse – discussion forum,
• Domoticz – smart home system,
• FreshRSS – RSS aggregator,
• Gitea – source code management,
• Grafana – analytical tool,
• Home Assistant – smart home system,
• n8n – automation tool,
• Mastodon – social network,
• Nextcloud – file sharing and collaboration platform,
• Nitter – alternative front-end for Twitter,
• PeerTube – self-hosted version of YouTube,
• phpMyAdmin – MySQL database management,
• Pi-hole – DNS server,
• Pixelfed – self-hosted version of Instagram,
• Roundcube – email client,
• Transmission – torrent (P2P) client,
• Vaultwarden – self-hosted version of Bitwarden password manager,
• Wallabag – read-it-later content aggregator,
• WireGuard – VPN server,
• WordPress – blogging platform,
• WriteFreely – blogging platform like WordPress but in the Fediverse.

And these are just a few quick selections because there is a lot more and I probably missed a few truly interesting and/or unknown (to me) services. There are also a lot of interesting positions on the waitlist for implementation.