Building a LAMP and git server

Frequent visitors of my blog will have noticed that I like to repurpose old computers and fix electronics. It is a small contribution to controlling the waste problem - stuff is not obsolete while it is not beyond repair.

I turned an old Windows 8 machine, not suited for a Windows upgrade, into a LAMP and git server that I called WALL-E. On a home network it serves files through Samba and printers through CUPS and Gutenprint, extending the life of perfectly good printers for which no Windows 11 drivers will be made available, and that would otherwise have ended on the scrap heap.

WALL-E is also a git server and a LAMP server, hosting a few legacy websites that should remain available locally for reference purposes. Some of those websites are Wordpress sites, and those need a database. However, WALL-E's /var partition where websites and databases sit, is a bit small whereas I have plenty of space on /home. The solution to migrate websites and databases to /home appears obvious enough. Here I want to describe a few issues that actually required RTFM (Reading The Formal Manual).

Moving web pages

I produced a directory /home/www/ to host the web pages. Apache however does not accept that out of the box and will produce "Forbidden 403" notifications. We must give directory /home/www/ a same status as /var/www/. Do not manage that in the top Apache configuration file as it may be silently superseded at the next update. Instead, I inserted in every virtual server configuration file a directive like that for /var/www/.

# systemctl stop apache2
# vi /etc/apache2/sites-available/example.lan.conf
<VirtualHost *:80>
        ...
        ServerName example.lan
        DocumentRoot /home/www/example.lan/htdocs
        <Directory /home/www/>
                Options Indexes FollowSymLinks
                AllowOverride None
                Require all granted
        </Directory>
        ...
</VirtualHost>
# systemctl start apache2
# systemctl status apache2

Moving databases

Debian sports MariaDB, which is a good drop-in substitute for MySQL. These notes pertain to Debian 12 with stock MariaDB installed from the Debian repository. Other systems may require a different approach. Please read these notes entirely, before meddling with your system. You best do this after installing MariaDB and before creating databases. Otherwise, moving databases is not without risk so please do make sure you have an up-to-date copy of your databases before you touch anything.

First we stop MariaDB. Then we create a directory on /home and make sure that user mysql owns it. When that is done, we migrate the data.

# systemctl stop mariadb
# mkdir /home/databases
# chown mysql:mysql /home/databases
# cp -rpv /var/lib/mysql/* /home/databases

Now we must change the MariaDB default directory. The top configuration file may be replaced at the next MariaDB update, and we would experience weird problems. Hence I inserted the new default in the local configuration files, in the [mysqld] block. This is the Debian way, please check the documentation for your particular system.

# vi /etc/mysql/mariadb.conf.d/50-server.cnf
[mysqld]
...
datadir=/home/databases

Here most tutorials suggest you restart MariaDB and continue with your daily chores. However, restarting MariaDB resulted in failure.

# systemctl start mariadb
[Warning] Can't create test file /home/databases/XXXX.lower-test
[ERROR] Aborting
systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: mariadb.service: Failed with result 'exit-code'.
systemd[1]: Failed to start MariaDB 10.11.6 database server.

At first I suspected a straightforward permission issue, but that appeared not to be the case. I found out that for security reasons, without written consent MariaDB refuses certain file systems, including /home. We consent in writing by dropping a short file at the right spot in /etc/systemd/system. This way, our consent is not overwritten at the next update of MariaDB. Again, this is the Debian way. Your distribution may require another approach.

# mkdir /etc/systemd/system/mariadb.service.d
# vi /etc/systemd/system/mariadb.service.d/wall-e.conf
[Service]
ProtectHome=false

Now we restart daemons and MariaDB, which should be uneventful now.

# systemctl daemon-reload
# systemctl start mariadb

You should test that the new configuration indeed works. As a minimum, check that MariaDB runs, and request the data directory.

# systemctl status mariadb
● mariadb.service - MariaDB 10.11.6 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/mariadb.service.d
             └─wall-e.conf
     Active: active (running) since ...
...
# mariadb -u root -e "select @@datadir;"
+------------------+
| @@datadir        |
+------------------+
| /home/databases/ |
+------------------+
#

Git server

WALL-E is a git server. For this there are also many tutorials on the web, but I present here mine that is a bit simpler than most. We log in as root and install git.

# apt update
# apt upgrade
# apt install git

Next we create a new user, git. You will be prompted for information on the new user. Give git a sensible password, you will need it on the client side.

# /sbin/adduser git

At this point, tutorials tend to instruct a tedious set up of ssh access for many users. In my tutorial, we skip this, and simply set that up from the client side later since I am the only user of the git server.

Now we make a first git repository. Just as an illustration, I will make a repository for Algol 68 Genie.

# su git
$ git init --bare ~/algol68g.git

And that is pretty much all. Now we move to the machine where the project is actually being worked on. There we install git as well.

# apt update
# apt upgrade
# apt install git

We're done as superuser now. Log in as the user that develops the project. First we set up ssh authorization, so we can easily access the git server. Note that you may have followed the ssh-keygen procedure in an earlier stage, for instance when setting up a computer cluster. In that case, do not issue ssh-keygen again, and immediately copy the key to the server.

$ ssh-keygen -t rsa
$ ssh-copy-id git@c3po

Now we enter the directory where the source code sits. In our case, it will be the directory algol68g.

$ cd algol68g

Now we make it ready to be synced with the git server c3po. Mind the dot at the end of the init command, it indicates the present working directory.

$ git init .
$ git remote add origin git@c3po:algol68g.git

Before we can synchronize with the git server, git wants you to properly introduce yourself.

$ git config --global user.name "..."
$ git config --global user.email "..."

Now, you could open the project with VS Code. However, in a project as large as Algol 68 Genie, VS Code may complain it sees too many changes for the initial commit. Therefore, we do the initial commit and push by hand. Again, mind the dot in the add command, that is not optional.

$ git add .
$ git commit -m "Initial commit"
$ git push -u origin master

And that is it. You now have your own local git server at your disposal!

Published in Tech Tips

More on Debian, Server

Deze website is gearchiveerd door de KB, nationale bibliotheek.

This website is archived by the National Library of the Netherlands.

Building a LAMP and git server

Marcel van der Veer

March 2024