In my previous post, I created a systemd unit file to define an application as a service, and configured it to auto-start on my server. I’ve been making a big push to define the provisioning of all my homelab machines/VMs using automation. So the last step in setting up my FoundryVTT server, is to automate the process. Fortunately, creating a systemd unit file is quite easy to do using ansible.
Recently, I’ve been hosting a Foundry VTT server (a
nodejs app) in a virtual machine on my home network. I would start the
application inside a
tmux session, by
executing a CLI command which worked… fine. However, if the VM restarted or
the applications crashed, I had to ssh in and manually run the command again. So,
to better automate this tedious task, I created a unit file to
define the foundry server as a systemd service. Here’s how.
Gnome is the default desktop environment for many Linux distributions, including my distro of choice, Fedora. When Gnome 3 was first released, I had to install a bunch of extensions to get a functional experience. These days, between becoming more familar with the Gnome workflow, and the Gnome team ironing out the rougher edges of the DE, I don’t need nearly as many extensions to get going. However, there are still three which I do not think I could live without.
Over the past year or two, my notes and planning systems have been a bit of a jumble. It started when I attempted to switch everything to joplin notes… only to eventually switch back to org-mode (for my work notes) a few months later. Around that same time, I also started using trello to organize my personal and home life task boards. This system has worked well, but feels very disjointed. My notes, goals, and tasks are spread all over the place. This might all be about to change. I’ve started using Notion.
While writing my previous post, I hit a frustrating issue. After saving a large chunk of the draft, it appeared that hugo wasn’t rendering the new additions. I verified on several computers, including fresh installs. None of them would generate the updated post, despite the source files containing the changes. Ugh.
Earlier this year, I noticed that my desktop seemingly did not connect to my
monitor. I used the computer mostly as a server, remoting in via
didn’t think much of it. I assumed it was either a mis-plugged cable or a
configuration issue. A few months later, I started to game a bit more and
wanted to use my desktop as a gaming machine again. That is when I realized…
it was an actual issue. Long story short, my desktop now has an rx580 instead
of it’s old rx560.
A month ago, I drafted a progression of examples with notes, to teach a co-worker the basics of writing and using ansible roles and playbooks. After reading through them, I realized it wouldn’t take much to turn them into an actual Ansible quickstart post. So here we are.
Several weeks ago I attend TSQA 2020, a conference presented every two years by the Triangle Software Quality Association (TSQA). Despite being hosted by my local software testing group, the speakers and attendees were from all over the country. While only a single-day conference, it was packed full with solid advice and ideas I left with. Here are a few.
Okay, quick post! Previously, I wrote about how I automated my website
tests using Jenkins. When I wrote that post,
I had the tests run on
any node. I wanted to have the tests
run inside a fedora docker container, but ran into issues configuring it.
With the problem now long fixed, I decided I would write a quick update post about
switching the pipeline to use container nodes.
In my previous two posts, I created a test framework for my website, and automated it using Jenkins. But we can do better. One of the most annoying things when maintaining (or even reading) something on the internet, are broken links. While I cannot control the availability of content outside the website, I can choose to remove links if they are broken. So, in this post, we will add tests to ensure that links in our posts are working. Well, at least the markdown ones.