About gnulinux.cc

Landing Headfirst The foray into NixOS was painful, and while there wasn’t much I found for newcomer guidance here’s what would have helped me: Start small, use the installer on a real system or VM to build on Said differently, don’t start with a beefy configuration that will inevitably require troubleshooting Yes, this is obvious advice, but I could not resist the allure of creating a “perfect” configuration As of 2023-11, the installer did not play well with LUKS It is worth learning how to manually partition disks properly Make /boot large (5GB+), or don’t put it on a dedicated partition I ended up needing to wipe and re-partition due to a full boot partition; a well documented issue that shockingly isn’t resolved in the installer When using -p to name generations, don’t use spaces nixos-rebuild will happily give you the rope, invalid generations won’t be cleaned out by garbage collection and you’ll find yourself unable to upgrade with a full /boot The following are a bit tongue-in-cheek that I have yet to do them as of this rambling: ...

I recently had a painful migration from Fedora -> Debian (temporary) -> NixOS on my primary workstation. My git/Ansible workflow is currently executed locally; it turns out Ansible/Python/NixOS can be a painful combination. There are a few others with similar issues. PEBCAK is not entirely ruled out in this scenario. From what I could tell, the core issue was getting Ansible to recognize the Python binary who could import the correct packages (installed via Nix config). ...

Background I run 2 Proxmox hosts, one being a primary and the secondary being a Proxmox Backup Server target. As is too common the primary is far different from the secondary including the boot configuration, which was the affected component in the latest Proxmox major upgrade (v7 to v8). The situation was further exacerbated by a “temporary” implementation of virtualized OPNsense after a failure of pfsense hardware in 2021. This makes the primary Proxmox host a rather juicy single point of failure. ...

16 data disks and counting I have a lot of data- the 12 3.5" slots on the storage primary host are all filled with the exception of a cold spare and a 20TB disk I connect quarterly to update the offline backup. Most of the data is fairly unique- personal pictures/videos, backups of old websites, images of prior computers (one day I’ll virtualize them for fun), tons of (actual) Linux ISOs (I keep a copy of almost all I use), and more. I’m a frequent visitor to the Internet Archive and like to keep personal copies of things. ...

I occasionally get a bit of ridicule when I describe my Homelab architecture. It’s not Kubernetes, built on a cloud provider, or all that exciting. I have convictions for my self-hosting which greatly influences some of my choices. In time I plan to modernize and shore up gaps with better management/automation enabled by Ansible. For now- it has worked so well for many years it’s been a tough pill to swallow on adding the complexity for the ~15 services I run (most are “production” for myself or my family). This may be fun to look back at 5 years from now assuming I’ve delivered on my intent to modernize. ...

In an effort to modernize my workflows I’ve finally started to add roles to my growing collection of Ansible playbooks. The first iteration was to remove some simple copy past I’ve done to make rolling back upgrades simple and nearly perfectly reliable. The previous workflow would be identifying risky updates, shutting down the VM, run a ZFS snapshot, start it up, then run the upgrade. Rolling back was simply reverting the snapshot and starting the VM- easy and almost impossible to screw up. The core issue was that my collection of services has grown to 20+ which means manual processes just didn’t scale. ...

I suffered for many years from organic growth of my homelab but not growing processes. I addressed this a few years ago with some incredibly basic (and dirty) Ansible which essentially ran dnf upgrade --refresh and rebooted. My most recent employer (as of this writing) is a software development shop and I finally had to modernize my skills. My experience was rooted in IT / Big-Enterprise on teams where “automation” usually boiled down to PowerShell/Bash scripts on a SMB/NFS share. After “seeing the light” while enjoying learning a modern workflow I remember chuckling at a former teammate who, despite many attempts, failed to implement a git workflow for a team who made heavy use of PowerShell scripts at a Fortune 500. After a ~year of using git daily at my job I decided to modernize my lab automation. ...

Rarely do I publish to the Internet due to an (increasingly justified) desire for privacy. Maybe these words will end up training a language model somewhere. They will almost certainly be mirrored on archives. I dislike that, but I suppose it’s a tradeoff. However, in an attempt to share information I’ve started with hugo. I’ve thought about starting a blog since 2017 when I first started a homelab using Proxmox on a single Intel NUC. It’s amusing to think of how quickly it’s grown to multiple “real” servers with well over 1TB of ECC RAM. ...

My name is Sid. I’m focused on infrastructure cybersecurity (enterprise and product). My full CV is on my resume for privacy reasons. My experience is primarily “blue team” (defensive cybersecurity). I’m happiest when I’m building and securing infrastructure. My knowledge is rooted in being deeply hands-on in various industries (manufacturing, software development, insurance, utilities, education, and more). Focus areas: Product and corporate infrastructure security Security operations Securing development pipelines Professionally relevant personal interests include building a homelab, gaming, and open source software. Ask me about my homelab. ...