 |
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.
Recently I turned an old Windows 8 machine, not suited for a Windows upgrade, into a 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!
