Forem: Benjamin Godfrey

Homelab Refresh 002 - The terminal environment

Benjamin Godfrey — Sat, 23 May 2026 17:01:06 +0000

Homelab Refresh 002 - The terminal environment

Benjamin Godfrey

The problem

Something I like to keep in mind when thinking about machines on my network is their sovereignty. These are machines in their own right, but are part of a bigger picture - a user should be able to move from one to the other without too much resistance. To aid this easy moving from one machine to another, we would like to be able to interact with the machines in a similar way. We want them to look similar, feel similar, and work similarly.

While this config task takes us away from 'homelabbing' for a moment, I think it is worth doing before we get into the meat of what we are taking on. My machines all run Linux, so I ought to know Linux. In the words of the prophet, proper planning prevents piss poor performance.

In practice, this will look like creating templates for .bashrc, setting some aliases, and perhaps including some more config for specific tools like vim. I think a nice neat way of doing this would be with bash scripts. If I can create some bash script called setupEnv or similar, I can just copy this across to each machine (or better yet, clone it), run it once, and be happy.

The script

The structure of this script will be easy enough. Something along these lines:

#!/bin/bash

# declaring some variables
# putting those variables somewhere

So our first step is deciding on our variables.

The prompt

The prompt is something which I have put some thought into before. I like to be able to see who I am and what machine I am on, I like to have a bit of a gap between things, and I like to type onto a new line. As such, I am happy for my prompt to be defined as follows:

USER_COLOR='\[\e[38;2;32;186;251m\]' #20bafb aqua
OTHER_COLOR='\[\e[38;2;139;233;253m\]' #8be9fd light blue
RESET='\[\e[0m\]'
PS1="\n  ${OTHER_COLOR}╭──${USER_COLOR}\u${OTHER_COLOR}@\h - \w\n  ${OTHER_COLOR}╰─> ${RESET}"

I will be lazy here and simply append this to my .bashrc, knowing that it would be applied after all other settings. The second most lazy thing to do would be use some sort of grepping like:

grep -Ev "^PS1" .bashrc

To find lines I do not want and remove them. Who can be bothered.

The aliases

I have a few aliases which I like to use across the board. These are the basic commands which I find easier to use than the defaults. These are:

alias cls="clear"
alias py="python"
alias la="ls -la"
alias lah="ls -lah"
function mkcd() {
        mkdir $1 && cd $1;
}

Putting these together

We can put these settings together in a single executable as follows:

#!/bin/bash

CUSTOM_FILE="$HOME/.custombashrc"

cat > "$CUSTOM_FILE" <<'EOF'
USER_COLOR='\[\e[38;2;32;186;251m\]'
OTHER_COLOR='\[\e[38;2;139;233;253m\]'
RESET='\[\e[0m\]'
PS1="\n  ${OTHER_COLOR}╭──${USER_COLOR}\u${OTHER_COLOR}@\h - \w\n  ${OTHER_COLOR}╰─> ${RESET}"

alias cls="clear"
alias py="python"
alias la="ls -la"
alias lah="ls -lah"

mkcd() {
    mkdir -p "$1" && cd "$1"
}
EOF

if ! grep -q 'source ~/.custombashrc' "$HOME/.bashrc"; then
    echo '' >> "$HOME/.bashrc"
    echo '# custom config' >> "$HOME/.bashrc"
    echo 'source ~/.custombashrc' >> "$HOME/.bashrc"
fi

Homelab Refresh 001 - Where are we?

Benjamin Godfrey — Sat, 23 May 2026 10:59:40 +0000

Homelab Refresh 001 - Where are we?

Benjamin Godfrey

The problem

My homelab, in its current form, is a mess. That is not a surprise, as it has evolved over time; grew, adapted, changed, if you will. New machines have been added, new services have popped up, services have become duplicated. As well as this, and perhaps more seriously, since I jumped into my homelabbing experience early doors, it is probably fair to say that the foundations were not as solid as they should have been.

All of this is to say, I fancy a refresh. I am at a point just now where I could tear it down, start again, and spend less than a day getting things back into line. To me, that is worth it. This will give me the opportunity to start again, apply best practice, and document. Here we go.

The goal

Simplify infrastructure
Simplify deployment of services
Improve security practice
Improve documentation

The resources

Machine name	Machine type	CPU	Memory	Storage	OS
`zorn`	2010s SFF desktop	Intel Core i5-4570	16gb	1tb+	Ubuntu Server
`lebesgue`	Raspberry Pi 1 B+	Broadcom BCM2835	~0.5gb	32gb	Raspberry Pi OS lite
`romulus`	Raspberry Pi 2 B	Broadcom BCM2836	~1gb	64gb	Raspberry Pi OS lite
`remus`	Raspberry Pi 2 B	Broadcom BCM2836	~1gb	64gb	Raspberry Pi OS lite

There is a clear difference in power between my machines, with zorn being much more powerful than each of the Pis. As such, I will use zorn as the main source of compute, handing smaller tasks off to the other machines. I will use either romulus or remus as the host of my wireguard vpn, as these are a nice middle ground of power.

We can also see that there is a difference in storage available to each machine. As such, I will plan to keep the services on romulus, remus, and lebesgue fairly stateless. This is a general rule, which will probably be broken in future.

The network

These machines are all on the same LAN, connected by ethernet through an unmanaged switch. This is fine, and provides a baseline for communication. In addition to this, I will require a VPN to enable connection to machines and services from other devices. To facilitate this, I will use piVPN with wireguard, as it is a tool which I know.

In the interest of security, I will impose some network rules. Specifically, I will have a single ssh entry point via wireguard, on zorn. All other ssh traffic will go through LAN. Similarly, I will allow network requests to zorn only to a single port, and use an nginx reverse proxy to route traffic.

Risks

Risk	Notes
Single point of failure introduced with ssh over wireguard	As this is a homelab, only my own access to machines and services is important. Since all machines are on my LAN (and in my house) I will be able to access these, even in failure

Homemade CI/CD Pipeline - Part 1: Git

Benjamin Godfrey — Thu, 12 Feb 2026 16:27:09 +0000

Week 1: Demystifying the Remote

This past week marked the official start of my DIY CI/CD pipeline project. My first goal was to come up with a way to manage git repos.

I wanted to host my code without relying on GitHub or GitLab. When I clone a repo at work, the address usually looks something like this:

git clone git@github.com:path/to.git

Looking at that through the lens of a Linux terminal, it’s clearly just pointing to a path on a machine via SSH. I had a hunch that setting up my own remote server couldn't be as simple as just pointing to a folder on a spare machine.

It turns out, it really is that easy.

The "Aha!" Moment

Realising that Git is essentially just a series of file transfers over SSH was a massive confidence boost. It’s easy to look at a project like "building a CI/CD pipeline" and feel overwhelmed by the scale, but this early win reminded me that I already understand the core technologies at play. I’m just putting them together in a new way.

To manage this, I’ve put together a few Bash scripts to handle my Git settings and repository initialisation.

You can find the current scripts in the src/scripts directory of my project repo here: CI-CD-BG on GitHub.

The Road Ahead: From SSH to HTTP?

Now that the "Store" part of the pipeline is working, I’m venturing into the unknown.

Currently, I have to manually SSH into the server to run my management scripts. For the next phase, I’m considering setting up a lightweight HTTP server. The goal is to be able to trigger my build and test scripts via webhooks or simple HTTP requests rather than maintaining a manual SSH session.

This moves the project from "running scripts on a box" to "building a service," and I’m excited (and slightly terrified) to see how it holds up.

Homemade CI/CD Pipeline - Part 1: Git

Benjamin Godfrey — Thu, 12 Feb 2026 16:27:09 +0000

Week 1: Demystifying the Remote

This past week marked the official start of my DIY CI/CD pipeline project. My first goal was to come up with a way to manage git repos.

I wanted to host my code without relying on GitHub or GitLab. When I clone a repo at work, the address usually looks something like this:

git clone git@github.com:path/to.git

It turns out, it really is that easy.

The "Aha!" Moment

To manage this, I’ve put together a few Bash scripts to handle my Git settings and repository initialisation.

You can find the current scripts in the src/scripts directory of my project repo here: CI-CD-BG on GitHub.

The Road Ahead: From SSH to HTTP?

Now that the "Store" part of the pipeline is working, I’m venturing into the unknown.

This moves the project from "running scripts on a box" to "building a service," and I’m excited (and slightly terrified) to see how it holds up.

Overengineering: A Series

Benjamin Godfrey — Sat, 31 Jan 2026 20:55:32 +0000

I want to make a CI/CD pipeline. Going in to this project I understand that whatever solution I could make would not be nearly as usable, reliable, or feature rich as existing options. Despite this, I want to give it a go.

There are a few reasons for this. Firstly, from my (possibly incorrect) viewpoint as a junior dev, I think that what is most important for me is to understand the fundamentals and the tools that I use. I know how to go through the process of commiting, pushing, making a PR and merging, but given a blank terminal I would struggle to remake that process. Add to this the exposure to networking, scripting, and automated tests, and I think the picture becomes very clear.

Secondly, I think that self hosting where possible is a good thing. Sure, my GitHub profile probably won't be deleted and take with it all of my previous projects, but you never know. If I can host my repos on some device that I own then I won't need to rely on any third party, and I won't need to send packets halfway around the world to access my own projects.

Thirdly, I think it would make an interesting series of blog posts. My plan is to take on this project in weekly sprints, and to review progress at the end of each of these sprints. With this in mind, we could call this first post my sprint planning.

The first step of any project: figure out what I actually want to achieve. When I say that I want a CI/CD pipeline, what do I mean? Well,

I need a place for my repos to live. GitHub and Gitlab exist, but as stated, I would prefer to keep this on my own network. Functionality here can be minimal, especially at the start. A directory on a machine somewhere on my LAN will do.
I want some series of events to happen when I push to main.
A build should be created. This will most likely be in a docker container, or at least it will be to start with.
After a build is created, it should be tested. This should be everything from unit tests to end to end automated testing. Maybe even some SecOps stuff, just to spice it up.
If anything fails (in the build or test stages), the whole pipeline should rollback. This probably means I need to keep builds somewhere in storage.
If everything is ok, we are sorted. Deploy the build to some container.

Even in writing this list I have found a few areas that will require research. I guess this is kind of the point. I will spend the next week filling in any gaps in knowledge that would block initial progress, and also trying to figure out how much time I can actually afford to put into this project.

Thus far, no blockers.