Hosting a remote git repository on Ubuntu Server

Motivation

This website is represented by a GitHub repository. That is, any changes made to it is pushed to a remote repository hosted on GitHub. The website runs on a PHP back-end, thus cannot be processed by the GitHub pages' static site generator. One may notice that the repository does have GitHub pages enabled. Here, the index page is processed and redirects to my primary domain. This is done by the following html statement within the document's head:

My personal website is hosted through Digital Ocean cloud services. I also use a Raspberry Pi 4 as a load balancer for certain sub-directories within. The Raspberry Pi powers a Nextcloud instance where the Digital Ocean Ubuntu server templates out my static website. This templating allows for the practice of using DRY code fragments making any bulk changes a trivial matter.

Taking this approach also affords the flexibility of implementing an arbitrary amount of front-end features and layouts. This is contrary to a typical static site generator which can be constraining in terms of the HTML being generated from some source.

The notes sub-directory is a new branch within this website. It operates on a custom static generator extended from phpLeague's CommonMark library. What this implies is that the posts contained within the notes section are markdown files that are converted to HTML.*

Contrary to the notes sub-directory, pages contained in the projects and writings sections of this website aren't created from markdown. They are built by leveraging a header and footer generation script where the primary body of a given page is built by hand. Once again, this allows flexibility in layout should I want.

An observer will not find the notes section, or any related markdown files, contained within the GitHub repository. The code generation scripts have also been decoupled from this repository. This was decided for two reasons:

First, markdown is a basic syntax which really doesn't necessitate a need to catalog any changes of said syntax. That is, the markdown files are defined by their semantic content and not the behavior that is exhibited upon executing the files, (perhaps through some interpreter, for example). The repository does not need to be cluttered by these files.

Secondly, new content is becoming a valuable commodity for AI agents to train on. A lot has changed since I started publishing on this website. During that time, I've learned that the code I've been pushing to GitHub has been used to train these agents. I would like to minimize this affect by at least making Microsoft go through another hoop to access this data. If they want this content they'll have to crawl my website.

It is still nice to have a repository that tracks any changes made to these markdown files. So I've instead opted to leverage my Raspberry Pi and self-host the repository.

Moving data and tracking changes; Setting up the repository

Prior to this implementation, my workflow for making changes to the website have been by running a virtual machine that hosts Ubuntu Server. This virtual machine would pull from and push to the GitHub repository where the live version of the website would pull from the GitHub repository as well.

Instead of using scp to securely copy any extraneous files, (those that don't warrant taking up space on the GitHub repo - such as the images located within the photography sub-directory), between these environments I would instead leverage Dolphin by using the sftp protocol.

A naive approach would be to simply use Dolphin in the same manner to move markdown files between these environments. This can get messy as it ignores the advantages of version control software. There's a good reason why git is used in modern software development. The reason for this includes a discussion which involves solving the problem of knowing which code-base is the most up-to-date.

Both scp and sftp are ssh file transfer utilities; they leverage the SSH File Transfer Protocol. Git also allows the usage this transfer protocol. This is what we will be using here.

A repository needs to be set up on the Raspberry Pi server. Navigate to an arbitrary directory where the repository should reside and then initialize the repo:

Once the repository is initialized, an ssh key needs to be generated. The server needs to know a valid public key in which a client that is seeking to use the server has a private key to unlock access through said public key. This can be generated on the server, where the generated private key needs to be transferred to a client. This can also be generated on the client machine, where the public key needs to be transferred to the server. It makes the most sense to generate the key pair on the client machine. This can be done by running the following command:

This will generate two files, a private key labeled <output-name> and a public key labeled <output-name>.pub. Transfer the generated .public key to the server hosting the repository.

Once the public key is transferred, add it to the authorized_keys file located in the primary user's .ssh folder within their home folder:

Once this is in place, the client machine can then add the private key to their ssh-agent:

Where the client user will need to enter the passphrase given whilst generating the initial pair.

Once this is done, the client can now interact with the remote repository**:

Which will clone the repository where one should be able to view the previously committed readme file!

* - The process of altering phpLeague's commonmark code generation will be explored in a later post.

** - Be sure the server has access to port 22 through its router should a connection should be made outside of its network.