David's Webpage

Getting Rusty

Thu, 30 Nov 2023 22:24:38 -0500

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Introduction

This article tells the story of how I found Rust, the true “first programming language” that I chose to learn. As I made progress reading through “The Book”, I created a Git project called fibonacci, a CLI program that calculates the “nth” position of the Fibonacci sequence. I also created a Git repository called Rust collection, which contains a bunch of scratch projects I worked on during this time. Both projects can be found on my GitHub, and are directly accessible by following the links.

Time to Get Rusty

By the end of 2023 October, I was still in the process of choosing the “first programming language” that I would dedicate a solid amount of time to learn. After trying out Python and TypeScript for a time, and not really feeling like either was right for me, I went back to my Bash projects, working to improve my debian-dwm installer. But, even as I made more progress with Bash, I still felt that it would be good to start learning “a real programming language”. As I mentioned in a previous article, I “wanted a language that would punish my lack of understanding, and would force me to better appreciate what I was trying to tell the computer to do”. Put another way, I wanted a language that would make me use all the knowledge I had gained from thePrimeagen’s Data Structures and Algorithms course. I forget exactly how I stumbled upon it; but, by the end of 2023 October, I finally found a language that would give me all of that: Rust.

One of the benefits of learning Rust at any stage of a programmer’s journey is that there are a TON of resources available. There’s “The Book”, which is an online collection of documentation put out by the Rust Foundation, explaining exactly how to get started. There’s “Rust by Example”, which was also created by the Rust Foundation, and is almost a different version of “The Book” that requires less reading, and has more examples. There’s also “Rustlings”, which is a compilation of practice examples, essentially in the form of a game. Despite knowing no Rust at the time, I decided to start with “Rustlings”.

Rustlings

I started to learn Rust by working through Rustlings. Because of my lack of Rust knowledge, and lack of coding experience in general, I decided to do Rustlings in a (likely) unorthodox way – I had a YouTube video walkthrough playing at the same time. I attempted every problem by myself at first; but, I quickly allowed myself to view “the answer”. In retrospect, I think this was the perfect way (at least, for me) to get introduced to the language. It provided a very fun way to get started, and it allowed me to get a wide view of how Rust worked and what it had to offer, without getting too bogged down in understanding what I was doing. This allowed me to confirm my major suspicion: yes, this was going to be a language where having a solid foundation of data structures would be extremely useful.

While my first go-around with Rustlings came with a large amount of hand-holding, it was my intention that it would serve only as an introduction, and nothing more. Once I got that introduction, my plan was to read through “The Book” in its entirety, and get a much deeper understanding of Structs and Enum and all the rest. After I completed “The Book”, I would return to Rustlings, and I would do it again from scratch. But, that next time, there would be no hand-holding. If I needed help, the solutions would be found in “The Book”. I would have to read documentation, and read my own code, to figure out what was wrong.

With my first completion of Rustlings under my belt, it was time to start reading “The Book”. However, I did take a short break from Rust to work on my debian-dwm project. While what I learned from Rust wasn’t directly applicable, I now had a far better understanding of functions, and how to write them. This was directly relatable, and I used that understanding to perform a major refactoring of the debian-dwm project.

The Book, and `fibonacci`

After completing the debian-dwm refactor, I was more enthusiastic than ever about learning Rust and becoming a better programmer. So, I started at the beginning of “The Book”, and began to work through the chapters.

I was only a few sections before I was presented with a stopping point, where I was told that I knew “enough to make a small program”. One of the suggestions for a project was to write a program that calculated the Fibonacci sequence. I immediately got excited by the prospect, as I began to think about all the different ways I could tackle writing the code. Specifically, I was pumped to write the algorithm that would calculate the Fibonacci. I was already envisioning a number line that would be looped over. The loop would take two numbers (call them “l” and “r”, for left and right), add them together, and then “step up” to the next set of numbers. The loop would continue this process until it reached the given index, and then spit out the sum. I took a crack at it, and after a bit, I had a piece of code that worked!

The fibonacci project was great for so many reasons. One of the primary reasons was that it gave me something to continually return to as I made more progress in “The Book”. When I learned how to write a “for loop”, I swapped it in for the “while loop” I had been using. When I learned how to write module files, I moved the code from “main.rs” to a “fibonacci.rs” file. Then, when I learned about library files, I moved the code over to a “lib.rs” file. The process continued:

I learned how to write tests, so I added some to the “lib.rs” file.
I was taught how to accept command line arguments as inputs, so I updated my program to accept arguments.
As I learned how to write better code, I began to abstract out functions to create simpler functions.

One thing that’s worth shouting out is the following: I noticed that there were insufficient logic regarding ordinal numbers (“1st”, “2nd”, “3rd”, etc). Specifically, “1st, 2nd, 3rd” worked correctly, and everything else received “th”. Unfortunately, this didn’t cover “21st, 22nd, 23rd, 31st, 32nd, 33rd, etc”. I thought the simple solution was to have the program read the last digit and output based on that. But, that logic would fail at “111th, 112th, 113th”. In addition, I found out that grabbing the last numeral in my integer was more complicated than originally assumed. So, I thought about it, and brought together everything I learned in order to come up with a solution. And then it came to me – I can use modulo (specifically, mod 10), and that would return the last digit! I used the modulo operation, in combination with some clever logical operators, to write a solution that would encompass all cases.

I’m not sure that it was “The Book”’s intention that I keep returning to an introductory project and keep refining it. However, the fibonacci project began a home for my development, and one of the best indications of my progression in learning the fundamentals of Rust. While it’s honestly nothing special, it serves as a demonstration of the improvements in my understanding as I worked through all of the chapters, almost more so than the other practice problems I worked on in the other chapters.

Conclusions

I’m honestly not sure that I ever finished “The Book”. I worked through it until the end of 2023 November, when I became distracted by Advent of Code, which I saw as another opportunity to take what I had learned and practice more Rust. Soon after, I started a new job as a System Administrator in the middle of 2023 December, and that took my focus away from learning to code. But, I came back to Rust on occasion throughout 2024 – the “modulo” story only happened at the end of 2024 May. Despite my attention being split between more projects than ever before, I was happy that I began to deep dive Rust for the time that I did. As compared to my experience with Python and TypeScript, it felt like the right language for me to start with. It gave me everything that I was looking for:

I wrote command line programs that I could easily run on a Linux computer.
I made use of a good amount of the data strucutres and algorithms that I had learned with thePrimeagen in 2023 August.
It was a fair level of “difficult”, in that I felt rewarded for taking breaks to “learn how things worked underneath the hood”.

In conclusion, after many months of working to find a coding language that I would be happy to learn and make progress in, I found that reality in Rust.

Getting Better at Bash

Fri, 17 Nov 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Introduction

This article tells the story of my progress at learning how to work better in Bash. As I grew and learned, I created a Git repository called Bash collection, which contains a bunch of scratch projects I’ve worked on – this project can be found on my GitHub, and is directly accessible by following the link.

My First Refactor

Starting at the beginning of 2023 August, I had spent a good amount of time learning the basics of how to code. In August, I took a data structures and algorithms (DSA) course, finished the first pass of the debian-dwm project, and wrote my own Neovim configuration files in Lua. In September, I began playing around with Python and Typescript, and made more progress on debian-dwm and my Neovim configs. I had even dipped my toes into Rust by working through Rustlings. But, it was now 2023 November, and I was looking to do something concrete that would cement the learning I did over the past few months.

After reviewing the current state of my debian-dwm project through the lens of what I had learned, I saw some glaring problems with it. While I had implemented some basic “for loops” and variables in early 2023 September, which made the code a lot cleaner, I was having issues with variable expansion within some of my commands. While there were other ways to fix my mistakes, such as exporting variables so they would be accessible throughout the code, I realized that using functions would be another way to resolve the matter. As an aside, this was something that Luke Smith had done with his LARBS project; but, I was too novice at the time to implement functions correctly. Now, with what I had learned, I felt confident that I could make those improvements to my project.

Most of the major changes that I made during this refactor were to make the scripts easier to read. Examples of these changes include:

I had some commands that were unnecessarily long, and would perform some of the same actions as other commands.
- In these cases, I decided to write functions that could be called by other commands.
- The added benefit of doing this was, when a change needed to be made, I only had to make the edit once, and it would be reflected in every invocation of that function.
- This also made it much easier to write conditional statements that, if true, were able to do more complex functions, without impacting readability.
I added sections to my scripts.
- Specifically:
  - The first section would be the script-wide variables that I was setting.
  - The second section contained all the functions that I wrote.
  - The third section was the “actual script”, which included all of the functions that were actually being invoked.
- This made it really easy to read the script, especially in Vim.
  - I could easily jump to the bottom and read exactly what was being run and when.
  - If I had a question about a function’s definition, I could use the keymap gd to jump directly to the function and see what it was doing.
I wrote some functions to take in files as arguments.
- This allowed me to break off the package list from the script that installed packages, and create a separate “package-list” file that was far easier to read and edit.

The product of this refactoring process was a set of scripts that were far easier to read and debug. While the project was far from perfect, I was able to massively improve the code I wrote only a few short months ago, and make it that much better, all because of the different things I had learned in the preceeding weeks. Content with the changes I had made, I committed the changes on 2023 November 12 and started reading through “The Book”, a set of documentation that would teach me the foundations of writing code in Rust. But, that commit had a problem that I wouldn’t notice until days later.

Indirect Variable Assignment

A couple of days into beginning to read through “The Book”, I needed to set up a new virtual machine (VM) with debian-dwm. So, I cloned the git repo I had been working on and ran the installer. However, I was met with a funny error: the echo commands that I would use to tell the end user that a package needed to be installed before continuing, were instead printing nothing in place of the $pkg variable. When I went to debug the scripts, I came across the problem: the variables weren’t being expanded correctly. As I looked more into the issue, I found out that it had a name: “indirect variable assignment”.

As I understand it, the problem had to do with my use of single quotes " ’ " versus double quotes " " “. While I know more than I did at the time, and I could have used double quotes had I escaped them correctly (using " \ “), I instead went a different route. I solved the issue by abstracting out the echo command into a new installcomment function, which could correctly expand the variable, despite using single quotes. While I learned more since this incident, and I realize that a simple read of the bash man page would have averted this issue entirely, it was a great experience for me. It gave me an opportunity, and a reason, to troubleshoot a more complex issue in some code that I had written, and to figure out my own way of resolving the problem. In addition, it was an indirect way for me to learn to abstract out more of m repeating code into simpler functions that could be invoked by other commands, rather than having repeating commands that do the same thing. In either case, it was one more experience added to my journey that helped me to learn better the tools with which I was working.

Conclusion

While I was working during 2023 November both on improving my Bash skills and learning Rust, I can safely say as of writing (2024 August) that I’ve used more Bash than I have Rust. That’s simply a function of all the projects that I’ve worked on since this time, and there being more utility for Bash than there was for Rust, especially at my level of expertise with both. Even though I’ve made even more progress in Bash since this time period, this article highlights an important part of my journey and development. A few years ago, I couldn’t even read a Bash script. Only a few months before, I was writing scripts that were essentially just a long list of commands, one after the other. But, by 2023 November, I was starting to get a good enough handle on Bash that I could write more complex scripts. These lessons would become foundational for all the progress I would make in the months to come.

Python and TypeScript: Learning How to Code

Fri, 08 Sep 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Introduction

This article tells the story of how I started working with Python and TypeScript. As I made progress in both languages, I created Git repositories called Python collection and TypeScript collection, which contains a bunch of scratch projects I worked on during this time – these projects can be found on my GitHub, and are directly accessible by following the links.

My First “Real Coding Language”

I was feeling pretty good about my progress from the past month. I had completed thePrimeagen’s data structures and algorithms (DSA) course a few weeks prior, finished the first pass of the debian-dwm project, and written my own Neovim configuration files in Lua. I was also getting used to the new Kinesis keyboard, and had starting learning how to use Git better. However, I was weeks out from the DSA course, and I hadn’t made much use of it. While I gained a ton of insights into programming, I was being self-critical: “Bash isn’t a real language”, and “Lua is a real coding language, but all you did was set a bunch of options”. I felt it was time to start learning a “real coding language.”

Since I had the Frontend Masters subscription for another few weeks, I wanted to get as much value out of it as I could. So, I thought about what language I wanted to start with. I considered TypeScript/JavaScript heavily, as the DSA course was done in TypeScript. But, I wasn’t sure if TypeScript would be the most accessible first language. I considered some other languages, and then made my decision: Python.

I made the decision to start with Python for a few reasons. The primary reason was that I thought Python might be more “noob-friendly”, and would be a better starting point than any other language, because of its accessibility. While this was the case, it incidentally also became the reason that I moved away from Python - I felt that the DSA course wasn’t necessary to use Python. To be more clear, Python is a great language, and has a bunch of use cases, such as data analysis and machine learning. However, none of those use cases were directly applicable to me. In addition, because of Python’s “noob-friendly” syntax, I had concerns that I wouldn’t be able to build the same foundation of understanding that I would from using other languages. I didn’t necessarily need to understand how things worked “under the hood” in order to do some basic projects, and that bothered me. As I would find out from using Python, I wanted a language that would punish my lack of understanding, and would force me to better appreciate what I was trying to tell the computer to do.

Getting a Handle on Python

During this time, I completed a handful of projects using Python. I worked on a simple “gambling game” by watching a video by the YouTuber “Tech with Tim” and gained some experience writing simple functions. I completed a crash course on Python from Frontend Masters, in which I learned some tips about how to work with Python virtual environments on Linux. I even took a swing at some Leetcode problems, where I got to work with data structures such as hashsets, and maps/dictionaries. In addition, I got to apply some of what I learned from the DSA course and think about clever ways to implement algorithms to solve problems. By working on these projects, I was excited to continue learning to code; however, I didn’t really see how Python was going to assist me with the types of things I was already doing.

So, after about a month of playing around with Python, I started to move away from it. Throughout 2023 September and October, I also tried out some Leetcode problems in TypeScript as well, just to see if that was a better fit for my first language. But, neither Python nor TypeScript gave me what I was looking for. While I had benefitted from the time spent working with Python and TypeScript, and I had gained a better understanding of how to write code, I couldn’t see how either language would help me with the other stuff I was doing. In contrast, I felt that getting better at Bash would be more useful to me, and the projects I was working on. Therefore, I kept working on my Neovim configuration, and continued to improve my debian-dwm project.

However, later in 2023, I eventually discovered the language that would be my true “first coding language”: Rust.

Neovim: Now in Lua!

Sun, 27 Aug 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Introduction

This article tells the story of how I wrote my own Neovim configuration from scratch – this project can be accessed by following the link to my GitHub.

“You Can Go Your Own Way”

While I was working on my debian-dwm project (links: to article; to GitHub), I began to notice that my Neovim experience wasn’t exactly where I wanted it to be. I had been using Luke Smith’s Vim config file for about a year now, and it was an excellent way to get started with Neovim. However, I was beginning to use Neovim for everything I did on my machine, and I was starting to realize that there were more features that I wanted. After watching enough of thePrimeagen’s content, I knew that I wanted some additional plugins that would take my experience to the next level. Fortunately, I had recently come across a video of his, where he starts with the bare-bones Neovim experience and builds it from scratch to suit his needs. And, I thought, “hey, why not do it with him?” In the worst case scenario, I could always revert back to using Luke’s Vim config file.

So, I sat down one day in late August 2023, and wrote my own Neovim configs alongside Prime. The first thing that I had to get used to was Lua. While Luke Smith’s Vim config was written in Vimscript, so it would be backwards compatible with the original Vim, Prime was writing configs for Neovim alone, and so he opted to use Lua in order to have greater control over the code he wrote. By doing this, I learned a ton about how my favorite text editor functioned. I learned:

How to work in Netrw, Neovim’s default file explorer, allowing me to create files and directories without having to exit Neovim.
How to create profiles for Neovim, so I could have alternate versions of my setup.
- For example, I created two profiles that were identical, except that one would install the LSP plugin, and one that wouldn’t.
- Pairing this with debian-dwm, I would be able to choose whether or not to install an LSP with my Neovim, saving myself time on VMs that weren’t going to be used for coding.
How to create custom keymaps that worked well with my new Kinesis keyboard.
- One of my favorites is that I bound “save file” to a double-tap of the spacebar.
  - This has enabled me to save my work incredibly quickly.
  - As a byproduct, I now save my work after every change, without even realizing it.
How to install and operate a plugin manager.
- While I still use vim-plug, as I did when using Luke’s configs, I learned how it actually works, and that allowed me to more easily add and remove plugins.
- Also, I learned how to direct vim-plug to install a specific version of a plugin.
How to add new colorschemes to my Neovim configs.
- This didn’t really help my productivity, but it definitely improves the experience. When you’re looking at raw texts for hours at a time, you want it to look aesthetically pleasing!
How to set options in Lua, as opposed to Vimscript.
- While all my settings are beneficial, the following is a small list of options I figured out at this time:
  - Incremental search is useful for showing what exactly I’m searching for, and where it appears in the file.
  - Scroll offset (scrolloff) keeps me from editing files near the bottom or top of my file.
    - Unless I’m at the absolute first or last lines of a file, Neovim will enforce a buffer, so I can see the lines above or below what I’m working on.
  - Remapping and with “zz” – this allows me to keep my eyes on the center of the screen as I jump up and down the file.
    - I also have the same setting for using search, which means I barely have to scan to find the string I’m searching for, since it’s always near the center of the screen.

I was also introduced to some awesome new plugins!

An image of my Neovim configuration directory, in Neovim, using the Telescope plugin to view files.

Plugins

These tools have greatly improved my ability to use Neovim. Especially when working on code projects, I can’t work without them.

Telescope

One of my favorite additions to my Neovim is Telescope: a fuzzy finder. While Luke’s configs also had a fuzzy finder, Telescope enabled me to also have a file preview for any file that I was searching over. Because of Telescope, I massively increased my use of the fuzzy finder within Neovim – where I almost never used fzf, I constantly use Telescope. With Prime’s help, I also added some custom keymaps, including one that allows me to use grep through the entire working directory to search for a file, and then displays that output in Telescope. This has been a great help when working within a repository, as I can now quickly find files I’m working on.

Harpoon

As Prime accurately describes it, Harpoon is truly “a glorious way to navigate files”. Basically, what Harpoon allows the user to do is to use the same set of keymaps for switching between files. What does that mean? It means that I know that “Ctrl-J” is always my #1 file in a project, “Ctrl-K” is my #2 file, and “Ctrl-L” is my #3 file. Then, no matter what project I’m working on, I can use those same keymaps to always hit the most important files. I can readily change those files out; if another file needs to be moved in, or the positions need to change, I can do that with no effort required. In addition, the marks are set on a “per repo” basis. If I’m working on my debian-dwm project, those keymaps will access the marks for that project; if I switch over to the library repo, then I have access to the marks for that repo. So, I now have the muscle memory to very effortlessly flip through the most accessed files in any one of my repos/directories/projects. And, if I want to add something that’s not in my Harpoon just yet, I use Telescope to navigate to it, add it to Harpoon, and then set it as whichever mark I need it to be. Harpoon is incredibly useful.

LSP

The last thing I want to shout out in particular are Language Server Protocols (LSPs) in Neovim. While I wasn’t coding much besides Bash scripts at the time, setting up LSPs paid dividends in the future. Once I started coding in Rust, having rust-analyzer built into Neovim made life so easy, as I was able to have my code actively assessed by the Rust compiler while I was programming. I also got some auto-complete features and function descriptions built into my Neovim. It’s not something I needed up until this point, but now that I have them, I don’t know what I’d do without them.

I Use Vim, BTW

While I was using Vim a lot before this, creating my own custom configuration caused me to love Vim even more. I now use Vim for everything I can, whether it’s coding, writing documentation in Markdown, or even my daily to-do lists. The more I use it, the more I become comfortable with using Vim motions and navigating using Harpoon and Telescope. Since creating these config files, I have become a bit obsessed with using Vim for everything I can. I even have a version of my Neovim configs written in Vimscript; that way, when I’m working on servers, I can quickly deploy a more lean version of my setup using just Vim (as opposed to Neovim).

It’s kinda become a way of life. 🤣

Helpful Videos

Debian DWM: Like LARBS, But Not Exactly

Wed, 23 Aug 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Introduction

This article tells the story of how I created my first true Git project, debian-dwm – this project can be accessed by following the link to my GitHub. If you want to learn more about how I install Debian onto new computers and VMs prior to using debian-dwm, check out my guide on installing Debian!

My First Real Git Project

debian-dwm is a project I have been working on since late July 2023, though it really only took shape in late August 2023. I had been using LARBS on my Artix desktop for about 6 months, so much so that I was loathe to use any other desktop solution. While KDE is definitely my favorite desktop environment for Linux, I vastly prefer the flexibility of a window manager like DWM. However, LARBS is written for Arch-based distros, such as Artix Linux. There was no easy way to deploy a similar build of DWM onto a Debian machine. So, I decided to make it myself.

I didn’t directly copy Luke Smith’s LARBS for a handful of reasons. The primary one was that my Bash knowledge wasn’t where it needed to be – I had no idea what Luke was doing with portions of his script. For example, the way that he was using Bash to pass arguments into functions that he had written completely baffled me at the time. But, another reason was that there were some things that I wanted the script to do, that Luke’s script didn’t do. A great example of this was the ability for the script, were it to fail, to be able to pick up from some sort of “milestone marker”, rather than starting again from the beginning. I saw this as a great opportunity to push myself to learn more, to build something myself that would be heavily inspired by, but not a carbon copy of, someone else’s work.

“We All Start Somewhere”

The first iteration of debian-dwm was completed by early August. At that point, it was genuinely just a list of commands that would run in succession. There was honestly nothing special about my script, except for the fact that it would work on a Debian system. I actually used this first iteration to create the VM that I would use to complete the “Starting Points” section of HackTheBox. I even used a version of these scripts to get DWM working on NixOS because I refused to make use of home-manager. While the script wasn’t anything special, it did what it needed to do: it installed Luke Smith’s DWM onto a Debian system. However, I was already beginning to implement my own additions to the script. The primary example of this was creating a way to have those “milestone markers”: thus, my idea of “modules” was born.

Simply put, I had no idea how to have the installer be able to “pick up where it left off.” I hadn’t been introduced to Ansible at the time, so I was struggling to find a way to make my main script be able to know what part of the install it was on. So, I came up with my way of doing it.

I broke the script up into smaller modules. The key was that every module that was going to get forked into an external shell would be preceeded by a logical operator that checked to see if the module file existed. If it didn’t exist, it would simply move onto to the next module. If the module completed successfully, it would move that module into a separate directory, so that it wouldn’t exist the next time the main script was run. And, if the module failed, it would leave the file in place, so that the main script would start from there if run again. It would also print a message to user, telling them exactly which script failed. Though it wasn’t particularly elegant, it worked as a first implementation.

An image of DWM running on a Debian VM, after having been installed using the debian-dwm script.

Improving My Work

However, once I completed thePrimeagen’s Data Structures and Algorithms course, I decided to revisit debian-dwm and make it better. Armed with my Kinesis keyboard and a better understanding of Git, I knew it was time to start applying what I had learned. One of the first things I learned how to do was to create a loop to run my modules, rather than a bunch of sequential commands. Again, in retrospect, it wasn’t anything special, but it was yet another example of visible improvement. I also learned how to utilize variables in conjunction with my loop – this meant that I could retain control of what order the loop ran the modules in by listing the modules in the order I wanted them to run. In addition, I leveraged the tools at my disposal by using my Proxmox server to test my code: by creating a standardized VM that I could clone for testing, I was able to rapidly test changes I made before uploading new commits to GitHub. At a much faster pace than before, I was able to write, test, and then implement improvements to my code.

Because I was now leveraging Git in more intelligent ways, I also no longer had to worry about finding a way to achieve proper version control. Instead of having a bunch of nearly identical directories, differentiated only by timestamps, I now had the ability to keep all that data in one repository. If I ever needed to look back a previous version, it was as easy as checking a previous commit. In addition, Git and GitHub allowed me to have a central repository for these scripts. Cloning down the repository was far easier than going through the hassle of using scp or rsync to get the scripts onto new VMs. For a first project, I really felt like I was working efficiently and utilizing all my tools in an effective way.

While I started August 2023 with a mess of repositories on my computer, with only slightly different changes between them, I ended August 2023 with a single, awesome repo that I wrote, containing a LARBS-inspired installer uploaded to GitHub. Now, whenever I want to create a new computer with DWM on it, I can use either LARBS or debian-dwm to quickly and effortlessly perform the install. I would continue to work on this project over the coming months, refining it further. But, for now, my attention had turned to something else: my Neovim configuration files.

Building a Library of Documentation

Wed, 23 Aug 2023 21:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Introduction

This article tells the story of how I wrote my own Git repository for guides – this project can be accessed by following the link to my GitHub.

Documenting my progress

The more I’ve made progress in my IT and home lab journey, the more I’ve noticed a certain trend regarding documentation. Often, for whatever project I’m working on, there is a common breakdown with resources I use:

There is a primary resource (official documentation, etc) that gets me about 90% of the way through the project.
There is a secondary resource that gets me another 8% of my progression.
Finally, there’s a third resource that resolves some issue I’m having, and that resource gets me the last 2% of the way through.

The percentages may vary, but there are almost always primaries I use, with some other resources assisting me with issues along the way. I usually make a point of bookmarking all those resources, though I’ll also bookmark other resources I used throughout the process. Once I’ve deployed whatever service it is, I won’t touch the project, or its resources, for about 3-6 months.

Eventually, I’ll come back to the project, and this is where I began to notice problems. I can almost always find the primary resource, and I can usually find the secondary resource. However, I often have immense trouble finding that obscure post buried deep on some message board. Even despite having the bookmarks saved, I’ll have to repeat the process of digging through the bookmarks to find that post. And, if I don’t have the post bookmarked, then I have to try and remember what search query I used to find that page, etc. It can be a real hassle, and it’s especially irritating when it’s regarding a problem for which I already found a solution.

So, I decided in 2023 August to take it upon myself to document the steps I was taking. I was absolutely tired of struggling to find the resources I used in the past, and I knew that keeping records of the process would allow me to more rapidly deploy projects I had already completed. I imagined it would be helpful to have a single resource that, if I followed the outlined steps, would get me 100% completion every time. I also thought that reading documentation written by me, for me, would be far easier to read and parse than some article written by someone else. This initiative became my Library git repository.

The “Library” repository

While it started out pretty basic, with some guides on installing Arch Linux and Debian (as well as some other troubleshooting tips), my Library repository has developed in an ever growing assortment of documentation on many of the projects I’ve completed. While it’s a time-consuming process to document the working steps, and it’s meant that I complete projects slower than I would if I skipped the write-ups, it has paid dividends in excess of the effort I’ve put in to maintain it.

Maintaining the documentation on GitHub has had extraordinary benefits. While I didn’t know much about git when I first started, having version control on my guides since the beginning has enabled me to easily view past versions of the guides. Whether it be looking back at the original versions of guides and seeing how much they’ve changed, or making an adjustment that didn’t work out as intended and reverting the change, using git to manage a large store of documents has made it really easy to work with a constantly developing set of materials. Also, while this was never the expectation, I have since had co-workers ask me how I set up certain services and servers, and it’s been really awesome to be able to direct them to guides I wrote. Mostly, my guides have been complete enough to get them to the point where they were able to set those same services up, without having to debug the issues I ran into. On occasion, something I added to the guides wasn’t as clear as it could have been. While the guides were originally written for me, and I could usually understand my own shorthand, learning to write documentation more clearly has benefitted everyone involved. It’s definitely inspired me to continue maintaining the “Library” as I learn more.

As of 2024 August, almost an entire year later, I now have guides on so many different projects I’ve worked on. I have writeups on 9 different server projects, how to set up default server configurations for both Debian and Alpine Linux, as well as troubleshooting docs on various issues I’ve encountered. I have also improved a bunch of the content that I’ve posted throughout the year, and made the guides more readable and useable; not just for me, but for anyone who uses the documentation.

Git: I "Git" It Now

Tue, 22 Aug 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Clowning Around on GitHub

To tell the story of how I learned Git, I have to start by being honest: I began using GitHub in January 2023, before I understood Git. Back then, I used it primarily to upload some text files containing “tricks and tips” that I had written and accumulated throughout 2022. None of them were all that good; I didn’t even know how to write Markdown at the time. I just needed a place to put some badly formatted text files so I could access them from other computers, and GitHub worked for that purpose.

I was such a clown about it though. For example, I was editing those text files through GitHub, directly from the browser. Every time I made a small change, I would “save changes” on the web page. I didn’t understand how GitHub worked under the hood, I just did what seemed to make sense. Now, looking back at those repos, I recoil at seeing 300+ commits with absolutely 0 useful commit messages. Checking the difference history and seeing that I was literally editing the text files one typo at a time… it hurts.

I really started properly using Git (and GitHub) in summer of 2023. While I created my @davidvogelxyz account in June 2023, it took a few months for me to start using it. However, after learning more from thePrimeagen, especially from his Data Structures and Algorithms course, I realized it was high time for me to learn how to use Git in a more intelligent way.

And, I’m really glad that I did. It has been, by far, the most useful tool that I’ve learned to use thus far.

Beginning to “Git” Good

There were tons of resources on YouTube that I remember using to start to learn Git: a couple of channels include Chris Titus Tech and Fireship. Some of those videos are embedded below. With my new keyboard assisting me, I consumed tons of content on Git, and came up with some projects that would allow me to test out what I learned. More on those in a bit.

While my Git skills have developed massively since this period, I was starting from zero. Therefore, my focus was on the small things. I began to learn how to make useful commit messages. I leveraged what I knew about GPG keys to make sure I was always signing commit messages with a GPG key. I moved away from editing files in the browser, in favor of using Vim and the terminal to make changes. After committing those changes, I learned how to push changes to the remote repository. These were small steps, I know. But, it was progress.

I also started to develop a deeper appreciation for good documentation. Instead of badly formatted text files, I was writing up guides to projects I was working on using Markdown, compiling them into a repository I called the Library.

I began to notice that any project I worked on usually involved three different sources of information: one that I got 85% of the knowledge from, one that was 12%, and a final one that was the remaining 3%. While I could almost always find the 85% again, and usually find the 12%, it was incredible how often I would fail to bookmark the 3% tip that would fix some issue that I was struggling with. Instead of trying to dig through pages of search results to find it again, I began to write my own comprehensive guides, so that I could use that “single source of truth” going forward, knowing that it had all the information I needed. It didn’t matter to me if no one else ever used them; it was good for me to start working on building and maintaining my own work.

Git is a version control software, and it is definitely the main attraction. Having the ability to manage only one set of files (rather than multiple copies of the same files, differentiated by timestamps), but also the ability to look back at previous versions, was an incredible benefit. It also allowed me to easily peer back at the previous state of my work, which made it easier than ever for me to appreciate my growth over time. More than ever before, I had a tool that enabled me to visualize the progress I was making. And that felt really good.

After watching those videos over the course of a day or two, I decided that the best way to gain some skill with Git was to work on a few projects that would force me to use Git properly. The two primary ones from this period of time were:

debian-dwm - Any time I installed an Arch/Artix Linux desktop, I was using LARBS. I was a huge fan. However, I was using my Proxmox to spin up a bunch of Debian VMs over the summer, and I wanted a way to automate the process of installing the tiling window manager dwm onto those machines. So, I wrote an installer, inspired by LARBS, that would do exactly that.
- Link to the debian-dwm project on GitHub
Neovim config files - While I had studied the art of Vim under Vim Diesel (Luke Smith), I was approaching a point of stagnation by using someone else’s Neovim config files. Therefore, assisted by a video by thePrimeagen, I decided to write my own config files.
- Link to my Neovim config files on GitHub

Helpful Videos

Kinesis Keyboard: Typing Without Pain

Mon, 21 Aug 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

A Better Way to Type

Coming off the heels of thePrimeagen’s Data Structures and Algorithms course, I was experiencing some major wrist pains from writing TypeScript code on a laptop keyboard for 20 hours of the past week. I realized that I would need to do something (and fast) in order to solve the problem, if this was a path I wanted to pursure. However, the solution was right in front of me, even if it was a bit expensive: the Kinesis Advantage360 keyboard.

I had seen Prime using the Kinesis keyboard throughout the Data Structures and Algorithms (DSA) course, and I knew from other videos of his that he was a huge fan of his keyboard. Since I had already started to feel pain in my wrists from only a week of coding, I decided to take the plunge and get myself one too.

An image of the Kinesis Advantage360 keyboard.

It was an absolute game-changer. It wasn’t without some growing pains… but, at least the wrist pains were gone.

I ordered the keyboard the weekend after taking Prime’s DSA course, and it arrived the following Monday. I excitedly unboxed the keyboard, cleared it off my desk, and admired it for a few minutes before plugging it in and testing how it felt. I pulled up MonkeyType and started doing some typing tests. I was amazed. Where I had been able to type at ~100 words per minute (WPM) on my conventional mechanical keyboard, I was now typing at a record… 3 WPM.

I was shook. Was this a skill issue, or was it the keyboard? I tried out some more typing tests. Thankfully, I started seeing some improvements after a few minutes. 3 WPM became 4 WPM, 4 WPM became 6 WPM, and it wasn’t long before I was back at a mighty 10 WPM. Clearly, it was going to take more effort than I had expected to get use to the keyboard. After a few hours of typing tests, I started to approach 60 WPM. Not my fastest, but I was getting the hang of the keyboard.

The Benefits of Using a Kinesis Keyboard

While I’m back to my previous highs of 100 WPM, and I’m grateful for all the changes I had to get use to, I didn’t realize that it would take a day or two (up to a week) to get used to them. The benefits of the curved and orthogonal keys are unmatched; but, early on, I found myself attempting to move my fingers in ways that I no longer needed. In addition, I no longer have to use my weakest fingers to reach out for curly braces ("{ }") and brackets ("[ ]"), as they’re found just below the comma and period keys. This has resulted in a far more comfortable experience when writing code. I also like that I get to use my thumbs to access keys like Ctrl, Alt, and the Super (Windows) key, which means I can utilize my window manager (DWM) with far less strain than I would with a regular keyboard.

What’s been most interesting about the experience has been going back to conventional-style keyboard, like I do when I use a laptop from time to time. I really haven’t seen much of a slow-down coming back to regular keyboards, as I can still hit numbers in the high 90s (WPM). The only difference is: I know what I’m missing, and I’ll long to get back to my Kinesis keyboard as soon as possible. And, that’s because using a Kinesis keyboard really has been such an improvement to my work flow. I really didn’t think it would make such an outsized difference in the typing experience, but it has.

The only other thing I’d mention in this article is this: while I only heard thePrimeagen say this after I purchased the keyboard, it’s stuck with me ever since. As I can’t find the clip where he said it, I’ll paraphrase: “don’t wait until you start having wrist issues to get a fix implemented.” I find it astonishing that I started to have wrist pains after only a week of attempting to code on a laptop keyboard. In contrast, I have spent many hundreds, if not thousands, of hours typing on the Kinesis keyboards since purchasing my first one in August 2023. Not once since then have I experienced any sort of discomfort while typing. Not only are my wrists saved, but by using a split keyboard, I’m also sitting up straighter as I type, which has helped my posture immensely.

It really has been a game-changer.

Helpful Videos

Learning Data Structures and Algorithms with thePrimeagen

Fri, 18 Aug 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Introduction

This article describes what it was like taking thePrimeagen’s Frontend Masters course on Data Structures and Algorithms. In order to best learn the course material, I followed along and manually typed out the same algorithms, in TypeScript, that were taught in the course. Those algorithms can be found on my GitHub in the TypeScript collection repository.

Deciding to Learn Some Programming

During the end of July 2023 and into August, I began to watch YouTube videos by a Twitch streamer by the name of “thePrimeagen”. His content seriously caught my attention, if for no other reason than he was an avid Vim user, whose skills greatly surpassed mine. Maybe it was his use of coconut oil; I wasn’t sure. But, I felt that I could learn a lot by watching him work.

I was wrapping up my free trial experience with HackTheBox, and getting ready to put down $15/month in order to get access to the full platform, when I came across thePrimeagen’s Data Structures and Algorithms course on Frontend Masters. It was appropriately named “The Last Algorithms Course You’ll Need”. I was sold. As someone who had been working on some basic Bash scripts over the past few months and had a very basic understanding of programming, I felt like this course might be a great place to learn the foundations of computer science.

My interest in learning how to code had also been accelerated by the HackTheBox experience. I was getting frustrated with myself for having such a limited understanding of some of the tools that I used for penetration testing. I wanted to get to the next level, where I might be able to start building useful tools for myself. Plus, if I completed thePrimeagen’s algorithms course quickly, I could use my remaining month with Frontend Masters to take some other courses. And, worst case scenario, I could always revisit HackTheBox in September once my membership had expired.

Taking the Course

I started taking thePrimagen’s course on August 14th, the Monday after the Friday that I finished the HackTheBox free tier. I was extremely excited for the course, as Prime brought an energy to teaching that I had sparingly encountered. However, I was not prepared for what I had gotten myself into…

I wasn’t prepared for a handful of reasons:

I had never really done any coding before.
- While I had some experience with Bash from the scripting I had been doing, my scripts were incredibly basic at this time. Essentially, they were just a series of commands that were being done in succession. I hadn’t even written a “for loop” before!
I had never seen any JavaScript code before, much less TypeScript.
- I was able to follow along with what was going on, simply because I had been working for the past year on reading source code for Bash scripts, etc. However, I didn’t have any experience with JS/TS, and so there were operations that were being performed that I didn’t understand without pausing the lectures and looking up documentation.
There was a lot of terminology that I had never encountered before.
- Similarly to the coding language being used in the course, there was a lot that I hadn’t seen before. There were many times throughout the course that I chose to stop and look up the things I didn’t know, so I could make the most of the learning experience.
My wrists hurt. A lot.
- Erroneously, I decided to take the course by casting the lectures to my TV and working with Prime by using a laptop. After a 10 hour course that required an additional 10 hours of work as I followed along, typing out every algorithm that he used, I started to get incredible wrist pains, especially from trying to hit all of the curly braces ("{ }") with my ring and pinky fingers. More on this in a bit.

However, I was also more prepared than I thought I’d be. For someone with only a basic understanding of programming, I realized that the work I had put into Linux and Bash were working in my favor. I may not have been able to intuit everything Prime was teaching, but I could read the code, and I was able to complete the course despite having to look things up. I was also reminded of a YouTuber named Presh Talwalker, who ran a channel called “Mind Your Decisions”. On this channel, Presh would give some difficult math and logic problems, and then demonstrate how to solve them. Watching some of his videos had definitely prepped me for Prime’s course, as many of the algorithms he taught allowed the students to solve problems similar to the ones on Presh’s channel. Not only were the problems similar, but I was learning to solve them using code!

An example of a logic problem that was solved with an elegant solution was dubbed the “Two Crystal Balls” problem. The context for the problem was this: the student was given two crystal balls, from which we needed to find the height from which the ball would break. Obviously, we could just drop the first ball from n=1, and iterate up until the ball broke. Then, we’d have the answer! However, this solution would take O(n) (O of “n”) time to solve. The more efficient way to solve the problem was to utilize both balls. How? We could drop the ball from multiple of the square root of the highest point (100). Once the ball broke, we could use the second ball to iterate by one, starting from the last point of non-breakage, until we found the height at which the balls would break. Solving the problem in this way would only take O(log(n)) (O of log(n)) time.

I found learning to solve problems like this fascinating, and learning how to utilize different algorithms and concepts to solve problems more efficiently has yielded tons of benefits to me (most of which would only reveal themselves later into the future). I was enjoying the content so much, that I powered through the entire course in less than a week – starting on Monday the 14th, I had completed the entire course by Friday, August 18th.

An image of some TypeScript code that was written as I worked through thePrimeagen’s DSA course. Specifically, this was an implementation of a data structure called a “stack”.

In the course, I also learned algorithms and concepts such as:

Linear search
Binary search
Bubble sort
Queues and stacks
Arrays and linked lists
Quicksort
Tree traversal
- Depth first traversal
- Breadth first traversal
Binary search tree
Heaps
Graphs
Dijkstra’s shortest path
Maps
LRU caching

The Aftermath

After completing Prime’s algorithm course, and deriving a ton of value from it, I decided that it might be worth my while to learn a programming language and go deeper into coding. I hadn’t yet figured out which language I would choose. Right after the course ended, I thought it might be JavaScript or TypeScript. After taking an intro course to Python with my remaining Frontend Masters membership, I decided that it wouldn’t be Python; mainly, because I noticed that I could code in Python without too deep of an understanding of the concepts I had just learned about from Prime’s course. I wanted a language that would allow (nay, force) me to continue to develop my understanding of computer science. I wouldn’t figure it out for a few months, but I eventually chose Rust as my first programming language.

However, more immediately, I resolved to make a few changes to how I did things. First, if I was to continue to learn to code and do the things I had been doing, I would need to figure out this keyboard situation. After watching Prime use a Kinesis keyboard throughout the course, I decided to get my own. I also made the decision to learn how to use git properly. With the combination of the Kinesis keyboard and a better understanding of git, I would also spend the next few weeks working on two major projects: creating debian-dwm, a version of Luke Smith’s LARBS that would install DWM onto Debian computers, and building my own Neovim configuration files from scratch.

Video Preview of the Course

HackTheBox: Learning Penetration Testing

Fri, 11 Aug 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Hacking the Box (ethically, of course)

Throughout the summer of 2023, I was working on improving my Linux and IT skills. I had built a webpage and e-mail server, deployed a Nextcloud instance using Docker, and even messed around with NixOS. I was putting hours of my day, every day, into this process. While this was a fun and engaging process, I also sought out downtime here and there. But, I also wanted my downtime to at least be “somewhat productive.”

I settled on finding a “hacking game” to play – something that would help me learn about the Linux command line interface (CLI), while also being fun. I found a few games, including Shenzhen I/O and Hacknet. While playing through the first hour of Hacknet, I realized that it was at best a facsimile of the actual CLI experience; it wasn’t going to teach me much, but it was going to approximate the experience. But, I thought, “why play a game on a pseudo-Linux CLI when I could learn stuff that actually uses the Linux CLI?”

Around the same time, I watched yet another NetworkChuck video or two, where he mentioned a platform called HackTheBox. It was exactly what I was looking for. Instead of playing a game that “mimicked” hacking, and wasting valuable time, I could instead divert my attention to something that would provide value to a future career in IT and system administration. Not only would learning basic penetration testing provide value, but it would also develop skills that could translate into the real world. If my future involved “white hat hacking”, then I would learn how to penetrate Linux systems; if my future involved cyber-security or system administration, then I would learn what types of attacks were possible, and I could start thinking of ways to better secure servers.

So, I spun up a free HackTheBox account and started my journey. I started with the “Starting Points” section, which claimed that it would teach me the “basics of penetration testing.” I learned how to connect to FTP, SMB, telnet, rsync, and RDP anonymously; used nmap to identify open ports, and broke into a MongoDB server. Then, I continued on, and learned how to perform SQL injections, server-side template injection, remote file inclusion, and how to perform attacks using remote SSH shells. I also learned how to use privilege escalation, perform cookie manipulation, brute force passwords with john the ripper, and exploited some LXD containers to gain access to privileged file systems. I was so engrossed with what I was learning, I completed all of the roughly 15 free VM targets in about a day or so – I started on Thursday afternoon, and had exhausted the free tier by Friday evening.

An image of the “HacktheBox - Starting Points - Tier 2” dashboard, with a short overview of the activities in this section.

Pwning HackTheBox

As a note: I have since learned a few things about the platform. HackTheBox (HTB) Labs is the part of the website that gives access to the “Starting Points” educational boxes. In addition, a “free user” is usually limited by the 2 hour time limit on the free-to-use “pwnboxes” – I was able to maximize my use of the free tier by leveraging my Proxmox and VMs.

Not only did I power through the free tier, but I did so utilizing skills I had been building over the past 6 months. While I could have used the freely provided “pwnbox” VMs, I instead opted to use my own VM through my Proxmox to complete the “Starting Points” course. Where I could have installed “Kali Linux” to a VM, to have all of these hacking tools readily available, I instead opted to use a Debian VM I had created, running dwm. This meant that I had to go out and install all of the different packages I needed myself. And, it resulted in me learning more about the tools I would use than I would have if I had them pre-installed on the VM. I remember using nmap to query a server’s open ports, hashcat to crack password hashes, and tcpdump to intercept network traffic. While some of the packages were available in the Debian package repos, there were also tools that I could only acquire by cloning down git repositories and building the software from source code, something I had rarely done before this point. Going through the HackTheBox course material improved my skills in far more ways than just “penetration testing.”

Once I completed the free tier of HackTheBox, I seriously considered shelling out $15 for a month’s subscription to gain access to the gated content. While I didn’t end up doing this, it was only for a few main reasons.

The free VMs that were part of the “Starting Points” course were very structured.
- While there were more “Starting Points” VMs to hack, I would soon complete those too. Then, I would have access to a myriad of boxes that were far less structured. It would quickly become a test of “use the skills you’ve learned, and be creative.” While there was tons of merit to continuing on, I decided that I wanted to only spend the $15 if I was going to seriously commit to an hour or two of HackTheBox per day, and I wasn’t ready to do that.
I decided to go down a different path. In late July and early August, I had come across on YouTube a programmer and streamer by the name of “thePrimeagen”. I enjoyed his content greatly, and his videos started to plant a seed in my head - maybe I should consider learning more about coding. In particular, I had discovered that he had a data structures and algorithms course on Frontend Masters, and that I could access that course for a $39 monthly subscription. Instead of putting the $15 towards HackTheBox, I decided to pursue a Frontend Masters subscription, with an expectation that I would eventually return to HackTheBox when I was done.

Helpful Videos

NixOS: Declarative Configuration Systems

Tue, 11 Jul 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Running NixOS

After getting my website and e-mail server set up, and after trying out Nextcloud through a Docker container, I was looking for other ways to expand my Linux knowledge. I had already come to the conclusion that distro-hopping was largely a waste of time. I ran Arch (specifically, Artix) for my main desktop PC, and I used Debian (no longer Ubuntu) for all of my server projects. Beyond this, I felt that other Linux distributions were just “variations on themes” – a few configurations might be changed here and there, but nothing was ever substantially different. If I wanted to see real variation, I could just install a different desktop environment (DE) onto a Debian or Arch VM and test that out.

However, this all changed when I found out about NixOS, thanks primarily to Chris Titus Tech’s videos on his testing of NixOS.

NixOS is a Linux distribution that is more than just its eponymous package manager, Nix. It is an Linux distribution that focuses on state-based configurations, using an immutable design and declarative configuration. In more simple words, it was an operating system that allowed the user to configure the system using one configuration file, and this file would allow a user to deploy a fresh install of NixOS and have a perfect reproduction of another system. This is incredibly cool, and has many utilities when it comes to deploying multiple identical Linux machines.

Specifically, I saw a Chris Titus video from mid-June 2023 that discussed the utility of NixOS in a corporate environment, because of Nix’s state-based configurations. The last time I had heard someone say that (re: Proxmox), I jumped on the opportunity to learn and benefitted greatly. Would NixOS be another Proxmox in terms of the value I would derive from it?

I had to find out.

While my stint with NixOS wasn’t longer than a few weeks, I was able to successfully configure a fresh “configuration.nix” file that implemented dwm as the window manager, as well as my zsh config files.

An image of a neofetch output on a NixOS VM running DWM.

Beginning to Appreciate Git

One thing I will note is that this was one of the first instances where I began to appreciate the value of git, and separately GitHub. Part of the fun of NixOS is being able to completely delete a VM and reinstall NixOS from scratch, while retaining all the progress I made by using a configuration file. However, in order to do that, I would need an easy way to access that configuration file. This is where GitHub began to play a role. GitHub allowed me to upload my configuration file to a publicly hosted repository, which made using curl to download that configuration file during install incredibly easy. On top of that, by using git, I now had a way to track any changes I made during the process.

Didn’t like something that I did? Changing a line broke my system? I could just roll back the changes to a previous commit and keep going as if nothing had happened. This was very useful, and I was only beginning to scratch the surface of that utility.

The Inception of DWM Install Scripts

Another note worth mentioning is that, between spinning up a bunch of Debian VMs on my local Proxmox, and now creating a NixOS VM, I was hitting a phase where I was getting tired of doing “the same work over and over again.”

Because of my appreciation for how efficiently I was using LARBS on my desktop, I figured out how to get dwm working on Debian, as well as on this NixOS VM, and I wanted to make future deployments simple and quick. So, in combination with beginning to learn about and appreciate git, I started working on scripts that I could use to quickly install dwm to VMs, without having to manually enter commands. While those adventures will be detailed in a future article, I was beginning to write those preliminary scripts in late July and early August of 2023, and was using them in conjunction with my “configuration.nix” file. This allowed me to use a NixOS VM, test out some new features, tear it down, and then use both my “configuration.nix” file and my dwm scripts in order to get everything back in working order. While I could have improved the reproducibility of my NixOS experience by using home-manager, I was beginning to get more proficient with different Linux distributions and learning how to troubleshoot issues that would arise.

Troubleshooting NixOS

My initial attempts at NixOS, and specifically getting dwm and dwmblocks working correctly, came with a bunch of obstacles to overcome. I probably could have used home-manager to resolve some of these issues, but I was focused on making things more difficult than they had to be by configuring everything the way I was used to.

While I was able to get dwm working rather quickly, I spent a decent amount of time attempting to get dwmblocks to display correctly. Even when I did, I had a lot of trouble getting the bar’s objects to be clickable. I’m writing this article after the fact (and after having deleted my NixOS VM in favor of a fresh start), but I don’t recall ever getting the bar to work as it does on Arch and Debian.

Another piece that required many iterations was getting an optimized “configuration.nix” file. Back during the summer of 2023, my coding and scripting skills were minimal. I could parse a NixOS configuration file, but I ran into some issues while writing my own. Piecing together a working config file required trial and error, and I redeployed the NixOS VM a handful of times as I figured out what worked and what didn’t.

The only reason why I didn’t continue further with NixOS was because I set my sights on a new target: learning penetration testing with HackTheBox.

Fresh Install - Tips and Tricks

While it took me a handful of days to get my “configuration.nix” file working correctly, the benefit of NixOS is that a fresh install is incredibly easy when using a previously configured installation. I would simply use the file I created, which can be found on my GitHub, and run:

nixos-rebuild switch

A fresh configuration is mostly similar. Boot into an installation media (ISO burned onto a USB drive), do the same partitioning and file system creation done for any Linux distribution, mount the drives, and then run:

nixos-generate-config --root /mnt

Configure the file found at “/mnt/etc/nixos/configuration.nix”, and then install the OS using:

nixos-install

Helpful Videos

Nextcloud Cloud Storage, in a Docker container

Sat, 08 Jul 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Self-hosted Services.

A Personal, Secure, Open-Source Cloud Storage Suite

Having just completed the website and e-mail server project, I was looking for another project to expand my home-lab. Fortunately, NetworkChuck had just released a video a few weeks before on setting up what is essentially a “self-hosted version of Google Cloud.” After watching the video, I decided this would be a worthwhile project to work on.

However, NetworkChuck’s video was about using a software called FileCloud, and deploying it on Amazon Web Services (AWS). After my previous experience with AWS, I chose not to go that route. I also reviewed FileCloud, and decided not to use it, as it wasn’t free and open-source software (FOSS).

Instead, I opted to deploy Nextcloud, a FOSS solution, on Vultr. While I could have also deployed this server on my local Proxmox, I would have to open up my home network in order to make the service publicly accessible, which was something I didn’t want to do. At the time, I didn’t know enough about networking and deploying remote SSH tunnels to have known there were other solutions to this problem. While I already had my TrueNAS configured and working, I didn’t feel comfortable opening up public access to my private NAS. I wanted something separate from my NAS, that also came with a web UI for easy drag-and-drop access regardless of what computer I was using. As a reference, I had used ProtonDrive in the past, and I was looking for a self-hosted FOSS solution that would mimic the experience I had there.

So, with my plan in hand, I spun up a Debian VM on Vultr and deployed a Docker container running Nextcloud All-in-One (AIO), using Portainer to make the container management easier. I also purchased a domain to pair with the server, so that I could easily access the server from any VM or computer I used in the future. Given that the Nextcloud documentation specified certain resource usage, but also keeping in mind cost limitations, I decided to roll with a $20/month Vultr VM with 2 CPUs, 4GB RAM, and 80GB storage. I had very little issue with running the Docker container after my previous experience with Docker, and I shortly went into the testing phase.

An image of the Nextcloud login page, after deploying Nextcloud on a cloud service provider.

This project was interesting, for a bunch of reasons. The primary reason was that this Nextcloud deployment was the first time I ran into a situation where my choice of VM was directly affecting performance. I actually started with a $10/month 1 CPU, 2GB RAM machine, and instantly would have problems with the server crashing when trying to upload files to my shared drive. Even after upgrading to the 4GB RAM version, I was still encountering issues with the web UI locking up if I interacted with it too much. Any of these server issues ended up requiring a server restart. It was incredibly frustrating, and directly impacted my ability to make use of the service I had created.

Eventually, I realized that I was either going to be paying $20/month for a sub-par experience, or have to upgrade to the $40/month 8GB RAM VM in order to get the performance I was looking for. For the amount of usage I was getting from the deployment, I couldn’t justify a $240/year server, and I really couldn’t justify a $480/year server. So, after a month of testing the Nextcloud Docker container, I shut down the server and moved on to other projects. Fortunately, I had one on my radar: testing out NixOS.

Helpful Videos

Web Pages and Mail Servers

Thu, 22 Jun 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Self-hosted Services.

Introduction

For more information on how I would set up a web and SMTP server today, check out my guide on creating a web and SMTP server, found on my GitHub.

My first web page

This website, davidvogel.xyz, is a project that I created using Hugo and self-hosted using Vultr.

After learning how to use Hugo from Luke Smith and his videos (more here), I was excited to create my own webpage to document my journey through the build-out of my home lab. Through the guidance of another of his videos, embedded below, I deployed a VPS on Vultr and bought a domain and built this website.

At that time, there was only a handful of projects to document, so I got to work writing articles. Through this process, I not only became more comfortable with spinning up servers in the cloud, but I also learned how to do various things, such as:

configuring DNS records for websites
create webpage configurations with nginx
working within vim (specifically, neovim)
writing shortcodes for Hugo in Go
writing articles in Markdown

During early summer of 2023, I created articles for all of the projects that I had done up until this point. While my writing has improved over the course of running this website, it was a great experience to document what I had done thus far. I learned how to write documentation in Markdown, which has come in handy as I’ve continued to write guides for my GitHub. I started to learn how to code during this time. One of my accomplishments was to create a shortcode that governs the menu found at the top of my website. Another was to write a shortcode that assessed if my articles were older than a certain date, and to add a context blurb explaining that the article was written “in the future”. I also edited some of the existing shortcodes that controlled the “previous” and “next” articles, found at the bottom of most pages. All of this was done in neovim, which I was beginning to really like as a text editor. I was learning Vim motions, and I no longer felt that nano was a faster way to get work done. It was a great summer!

However, I wasn’t satisfied with just a webpage. As Luke demonstrates in the video, it was also possible to set up a hosted mail server, such that I could have an e-mail account with my own personal site. I used the installation script that he built to do this too (and had to get permission from Vultr to open the SMTP ports for my server), but I was able to get that working too.

The more I worked on projects like this, the more I was developing a passion for Linux, and self-hosted servers, and free and open-source software. I wanted to complete even more projects, which is why I quickly jumped into the next one: deploying an instance of Nextcloud cloud storage.

Fresh Install - Tips and Tricks

Tips and tricks for setting up a webpage and mail server for the future including the following:

watch Luke Smith’s video. There are a handful of minor additions I have from my time setting up this webpage, but this is an occasion where the original video is truly the best source of information on how to do it.
Regarding nginx, reading documentation on what the server configuration settings actually mean will help in the future with deploying other server projects.
Regarding vim and neovim, I learned the basics from watching videos made by Luke Smith. In particular, he has a video where he spends an hour going through vimtutor. This is an excellent starting point, and gave me a foundation from which to learn how to Vim. More on this in a future article.
Regarding shortcodes, Luke’s video on how to create shortcodes is a great introduction. To go beyond that, read the Go documentation and start learning Go’s syntax.
Regarding Markdown, a quick read-through of the documentation on getting started will help greatly.
- I think this is an especially good skill to develop, as being able to write in Markdown has many applications, such as being able to create guides and documentation that can be posted onto GitHub, etc. Many projects support Markdown, and it is a simple syntax that makes writing formatted text really easy.

Helpful Videos

Hugo: A Static Site Generator

Fri, 16 Jun 2023 22:24:38 -0400

This article was written in 2024, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Self-hosted Services.

Creating Websites

After building out a bunch of different services for my home lab, I decided that I wanted to document my journey and process. What better way to do that than to build my own website and begin to post content in the form of blog posts, etc?

While there are many services (WordPress, Wix, SquareSpace, etc) that make it relatively easy to set up a web page, I instead opted to use Hugo, a static site generator written in Go. The reasons for this were multi-faceted but simple. I wanted a solution that was:

free and open source
easy to learn, implement, and reproduce
did not add in any unnecessary bloat (additional code, like JavaScript, or any additional features like databases, etc)

With this in mind, I found a couple of tutorial videos by Luke Smith (embedded below) that vastly reduced the learning curve for Hugo. It took no more than a few hours of reviewing his content and beginning to build a web page before I had this website built.

One of the perks of Hugo that I really like is its ability to host a Hugo server on a local machine, and being able to access to a live preview of the website. While there are other ways to implement a Markdown previewer, such as a Neovim plugin, having a live test webserver meant that I could make an edit to an article, and immediately see the rendered output before committing any changes. This is incredibly useful, as it allows me to make sure that everything on the site, including hotlinks, are linking correctly before I push any articles to the live webserver.

To make life easier, I set up a VM on my Proxmox for hosting Hugo servers. One particular trick that I implemented was creating a systemd service that would initialize the Hugo server on startup. Beyond the benefit of the server automatically coming online anytime the VM was booted up, setting up systemd services also allowed me to host numerous Hugo servers at the same time by changing the port. This allowed me to work on multiple different website projects at any given time, with all of the startup automated. Very convenient!

With my first web page created in Hugo, the next step was to self-host it.

Fresh Install - Tips and Tricks

The following is an example of what a systemd file for Hugo looks like:

[Unit]
Description=hugo
After=network.target

[Service]
WorkingDirectory=/home/$USER/...
ExecStart=/usr/bin/hugo server --noHTTPCache --bind 0.0.0.0 -b $IP_ADDRESS -p 1313
User=$USER

Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

Obviously, a few edits would need to be made for this example file to work:

the working directory needs to point to the active Hugo directory
the “ExecStart” setting requires an IP address for the -b (bind) flag
- this IP address is the same as the IP of the server hosting the Hugo server
- instead of an IP address, a hostname for the server can be used, so long as DNS is able to be resolved at the network level
the “User” setting needs to be set to the user on the server

Helpful Videos

OpenVPN Server Using Amazon Web Services

Mon, 12 Jun 2023 15:25:35 +0000

This article is part of a series on Network Administration.

Introduction

For more information on how I would set up a VPN server today, check out my guide on creating a VPN server, found on my GitHub.

Welcome to the Jungle

While I have been working with cloud service providers (CSP) for months, I hadn’t yet tried out Amazon Web Services (AWS). I decided to re-deploy a project that I’m familiar with, OpenVPN, because I thought it would be easy. “Easy” is not how I would describe my experience with AWS.

The OpenVPN parts of the setup were streamlined and quick; all the hurdles came from the AWS side of the experience. Everything was made intentionally obtuse, and it feels like it was done to necessitate a certification on “AWS.” Instead of just spinning up a Debian server/container using an image, I had to find my way over to the “EC2” dashboard in order to search the “AMI catalog” (AMI, for Amazon Machine Image) for the right selection. The VM configuration page was also riddled with jargon and terms, with all the useful information tucked away behind links. None of this is to even mention how slow the website operates compared to Linode. Despite all the complications, I managed to boot a pre-imaged OpenVPN server and test it out.

An xkcd comic. No context given.

The experience with the OpenVPN web UI itself was smooth. I had never used an OpenVPN server with a web UI before, so it was fun to click around for a bit and see what all the menu options were. I eventually found out that this version of OpenVPN server was operating on a “7 day free trial,” after which I would be billed via AWS. Even though I was supposed to have a “12 month free trial” with AWS for certain VMs, this apparently did not extend to the OpenVPN server. I used the server for a bit longer before bringing it down and terminating all my VMs with AWS. I like the web UI, don’t like having to pay, and still prefer self hosting for my VPN needs.

I’m actually in awe of how bad my AWS experience was compared to other CSPs I’ve used. The AWS web dashboard was slow and painful to use, I spent far too long getting a VM spun up, and I spent the entire time feeling confused. I know from using other CSPs and their platforms that doesn’t have to be the case. Other things that bothered me include:

Because of the SSH sign in being mediated through keys (with no passwords), AWS actually seems to disallow passwords on the servers. To me, this is a huge red flag.
Pricing. While “12 month free trial” sounds enticing, I saw that the pricing for a year of this VPN after the trial ended was $660 USD, or over $50 per month. That’s insane.

All in all, I still have no idea what the appeal of AWS is. It just doesn’t make sense to me. I still want to try Google’s cloud platform though.

So far, I’m pretty happy that I started with Linode and other CSPs like it.

An image of the dashboard to the web UI for the OpenVPN Admin Server running on an AWS machine.

The Build

Software stack:

Ubuntu
OpenVPN

An image of the dashboard of the web UI for Amazon Web Services.

Fresh Install Bullet Points

NB: I have no interest in running this project again, and I have no interest in running any project on AWS ever again.

Thanks to those who got me here!

NetworkChuck for his video on installing an OpenVPN server on AWS

Docker Containers on Arch Linux VM

Wed, 31 May 2023 16:22:27 +0000

This article is part of a series on Virtualization (Hypervisors).

Everybody Loves Docker

Since getting into virtualization, I have heard tons of people say many positive things about Docker. I created a Ubuntu VM in early 2023 when I first created my Proxmox server, but I had only created one or two containers quickly. Now, I not only had an interest in learning about Docker, but a need to learn Docker: I wanted to host my Hugo server using Docker, so I could work on my website before pushing it live.

Docker is incredibly lean. The VM I have Docker running on was given a small amount of CPU resources and only 4GB of RAM. Despite that, it has the ability to run tons of containers all at the same time. While I have been able to run certain containers in ways to push their resource use and max out the VM, it’s not something that I’ve run into during standard server use.

A neofetch of a SSH terminal window for the Proxmox VM running my Docker containers.

The Build

Hardware (virtualized):

2 CPU cores @ 3.8GHz
4GB RAM

Software:

Docker
Portainer

Portainer

I really, really like Portainer. It has made getting into Docker extremely easy. While it was good to watch this NetworkChuck video and do the exercise with him of setting up containers using the command line, there’s a lot with Docker that can get confusing when it comes to the proper switches and flags. Portainer makes it incredibly easy to get Docker containers set up that run the way I want them to.

An image of the dashboard of the web UI for the Portainer docker container, running on my Arch Linux VM, which itself runs on my Proxmox VE server. So cool.

Fresh Install Bullet Points

Here’s how I would reinstall Docker and Portainer if I needed to:

Go to my personal GitHub and reference my guides on:
- Installing Docker and Portainer on Arch Linux

Thanks to those who got me here!

NetworkChuck Portainer video on YouTube
NetworkChuck Docker playlist on YouTube

Helpful Videos

Homer Web Dashboard

Wed, 10 May 2023 22:58:58 -0400

This article is part of a series on Self-hosted Services.

“My first website”

I never thought that I would need a web dashboard for all of my web-based self-hosted services. Back then, I had one service. Maybe two.

But, one day, I had far too many services to keep track of. All of the local IP addresses, all of the port numbers, which ones were ‘http’ versus ‘https,’ etc. It got to be very onerous.

This is when I decided to configure a Homer dashboard.

Life-changer.

This is a screenshot of part of my Homer dashboard.

pfSense on a Protectli Router

Thu, 04 May 2023 22:56:48 -0400

This article is part of a series on Network Administration.

Building a Home Network from Scratch

I was working my way through the CompTIA Network+ certification, and had just finished the travel router project, when I decided it was time to upgrade my home network setup. I had previously been using a Netgear device that served as both the router and the access point (AP) for my network. However, various issues, including a slow web UI and an inability to do VLANs properly, made it clear that it needed to be replaced at some point. I decided to take a small break from studying – May 2023 was now that moment.

I set up a Protectli router running pfSense. And, the process was relatively painlessly, the first time around. I followed a guide (link below) and set up a basic home network, with some custom firewall rules and NAT permissions for my OpenVPN server. I did have to overcome the hurdle of bridging some physical interfaces so I could have additional LAN ports. But, it felt like the issues I was experiencing made sense, and so did the solutions. After getting the network to a stable, working place; I resumed my studying for my upcoming exam. Afterwards, though, it was time for VLANs!

A couple of weeks later, I revisited the router in order to implement those VLANs. Even though I passed my exam, and received my CompTIA Network+ certification, I was not prepared for the weekend of obstacles that I endured. I spent far too many hours of a full weekend troubleshooting. While that was painful, I also gained a ton of experience that studying for the Network+ had not given me. Before, I could correctly answer exam questions about VLANs. Now, I understand them so well that I can set them up even if some of the hardware isn’t playing nice.

Surprisingly, I feel rewarded for the time I spent fixing my home network. I received extremely valuable hands-on knowledge that I’m confident will be useful in the future. I became really comfortable with pfSense too. I can follow someone’s guide and configure a network, but I can also say that I know how to deviate from that guide, as is needed, in order to build a custom network that suits my needs. And, that’s another thing: I got a really secure home network out of it, one that I set up myself. That’s really awesome.

An image of the firewall rules for the LAN interface on my pfSense router.

The Build

Hardware

Protectli

Software

pfSense

Old hardware

I was able to make use of all of my old hardware. The managed switches I had stayed where they were, and the old Netgear router was demoted to just being an access point (AP). This allowed me to extend the wireless coverage to more areas of my home that needed it, since the office area was entirely wired connections.

Takeaways

Even though I followed a guide throughout the process, having a good understanding of networking basics was extremely helpful as I set up my pfSense router.

Bridging

The Protectli router that I have doesn’t have a bunch of LAN connections in the way I was use to. It has one LAN port, and an OPT1 and an OPT2 port (short for optional). In order to make use of the OPT1 port as another LAN port, I had to set up a bridge between the interfaces. That required setting up a new interface between the two, adjusting some settings, and then adding in some firewall rules to allow LAN traffic to talk to anyone. Figuring this out took a mix of searching the right keywords and knowing how to correctly implement the forum post solution I had found.

Firewall

pfSense makes it easy to set firewall rules on a per interface basis. That meant firewall rules for LAN, OPT1, their bridge, and any VLANs I created (and any bridges they needed). While that felt like a lot of work, my solution was building a spreadsheet of rules and working from there. The table allowed me visual clarity into the differences between the VLANs, based on their firewall rules. Then, I copied over to all of them the default block and allow ping rules. Soon enough, I had a complete set of firewall rules for all of my VLANs and other network interfaces. Then, all I had to do was test them.

VLANs

Learning VLANs was painful. The pain had little to do with pfSense or Protectli, a fair amount to do with these being my first VLANs, and a lot to do with issues with my switches and wireless access point. But, through this pain, I learned how to set up VLANs, and that’s awesome.

My first issue was a combination of my inexperience with VLANs and the switches’ (TP-Link) software. Figuring out the correct way to interact with their software took many trials and errors, and a few factory resets for the switches. Some of this was due to the requirement that the PVID also needed to be set in order for the port to actually be tagged. Some of my issues were also due to my interest in putting the switch onto a management VLAN. Eventually, I figured out how to get the VLAN traffic flowing.

The other issue arose at this point, and related to the Netgear wireless access point. When I first implemented the pfSense router, I changed the Netgear device to access point mode, over from router mode. In doing so, a software configuration happened that removed the device’s ability to process VLAN tags – essentially making the Netgear a “dumb switch.” This meant that the AP’s IP address would have to reside within the same VLAN it was propogating. Naturally, this also conflicted with my attempts to set up a management VLAN. Solutions were arrived at, as they always are, but I spent a good while thinking that I had misconfigured the VLANs on the pfSense side.

There was also the small thing with bridging VLANs in order to get VLAN traffic from the VLAN interfaces on the LAN port to the VLAN interfaces on the OPT1 port. Not getting it right (ex. bridging a VLAN to its parent interface) would cause loops and bring the network down. That was a fun learning experience too.

OpenVPN

WireGuard (coming soon)

Fresh Install Bullet Points

Follow the guide that I originally found for setting up a pfSense router
Message board post from Linus Tech Tips about bridging OPT1 with LAN
YouTube video from Tom Lawrence at Lawrence Systems on YouTube describing how to tag the VLANs correctly on TP-Link switches
YouTube video from Tom at Lawrence Systems about OpenVPN on pfSense

Helpful Videos

Travel Router - Raspberry Pi Running OpenWrt

Mon, 01 May 2023 22:58:45 -0400

This article is part of a series on Network Administration.

Secure VPN Internet On-the-Go

I successfully built multiple travel routers, each one using nothing more than a Raspberry Pi, an external USB wireless adapter, and a connection to a remote OpenVPN server.

But why do this? Two main reasons:

Home lab access no matter where I am
Secure internet access when outside the home

If I’m not using my home network, I’m using someone else’s network. Now that I have an awesome home lab, that’s not okay. So I built my travel router with a connection back to my home OpenVPN server so that I always have access to my home’s local network. Access that, for example, allows my laptops to connect to my Proxmox VM server, and therefore my Docker containers, at all times. Or, I can pull a file off of my network attached storage (NAS) anywhere I go. It means that, no matter where I am, I always look like I’m using the internet from the comfort of my home. Sometimes, that’s exactly what I want.

An added benefit to this “everywhere-I-go” home network access is that the VPN tunnel protects my traffic from a potentially compromised network connection. Whether it’s rogue users or a rogue network administrator, using other networks confers a level of risk that the traffic sent over the network will be sniffed. Even with HTTPS and SSL, there’s tons of metadata that can be gathered from any traffic going over the network. If the traffic is instead being routed through an encrypted tunnel until it reaches the VPN server, it would be entirely unreadable. So, the travel router adds a security benefit as well.

Another plus of the travel router is its convenience. Normally, any device that wanted to connect to the VPN would need VPN software and a configuration file. Instead of needing to do that, I simply connect the device to a specific wireless network hosted by the travel router, and the device is automatically connected to the internet through the VPN. The travel router is also configured to have a “VPN kill switch,” so that the router cuts the internet anytime the VPN connection is lost. This ensures that any traffic leaving the router is on its way to the home OpenVPN server) and, therefore, encrypted.

Yet another benefit to building the travel routers was that I was actively pursuing my CompTIA Network+ certification at the time, and the travel routers were a practical home lab project for someone studying for a networking exam. While I followed guides for most of the initial setup, I had a strong understanding of what I was doing because I was solidifying the material I was learning for my certification.

An image of the travel router’s web UI dashboard.

The Build

Hardware:

Raspberry Pi 4, 8GB RAM
External USB wireless antenna
- MediaTek 7601u chipset

Software:

OpenWrt
OpenVPN
mt7601u-firmware driver

As is posted on my GitHub, my particular pair of antenna and driver no longer installs correctly, as the 2023 May 15 update to the mt7601u-firmware driver package broke the compatibility. I now build new travel routers by using a backup image I created from a currently working travel router.

Fresh Install Bullet Points

Here’s how I would rebuild my travel router if I needed to:

Go to my personal GitHub and reference my guide on:
- Setting up travel routers

To give credit to those who got me here:

NetworkChuck Raspberry Pi Travel Router video
OpenWrt guide to OpenVPN client using LuCI specifically for help with the VPN kill-switch

Helpful Videos

Network Attached Storage Using TrueNAS Scale

Sun, 23 Apr 2023 22:56:32 -0400

This article is part of a series on Self-hosted Services.

Self-hosted Cloud Storage

If the Proxmox VE server wasn’t my first “home lab flex,” then my network attached storage (NAS) definitely was. It’s a flex because of the hardware it’s running, but it’s also a flex because of the software it’s running. And, it’s a flex because of how that software is configured. It was actually as impressive as rebuilding a PC and turning it into a Proxmox server with GPU passthrough. Maybe more.

What makes my NAS so great?

The 16GB of RAM it has is pretty great. What makes it better is that I had to completely disassemble the ASUSTOR NAS I had purchased in order to install the two RAM modules. After working on my desktop PC and the Proxmox server, opening up a NAS was no problem, even if it was a complete disassembly.

It runs TrueNAS Scale. TrueNAS is awesome because it’s free and open-source software (FOSS) that’s built on a Debian architecture. What’s more awesome is that I installed TrueNAS on a device whose manufacturer doesn’t condone non-official softwares being installed on their hardware. I would rather have control over the devices I purchase than have a warranty, so I just installed my own software over it. So cool.

The 4 drives that fill the 4 bays of the NAS, and all their storage capacity, are maybe the best part. Self-hosting my own cloud storage that I can access from anywhere with the help of my home VPN server – that’s undoubtedly pretty cool. BUT, what’s actually the best part is how I set those drives up:

The NAS is running ZFS as the file system.
The NAS is configured in RAID 10.
- RAID 10 isn’t officially a thing in ZFS. So, I just configured my datapool to stripe the data between two drives, and then use the other two drives as mirrors. Basically, a RAID 10 on ZFS.
- I get 50% of the theoretical storage capacity of my 4 drives, but I get increased transfer speeds and the ability to lose any 1 drives without issue.
  - Depending on which drives fail, I can even lose two drives without issue.
The NAS has link aggregation (LAG).
- I had extra room on the switch, so I configured LAG on my NAS take advantage of the second Gigabit Ethernet port and speed up transfer times.

That’s why my NAS is such a “home lab flex” – it’s freaking awesome.

The Build

Base - ASUSTOR NAS:

Upgrades/additions:
- 16GB RAM, upgraded from 4GB
- Internal SSD
- 4x 8TB hard drives

Software

TrueNAS Scale

Fresh Install Bullet Points

Here’s how I would reinstall TrueNAS if I needed to:

Use the video guide released by ASUSTOR to correctly disassemble the unit and replace/upgrade the RAM and add an internal SSD
Follow the video guide by the YouTube channel NASCompares to walkthrough the software install, using TrueNAS Scale instead of Core (not by choice; Core wouldn’t install; related to drivers for the NIC)

Thanks to those who got me here!

Helpful Videos

Proxmox Virtual Environment

Sat, 18 Mar 2023 22:52:04 -0400

This article is part of a series on Virtualization (Hypervisors).

Type 1 Hypervisor, a VM Server, for free, in the cloud

Soon after building my custom DIY Desktop PC and replacing my old PC, I watched a video on YouTube by NetworkChuck about Proxmox, a type of virtualization software that I could run as a server. Once I found out I could turn the old computer into a VM server, I knew immediately that I had to make it happen.

In March of 2023, I took the old pre-built computer I had purchased from NewEgg and upgraded nearly every single part of it. Where before I would severely limit how often I opened the comptuer’s case for fear of breaking something, I now enjoyed completely breaking down the machine and rebuilding it as if it was from parts. When it finally booted up with all the upgrades installed, I was so excited - I couldn’t wait to install Proxmox.

And that’s what I did. With my new “old computer” ready, I watched a few YouTube videos and made Proxmox happen. Then, I immediately took it a step further by making sure it had the GPU passthrough right at the start, just like I had done with the QEMU setup on my desktop PC. The upgraded parts came from a one-at-a-time process of trying to fix different problems as they came up. But, I got it done, and my type 1 hypervisor VM juggernaut was ready.

Building out another component of my home lab on my personal home cloud really motivated me to tackle other home lab projects. I felt like I could do it all! But, I had to wait. Right after completing the server, I began studying intensely for the CompTIA Security+ exam, and I had to take a pause from VMs and hypervisors and home lab projects.

Since building the server, Proxmox has become an essential part of my home network. With my self-hosted VM server, I can:

run a VM that hosts all my Docker containers.
try out other Linux distributions that I don’t want to install on bare metal.
use it to play old software, like the occasional ISO I have from old video games I use to play on Windows 98 or Windows XP.
test out anything I want, like intentionally downloading old viruses onto a Windows XP machine.
- And, I can do that all from within a safe environment where I can delete the VM the moment I’m done with it, and it doesn’t harm any of my other machines.
do all of this without bloating my main machine with test VMs, or detracting from its virtualization tasks by utilizing system resources for smaller VMs.

That’s awesome.

A screenshot of the desktop of a Ubuntu VM, being run on a local Proxmox server and being accessed through a web browser.

The Build

Hardware upgrades:

Motherboard: ASRock B450M Pro4 -> ASUS
- Old motherboard was giving me issues in conjunction with other upgraded parts
CPU: AMD Ryzen 2700X -> AMD Ryzen 5700G
- This was a crucial upgrade, as the integrated graphics allowed for the passthrough of the GPU, while still allowing the hypervisor to boot.
RAM: 16GB -> 32GB
- More RAM to split between all the virtual machines
Storage: blah
GPU: NVIDIA GeForce -> AMD Radeon
- Technically a side-grade at best. I gave the NVIDIA card to my desktop for use with QEMU. However, I needed to passthrough a GPU, so I went and found the cheapest Chinese GPU I could find.

Software stack:

Proxmox Virtual Environment
- Type 1 hypervisor

A neofetch of a SSH terminal window of the Arch Linux VM running on my Proxmox VE server. The Arch VM is actively running all of my Docker containers.

How to do backups using CLI

/var/lib/vz: Directory for VM images and something else…
/etc/pve/qemu-server: stuff
/etc/…: more stuff

Fresh Install Bullet Points

Here’s how I would reinstall Proxmox if I needed to:

Go to my personal GitHub and reference my guides on:
- Installing Proxmox
- GPU passthrough on Proxmox

Thanks to those who got me here!

NetworkChuck - Proxmox install video
Techno Tim - 11 Things to Setup Proxmox video
Proxmox documentation on how to set up PCI (GPU) passthrough

Helpful Videos

QEMU on Artix Linux Desktop PC

Mon, 20 Feb 2023 22:51:13 -0500

This article is part of a series on Virtualization (Hypervisors).

Virtualization for the Desktop

QEMU is a type 2 hypervisor. What that means is that, I can install QEMU on an operating system, like Artix Linux on my desktop PC, and that will allow me to virtualize computers within my computer. Using a type 2 hypervisor, I can run virtual machines of all different operating systems from within my Linux PC. As an example, I can run Windows occasionally for games, but virtualize Windows within my Linux OS, and that keeps all of the spooky stuff that Windows does restricted to the virtual machine.

Almost immediately after I got my new desktop PC up and running, I installed QEMU, virt-manager, and a few other packages on it. Not only did I manage to get the hypervisor running; but, not long after that, I successfully passed through the second GPU to the virtualization software. With assistance from an HDMI splitter, I can access my VMs from the same keyboard, mouse, and monitor. That may not sound special on its own, but consider that the setup needs to receive two different HDMI outputs from two different GPUs in order to work. Because of this setup, I am able to get essentially bare metal performance from my Windows VMs, which means that high performance tasks like gaming work just as well virtualized.

Because of my success with installing QEMU and getting the GPU passed through, I was starting to feel good at computers. I got this virtualization setup working, which was one of the main drivers behind building the new PC. But, in addition, I also had installed a ’new-to-me’ version of Linux (Arch, as opposed to Ubuntu/Debian), and I was still successful. I felt like I could tackle any home lab project and I’d make it work. So, when I soon heard about type 1 hypervisors, like Proxmox, I was eager to build out a VM server self-hosted by my own personal cloud.

A screenshot of the desktop of my Windows 10 VM, running on my Artix Linux Desktop PC using QEMU. There are a couple of dxdiag windows up showing the NVIDIA GPU being passed through, as well as the hardware that Windows 10 is virtualizing on top of.

The Build

QEMU

Type 2 hypervisor
Deployed using Desktop

A neofetch of the desktop PC while also virtualizing my Windows 10 gaming VM.

Fresh Install Bullet Points

Here’s how I would reinstall QEMU on an Arch Linux machine if I needed to:

Go to my personal GitHub and reference my guides on:
- Installing QEMU on Arch Linux
- GPU passthrough on QEMU

Thanks to those who got me here!

Mental Outlaw QEMU install video
Mental Outlaw GPU pass-through video
Arch Linux wiki article on PCI passthrough

Helpful Videos

DIY Desktop PC Running Artix Linux

Mon, 13 Feb 2023 22:51:03 -0500

This article is part of a series on Other Projects.

The New Computer

This desktop PC, which I built from parts in February 2023, is ridiculously awesome. Why?

Because I built it myself.
- Building my PC gave me a greater understanding of the inner workings of computers. Even though I had been working with the Raspberry Pi for over a year, I learned more from building a PC that I had from the Pi computers. I felt empowered to diagnose and fix my own computer problems. It was cool.
Because it runs Artix Linux.
- I had been running Ubuntu Desktop on my desktop PC since summer 2022, and I had tried Arch before. However, this was my first time using Arch as a daily driver.
- LARBS!
Because I learned about virtualization.
- One of the reasons why I built this computer with the parts I chose was for virtualization. I had been having trouble playing certain games on Linux because I was using container solutions and emulators to run the games, and I had heard that virtualization through a software such as QEMU could be a potential solution.
Because all of this gave me the tools to learn about Proxmox virtualization.
- While working with QEMU to set up virtual machines was useful in setting up a Proxmox server, so was building a PC. It gave me the skills to rebuild my old desktop PC and convert it into a Proxmox server.

So, for all these reasons and more, my current desktop PC is a powerhouse.

A neofetch of the desktop PC at rest after running VMs for nearly 2.5 days.

The Build

Hardware:

Motherboard: ROG Strix X570-E
CPU: AMD Ryzen 9 5900X
RAM: 64GB (4x 16GB) G.Skill Trident Z DDR4 3600MHz
GPU 1: 12GB AMD Radeon RX 6700 XT GDDR6
GPU 2: 8GB NVIDIA GeForce RTX 2070
Storage 1: 1TB Samsung 980 Pro SSD
Storage 2: 1TB Samsung 980 Pro SSD
Storage 3: 4TB Seagate Barracuda HDD

Software:

Artix Linux
- Arch-based
LARBS
QEMU

Installed using legacy boot (BIOS) and a fully encrypted root partition.

I use LARBS, created by Luke Smith, as a desktop solution. Check out LARBS on Luke’s site or over on Luke’s GitHub. It uses a combination of dwm and dmenu to create a simple window manager solution.

One of the things I find most impressive about my desktop is not how much software it runs, but actually how little software it runs.

I used virtualization to solve some of those needs. With QEMU, I can spin up a Windows machine for any software I want to use that runs best on Microsoft software. No more Wine containers, or bottles; no more Lutris; and, no more having to stash a Windows computer for “just in case.” In fact, the performance using QEMU is so good, that I even install any superfluous Linux software on a VM first, meaning that the amount of software I install on bare metal is very little.

Fresh Install Bullet Points

Here’s how I would reinstall my current desktop if I needed to:

Go to my personal GitHub and reference my guides on:
Download LARBS for the desktop

Thanks to those who got me here!

Building a PC
- Linus Tech Tips
  - Video 1 - POV
  - Video 2 - comprehensive
Installing Artix Linux
- this video guide by Luke Smith (YouTube link)
- The Artix wiki
- The Arch wiki
Learning Artix Linux
- VimTutor with Vim Diesel
- Using LARBS

Helpful Videos

OpenVPN Servers Using Cloud Service Providers

Fri, 16 Dec 2022 22:46:08 -0500

This article was written in 2023, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Network Administration.

Introduction

For more information on how I would set up a VPN server today, check out my guide on creating a VPN server, found on my GitHub.

The Advantages of Using Another Person’s Computer

At the end of 2022, I revisited VPNs. My Raspberry Pi VPN was doing a great job with allowing me remote access to my home network, but my public IP was always my own. Why did I want a different IP? So I could give my phone a VPN connection when using the internet, to reduce the amount of data I leak, and to try and control what does leak. That way, web apps, like social media apps, would believe I live in a different part of the US. I would get reminders to vote for states I didn’t live in. It felt good to push back a bit against all the unrequested, unwanted, permissionless corporate data collection.

Therefore, I sought out cloud service providers (CSP) such as Vultr and Linode for access to cheap and easy-to-use computing platforms. I didn’t know it at the time, but those infrastructure-as-a-service platforms were being offered because of virtualization. Virtualization made it easy to spin up a Debian machine, secure it, and then run the OpenVPN installation script by Angristan. Because of how easy and cheap it was, I actually showed others how to set up their own VPN servers, in order to have alternatives to the well-known VPN service providers. It didn’t make sense to run projects I’ve already run using CSPs; but, I was excited to have them as another tool in my toolbox.

INSERT FROM THE FUTURE: I used Amazon Web Services (AWS) to run an OpenVPN server. For many reasons that are detailed on that post, it was a terrible experience compared to using CSPs such as Vultr and Linode (and others like them). AWS is unnecessarily convoluted with terms, the web UI is slow, and it felt weirdly neutered (and not in a way that made it simpler).

An image of a cloud service provider web dashboard showing two active servers; one for OpenVPN, and one for Hugo.

The Build

Version 1.1 - Cloud server deployment (winter 2022)

Debian 11 (Bullseye)
- UFW
- fail2ban
OpenVPN
Nala (wrapper for apt)

This build lacked much that was noteworthy. Vultr and Linode (and other CSPs like them) made it really easy to spin up a VM with a pre-installed OS, and using Debian meant that I could use the most up-to-date OS installer without casuing the script to break. It was simple and reliable. It simply worked.

The only thing of note was nala. It was around this time that I learned of nala, a wrapper for apt that made package management feel more like pacman while on Debian-based systems. It’s noteworthy because, it made Debian (and by extension, Ubuntu) fun again. It was enjoyable to SSH into a server running Debian/Ubuntu and to do regular updates, if it meant getting to watch nala render the output. It almost made me want to start migrating back to Debian-based systems…

Fresh Install Bullet Points

Here’s how I would rebuild my VPN server if I needed to:

Go to my personal GitHub and reference my guide on:
- Installing OpenVPN server

Thanks to those who got me here!

Angristan for his script
Mental Outlaw for his video about creating an OpenVPN server (YouTube link)

Helpful Videos

Bitcoin Node: Version 3

Fri, 11 Nov 2022 15:58:03 -0500

This article was written in 2023, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Bitcoin Nodes.

Introduction

This article describes an outdated way to build a Bitcoin node. For more information on how I would set up a Bitcoin node today, check out my guide on creating a Bitcoin node, found on my GitHub.

Leveling Up My Bitcoin Node Even Further

By the end of 2022, I had been running the Bitcoin Node Version 2.1 for about a year. It had been running incredibly robustly since I brought it online, and especially after upgrading it to Ubuntu 22.04 LTS in May 2022. But, it also gave off a sense of staleness. I had thought about testing out some potential upgrades, and the end of the year provided the time. And, it was the perfect time, because it was just about the two year anniversary since I started running Ubuntu Linux servers.

I upgraded the Bitcoin node in a big way. I upgraded the hardware to a badass mini laptop meant for gaming; except, instead, I threw a 1TB SSD inside and made it into a portable powerhouse. I also moved away from Ubuntu, right past Debian, and installed Arch Linux. Why not? Then, on top of Arch, I installed a more powerful indexer, Fulcrum, that was going to make my Mempool explorer quicker and my wallet sync even faster. Finally, I added a web UI dashboard, so I can keep track of my home lab web links for later.

The upgrade had its challenges. There were issues with networking and with nginx, and there were some issues that had to do with differences between Debian-based systems and Arch-based ones. Some packages had extra installation steps that I was unaware of. It was not easy.

But, as I perservered through each problem, I became better at troubleshooting issues. I learned more about Linux and about how different softwares interact with each other. I practiced finding my own answers, instead of being able to ask someone for help. It was a struggle, but I came out a better Linux user because of it.

The Version 3 era is also where I really developed a love for building servers. The emptiness of my Homer web dashboard was an invitation to deploy more services and create as many buttons as possible. I also developed an interest in writing scripts so that I could quickly re-deploy my installs instead of copy-pasting commands again and again. That would allow me to build a foundation of knowledge and skill, such that I could reiterate the base layer far more quickly, and spend more time working on new additions to my home lab.

The Build

Version 3.0 (fall 2022)

Arch Linux (x86)
- UFW
- fail2ban
- nginx
- Tor daemon
Bitcoin Core (daemon)
Fulcrum (indexer)
Mempool (timechain explorer)
- MariaDB
Homer web dashboard

Some key notes about upgrading to Version 3.0:

Getting networking at the beginning of the setup process takes a bit more work.
Ubuntu has a user named ‘www-data’; on Arch, this user is named ‘http’. In addition, the Arch directory is located at ‘/srv/http’, rather than whatever Ubuntu is. This took me a while to figure out, and I was not able to get Mempool nor NGINX working until I did.
Some of the directories for NGINX needs to be manually added. Not sure why, but a quick mkdir fixes this.
Some of the package names are different.
Installing MariaDB has additional steps.
In addition, when installing Mempool, certain files need to be redirected to point to the right direction or use the right user.

While it runs systemd just like the Version 2 era Ubuntu servers, it boots incredibly fast. I believe it has something to do with how the full disk encryption was set up, because the Version 2 Ubuntu servers all boot much slower than the Version 3 Arch servers.

Another difference between the two Version eras is the encryption passphrase entry at startup. Ubuntu was far slower to process the entry, and would only allow one entry before forcing the user to shutdown and restart to attempt the unlock again. In contrast, the Version 3 Arch servers process entries very quickly and allow multiple attempts.

Fulcrum was also a massive success at speeding up the wallet lookups. Everything became near instant, especially on the local network, which I now was addicted to using. With the power of the VPNs, I could always use this fast connection to use my wallets and check on transactions using the Mempool explorer. Life’s good.

Fresh Install Bullet Points

Here’s how I would rebuild my Bitcoin node if I needed to:

Go to my personal GitHub and reference my guides on:
- Installing Arch Linux
- Security Hardening on Arch Linux

Thanks to those who got me here!

Stadicus again for his Raspibolt guide series
I learned how to install Arch (and Artix) Linux with assistance from:
- the Arch wiki
- this video guide by Luke Smith (YouTube link)

Helpful Videos

OpenVPN Server on a Raspberry Pi

Mon, 23 May 2022 22:46:08 -0400

This article was written in 2023, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Network Administration.

Introduction

For more information on how I would set up a VPN server today, check out my guide on creating a VPN server, found on my GitHub.

VPNs Done Right

Most people don’t understand VPNs. This is mostly due to effective marketing by companies selling VPN services. People believe VPNs are far more than they actually are. But, VPN still have utility, if applied correctly.

The one and only utility that a VPN provides is the ability to relocate the point where one’s local traffic becomes wider internet traffic. Put simply, VPN servers allows an individual to change their public IP address. Uses for this include remotely accessing private networks, such as a corporate or home network, or pretending to be somewhere else to get a different country’s streaming service catalog. For this purpose, a VPN service with access to servers in different countries may have use.

VPNs are claimed to be secure because of the encryption provided by the VPN tunnel. Because traffic leaves the client computer and transits over to the “external local network” using an encrypted tunnel, the client’s ISP no longer has “provider-level access” to the client data. But, that access doesn’t go away – the control is simply transferred over to the ISP of the VPN server. This is one big caveat to the marketing reads of the VPN service companies regarding security.

With this in mind, in the spring of 2022, I used another Raspberry Pi to deploy an OpenVPN server. I was deploying the server simply to gain remote access to my home network using an encrypted connection. Nothing more, nothing less.

The OpenVPN Pi server was awesome. It was one of my most stable server projects, achieving a >99% uptime for the 6 months that it ran. I tested it from across the world and I was always able to connect, no matter what. And, it was much faster than the hidden services I had been routing through the Tor onion network. The OpenVPN Raspberry Pi project was also the first to open my eyes to networking. While I had been communicating with my Bitcoin and camera servers over the local network and over Tor, being able to set up a Raspberry Pi to enable full network access from anywhere across the world, with minimal latency, was incredibly cool.

The Build

Version 1.0 - Raspberry Pi 4, 8GB (spring 2022)

Ubuntu Server 20.04 LTS (arm64)
- UFW
- fail2ban
OpenVPN

Regarding operating systems, it is worth noting that Ubuntu 22.04 LTS (Jammy Jellyfish) had already released by the time I started this project. However, due to issues of package dependencies and wanting different version, I was unable to get Ubuntu 22.04 working with the script I was using to install the OpenVPN server. I had to downgrade to Ubuntu 20.04 (Focal Fossa) in order to get everything working.

It is also worth noting that current Debian systems seems to work fine as well – it is only Ubuntu, and only versions 22.04 and above, that have the issues with the script.

Fresh Install Bullet Points

NB: The Raspberry Pi OpenVPN server was the first way I learned to set up a VPN server, but it is only one of many ways. From spinning up a Docker container or a Proxmox VM, to running the server on the cloud (with Linode, not AWS), to running the VPN server directly on a pfSense router, there are so many options to choose from. Building another Raspberry Pi VPN server would be driven almost entirely by circumstance.

Here’s how I would rebuild my VPN server if I needed to:

Go to my personal GitHub and reference my guide on:
- Installing OpenVPN server

Thanks to those who got me here!

Angristan for his script
Mental Outlaw for his video about creating an OpenVPN server (YouTube link)

Helpful Videos

Cameras using MotionEyeOS

Tue, 08 Mar 2022 22:35:03 -0500

This article was written in 2023, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Other Projects.

Open-source home camera system

The MotionEyeOS camera project was mostly a project of “what’s possible?” I took a couple of Raspberry Pi and deployed new software, turning them into a combination of a camera server and multiple wireless cameras. Being able to self-host software that was being sold commerically was really cool, because it meant that “my data” would stay “my data.”

This project also proved that self-hosting didn’t have to mean a loss of features – I had multiple cameras set up around the house, communicating wirelessly, live streaming video in decent quality, with the ability to do video capture when they sensed motion. This project was a demonstration that I didn’t have to trust some faceless corporation with my camera data, I could do it myself using free and open-source software (FOSS).

As I found out in 2023 when attempting to install MotionEyeOS into a Docker container, there are no images for MotionEyeOS that work on the x86 platform. Therefore, I was unable to test out the software again, as I did not have an interest in reinstalling the OS onto a Raspberry Pi.

The Build

Hardware stack:

Raspberry Pi 4, 8GB (server)
Raspberry Pi 4, 8GB (camera)
Raspberry Pi Zero W (camera)

I remember having one issue with the web UI related to adding cameras. I think the issue was not including http:// in front of the camera’s IP address.

The issue -was- not including “http://” in front of the camera IP addresses. Image from MotionEye GitHub.

Fresh Install Bullet Points

Here’s how I would rebuild my camera system if I needed to:

Follow the MotionEyeOS documentation to set up the server
Then, use the same documentation to set up the cameras

Thanks to those who got me here!

Tom from Lawrence Systems on Youtube for verification re adding cameras.

Helpful Videos

Bitcoin Node: Version 2

Sat, 18 Dec 2021 21:26:15 -0500

This article was written in 2023, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Bitcoin Nodes.

Introduction

This article describes an outdated way to build a Bitcoin node. For more information on how I would set up a Bitcoin node today, check out my guide on creating a Bitcoin node, found on my GitHub.

Going Down the Rabbit Hole of Headless Servers

My first home lab project was about to level up in a big way.

My first experience with a headless server was in the spring of 2021. I reinitialized my Raspberry Pi with Ubuntu Server and I forced myself to set up a node from scratch using only the command line. With some help and assistance and some guide videos, I made it happen. Skills I had just learned continued to develop:

software integrity checks using GPG
full disk encryption
networking through the Tor network
writing service files
connecting new software to other self-hosted services

I also gained some new skills and abilities. Those included learning how to SSH, in addition to learning how to SSH securely by securing sshd using public/private key pairs. I learned how to troubleshoot multiple Raspberry Pi servers and maintain maximum uptime and high availability. I also combined SSH with a previous skill, Tor networking, in order to expose a Tor hidden service so I could remotely administer a server without exposing my home IP address. It was slow, but it was private and it was encrypted. It was also really cool.

The high achievement of the Version 2 era was the end of 2021, when I upgraded the entire headless software stack to include the block indexer. Suddenly, my node was supercharged. It powered stronger wallet software and a more aesthetically pleasing (yet incredibly useful) web-based timechain explorer. It also had better security with a firewall and software to limit the potential for DDoS attacks by banning spam attacks. That’s pretty cool.

The best part was that, in just a year, I had managed to go from running my node on Windows 10 (LOL) to running my node on Linux, with just a command line. So freaking awesome.

This new node was so good that it basically ran uninterrupted from the end of 2021 until the end of 2022, when it was upgraded to the new Version 3.

An image of the home page of the web UI for the Mempool explorer, added to the Bitcoin node stack in Version 2.1. A public version of the website can be found at mempool.space.

The Build

Version 2.0 (spring 2021)

Ubuntu Server 20.04 LTS (arm64)
- Tor daemon
Bitcoin Core (daemon)
Specter Wallet (Server)
btc-rpc-explorer

Version 2.1 (winter 2021)

Ubuntu Server 22.04 LTS (arm64)
- UFW
- fail2ban
- nginx
- Tor daemon
Bitcoin Core (daemon)
Electrs (indexer)
Mempool (timechain explorer)
- MariaDB

To address a potential discrepancy, Version 2.1 ran Ubuntu 20.04 LTS until spring 2022, when Ubuntu 22.04 LTS was released. Since Version 2.1 ran 22.04 for the majority of its life, it is listed as such.

NB: Around this time, I also learned that Ubuntu Desktop can be made into Ubuntu Server by setting the systemd boot to be multi-user and not graphical. To go further, the desktop environment can be uninstalled, as well as the snap related packages and any other Ubuntu bloat.

Fresh Install Bullet Points

This version, and all of its subversions, have been retired in favor of a more recent version. Check this page for the most up-to-date version of the Bitcoin node stack.

Thanks to those who got me here!

Tj for his guide to “Full Disk Encryption on Ubuntu”
Stadicus for his Raspibolt guide series

Bitcoin Node: Version 1

Thu, 18 Feb 2021 21:26:15 -0500

This article was written in 2023, looking back at my previous home lab projects and where my journey into IT began.

This article is part of a series on Bitcoin Nodes.

Introduction

This article describes an outdated way to build a Bitcoin node. For more information on how I would set up a Bitcoin node today, check out my guide on creating a Bitcoin node, found on my GitHub.

My First Home Server

My first home lab project was a Bitcoin node.

This was back in the spring of 2020, during the coronavirus lockdown times. I knew nothing of building home labs at the time. I really knew nothing at all besides Windows, and a little bit of Mac OS. The first iteration of my Bitcoin node was nothing more than a Dell laptop running Windows 10 with Bitcoin Core GUI running on top of that. It was simple, and it allowed me to connect my Wasabi Wallet software to it. But, the more I learned about Bitcoin nodes, the more I understood that the next step was for me to harness the power of the command line. To do that, I would need to install Linux.

I ran Linux for the first time in the winter of 2020. I wasn’t ready for the full command line experience, so I installed Ubuntu Desktop onto a laptop and ran the Bitcoin Core GUI. On the surface, all I had done was import my Windows experience onto Linux. This was mostly true. My use with Linux was primarily graphical, which meant a lot of clicking through a GUI. But, I was beginning to gain a little experience with pulling up a terminal and entering some commands.

My next move was to free up the laptop and install my node onto a Raspberry Pi. At the start (January 2021), I continued to use Ubuntu Desktop, same as before. But, I started to train new skills such as:

doing software integrity checks using GPG
performing full disk encryption
networking services through the Tor network
writing service files to run software at startup
installing new software and connecting it to other self-hosted services

As I did, I also noticed how cumbersome my setup was. On the occassions that I wanted to check in on my server, I had to put together a complete monitor-keyboard-mouse setup that I would be putting away at the end of the check-in. In addition, I was also becoming painfully aware of how slow the Raspberry Pi was, because I demanded a graphical interface.

So, for Version 2, I decided to go completely headless. My server, that is.

An image of the dashboard of the web UI for the btc-rpc-explorer (Version 1.2 era). This is an image from the public version of the website, which can be accessed using this link.

The Build

Version 1.0 - Windows 10 (laptop; spring 2020)

Windows 10
- Tor daemon
Bitcoin Core (GUI)

Version 1.1 - Ubuntu Desktop (laptop; winter 2020)

Ubuntu Desktop 20.04 LTS (x86)
- Tor daemon
Bitcoin Core (GUI)
Specter Wallet (Server)
btc-rpc-explorer

Version 1.2 - Ubuntu Desktop (Raspberry Pi 4, 8GB; early 2021)

Ubuntu Desktop 20.04 LTS (arm64)
- Tor daemon
Bitcoin Core (GUI)
Specter Wallet (Server)
btc-rpc-explorer

Fresh Install Bullet Points

This version, and all of its subversions, have been retired in favor of a more recent version. Check this page for the most up-to-date version of the Bitcoin node stack.

Thanks to those who got me here!

This forum post for explaining how to do full disk encryption on a Raspberry Pi
Ketan & Ministry of Nodes for this YouTube playlist

David's Webpage

Getting Rusty

Introduction

Time to Get Rusty

Rustlings

The Book, and fibonacci

Conclusions

Getting Better at Bash

Introduction

My First Refactor

Indirect Variable Assignment

Conclusion

Python and TypeScript: Learning How to Code

Introduction

My First “Real Coding Language”

Getting a Handle on Python

Neovim: Now in Lua!

Introduction

“You Can Go Your Own Way”

Plugins

Telescope

Harpoon

LSP

I Use Vim, BTW

Helpful Videos

Debian DWM: Like LARBS, But Not Exactly

Introduction

My First Real Git Project

“We All Start Somewhere”

Improving My Work

Building a Library of Documentation

Introduction

Documenting my progress

The “Library” repository

Git: I "Git" It Now

Clowning Around on GitHub

Beginning to “Git” Good

Helpful Videos

Kinesis Keyboard: Typing Without Pain

A Better Way to Type

The Benefits of Using a Kinesis Keyboard

Helpful Videos

Learning Data Structures and Algorithms with thePrimeagen

Introduction

Deciding to Learn Some Programming

Taking the Course

The Aftermath

Video Preview of the Course

HackTheBox: Learning Penetration Testing

Hacking the Box (ethically, of course)

Pwning HackTheBox

Helpful Videos

NixOS: Declarative Configuration Systems

Running NixOS

Beginning to Appreciate Git

The Inception of DWM Install Scripts

Troubleshooting NixOS

Fresh Install - Tips and Tricks

Helpful Videos

Nextcloud Cloud Storage, in a Docker container

A Personal, Secure, Open-Source Cloud Storage Suite

Helpful Videos

Web Pages and Mail Servers

Introduction

My first web page

Fresh Install - Tips and Tricks

Helpful Videos

Hugo: A Static Site Generator

Creating Websites

Fresh Install - Tips and Tricks

Helpful Videos

OpenVPN Server Using Amazon Web Services

Introduction

Welcome to the Jungle

The Build

Software stack:

Fresh Install Bullet Points

Docker Containers on Arch Linux VM

Everybody Loves Docker

The Build

The Book, and `fibonacci`