That’s how SeanTechGuy came about. It’s simpler, it’s personal, and it’s a much better fit for what this site actually is at this point: a place where I write about the stuff I’m learning and working on, not a storefront.

What actually had to change

Making the switch wasn’t just a matter of updating a logo or renaming a folder. The site itself has lived on GitHub Pages for a long time, with a custom domain sitting in front of it, DNS managed through Cloudflare, and the domain registered through Namecheap. All of those pieces needed to be touched in some way to move the public facing identity from techsnazzy.com over to seantechguy.com without losing anything in the process.

At a high level, this meant getting the new domain pointed at the same GitHub Pages hosting the old one used, updating the hosting configuration to recognize the new domain as the official one, and making sure a valid certificate was issued so the site would still load securely under the new name. None of that touches the site’s content or code, it’s purely about which address the site answers to.

The other half of the work was making sure the old domain didn’t just go dark. Anyone who still has techsnazzy.com bookmarked, linked, or indexed in a search engine gets automatically forwarded over to the matching page on seantechguy.com rather than hitting a dead link. That redirect setup lives entirely in DNS and routing rules, so it happens quietly in the background without anyone needing to do anything differently.

One thing I was careful about the whole way through: my email address tied to the old domain didn’t change and wasn’t touched at any point during this. Moving a website’s DNS around can get messy if you’re not paying attention to what else is sitting in that same DNS zone, so this was as much about knowing what not to touch as it was about making the actual changes.

Where things stand now

seantechguy.com is live and is now the site’s real home. techsnazzy.com still works exactly the same as before, it just quietly redirects anyone who lands there over to the new domain. Nothing about the content changed, just the name on the front door, and honestly it feels like a better fit for where I’m at now than TechSnazzy ever did.

A quick note on how this was written

Yes, I used Claude to write this post. Don’t judge me too hard for it. The idea, the outline, and every bit of the actual work described above came entirely from me, Claude just helped turn it into something readable. That’s basically how I use it these days: I do the thinking and the doing, then it takes my rough notes and turns them into a polished writeup faster and better than I’d get around to doing myself. I’m alright with that division of labor.

The machine

Nothing fancy, gaming-style computer:

• Fedora 44 Workstation (kernel 7.1.5-201.fc44.x86_64)
• NVIDIA GeForce RTX 3060, running the proprietary driver, not nouveau
• GNOME on Wayland
• An LG 34” ultrawide monitor (3440x1440, 21:9) as the main display
• zsh with Oh My Zsh as the shell setup

Why leave ZorinOS

ZorinOS had been fine for a long time, but the real reason for the move is that I’ve decided to pursue Red Hat certifications to get better with enterprise Linux. I recognize Ubuntu is probably the more well known and popular distro among end users in this space, but my focus going forward is on the server side of things, not the desktop side, and that points toward Red Hat’s ecosystem instead. Fedora is the closest thing to RHEL without actually being RHEL, so reverting back to it now gets me working in that world day to day. I’ll also be spending time directly in RHEL as I go through this process. Fedora’s relationship with NVIDIA hardware isn’t perfect, but it’s well documented, and RPM Fusion makes the proprietary driver a known quantity rather than a guessing game. So the plan was: back everything up, wipe the drive, install Fedora 44 clean, then pull the important stuff back in.

Step 1: backing up ZorinOS with rsync

Before touching partitions, I backed up the ZorinOS install to an external USB drive using rsync rather than a disk image. The reasoning was simple: I didn’t need a bit-for-bit clone of a system I was about to replace, I needed the data and configuration that actually mattered, in a form I could selectively restore from later.

The backup covered two things specifically: /etc (system configuration) and my home directory, organized into its own folder on the drive rather than dumped as a raw /home/sean. On the USB drive those ended up as two top level folders, something like:

/run/media/sean/BACKUPDISK/etc
/run/media/sean/BACKUPDISK/home-organized

One detail worth remembering here, because it trips people up: on Fedora (and most modern distros), removable drives mount under /run/media/<username>/<label>, not /run/media/<label>. The username is always in the path. I’ve lost a few minutes to this exact mistake more than once.

The actual copy used rsync with archive mode plus flags to preserve hard links, ACLs, and extended attributes, since this was a full system backup and I wanted permissions and ownership to survive the trip:

sudo rsync -aHAX --info=progress2 /etc /run/media/sean/BACKUPDISK/
sudo rsync -aHAX --info=progress2 /home/sean/ /run/media/sean/BACKUPDISK/home-organized/

-a is archive mode (recursive, preserves permissions, timestamps, symlinks). -H preserves hard links. -A preserves ACLs. -X preserves extended attributes, which on a SELinux system includes the security.selinux context on every file. That last flag turned out to matter a lot later, but not during the backup itself, only when I tried to restore.

Step 2: installing Fedora 44 Workstation

The install itself was the boring part, which is exactly what you want from an OS installer. Standard Fedora 44 Workstation image, wiped the target drive, default partitioning, GNOME desktop, done. No dual boot, no manual partition surgery, no drama. The interesting work started after first boot.

Step 3: restoring files with rsync

With Fedora up and running, I plugged the USB drive back in and started pulling files back off it, one folder at a time rather than all at once, so I could actually watch what was happening instead of trusting a single giant transfer.

First attempt, copying etc back over, used the same flags as the original backup:

sudo rsync -aHAX --info=progress2 /run/media/sean/BACKUPDISK/etc /home/sean/Downloads/

This failed partway through with:

rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1356) [sender=3.4.4]

Code 23 from rsync is intentionally vague, it just means “something didn’t transfer, check the log,” so I reran it with plain verbose output redirected to a file instead of the live progress bar (--info=progress2 constantly rewrites one line, which turns into garbage once you redirect it to a file):

sudo rsync -aHAX -v /run/media/sean/BACKUPDISK/etc /home/sean/Downloads/ \
  > /home/sean/Claude/rsync-etc-log.txt 2>&1

The log came out at 472KB, too big to read start to finish, so I grepped it for anything that looked like an actual failure rather than scrolling:

grep -iE "error|denied|failed|cannot|no such|refused|rsync:" rsync-etc-log.txt \
  | sort | uniq -c | sort -rn | head -60

Every single hit was the same line, just with a different filename:

rsync: [receiver] rsync_xal_set: lremovexattr("/home/sean/Downloads/etc/...","security.selinux") failed: Permission denied (13)

That’s the -X flag again. It tries to preserve the security.selinux extended attribute on every file, and SELinux blocks writes to that specific xattr unless the process holds a MAC-admin privilege that plain sudo doesn’t grant. This isn’t a bug in these specific folders, it will happen on any full-tree rsync with -X under enforcing SELinux on Fedora. Root doesn’t automatically mean “can set arbitrary SELinux contexts.”

The fix was to just drop -X for this copy. I wasn’t restoring these files into their original system locations where matching SELinux contexts would matter, I was pulling them into ~/Downloads for reference, where they’d get Fedora’s normal default context regardless:

# etc
sudo rsync -aH -v /run/media/sean/BACKUPDISK/etc /home/sean/Downloads/ \
  > /home/sean/Claude/rsync-etc-log.txt 2>&1

# home-organized
sudo rsync -aH --info=progress2 /run/media/sean/BACKUPDISK/home-organized /home/sean/Downloads/

-aH still keeps permissions, ownership, timestamps, symlinks, and hard links, it just stops fighting SELinux over extended attributes. Both copies finished cleanly after that.

One side effect of running the copy under sudo: everything under ~/Downloads/etc ended up owned by root:root. Nautilus shows a little padlock icon on folders like that, which looks alarming but just means my regular account has read and execute access without write access, not that anything’s broken. Fixed with a straightforward chown once the copy was done:

sudo chown -R sean:sean /home/sean/Downloads/etc
sudo chown -R sean:sean /home/sean/Downloads/home-organized

From there I went through home-organized by hand and moved the pieces I actually wanted (dotfiles, project folders, SSH keys, that kind of thing) back into their real locations in /home/sean, rather than restoring the whole tree wholesale. Old home directories accumulate a lot of things you don’t actually want to carry forward, and a fresh install is a good excuse to leave the rest behind.

Step 4: getting the NVIDIA driver working

Fedora ships with the open source nouveau driver by default, and nouveau will get a desktop on screen, but it won’t give you CUDA or full hardware accelerated OpenGL on an RTX card. Getting the proprietary driver installed and confirmed working went smoothly, though it helps to understand what “installed” versus “actually active” means on Fedora.

First, RPM Fusion’s nonfree repo needs to be enabled, since that’s what provides akmod-nvidia. With that in place:

sudo dnf install -y akmod-nvidia xorg-x11-drv-nvidia-cuda

akmod-nvidia doesn’t ship a prebuilt kernel module, it builds one against whatever kernel you’re currently running, in the background, via the akmods service. That build can take a few minutes, and if you reboot before it finishes, you’re back on nouveau with no explanation why. So the thing to check before rebooting is whether the module actually built for your running kernel:

rpm -qa | grep nvidia
modinfo nvidia

modinfo nvidia should point at a .ko or .ko.xz file living under /lib/modules/$(uname -r)/. If kmod-nvidia-$(uname -r)-... isn’t listed yet in the rpm query, the build just hasn’t finished, wait and check again rather than assuming something’s wrong.

The other piece that has to be in place is a nouveau blacklist on the kernel command line. The driver package’s install script usually adds this automatically to /etc/default/grub:

GRUB_CMDLINE_LINUX="... rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core"

but /etc/default/grub is only a template. What the bootloader actually reads at boot time is the BLS entry under /boot/loader/entries/*.conf, and editing the template alone doesn’t do anything until that’s regenerated, or until you push the args in directly with grubby:

sudo grubby --update-kernel=ALL --args="rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core"

After a reboot (sudo systemctl reboot), I ran through a short checklist to confirm the proprietary driver was actually the one in use, not just installed alongside nouveau:

cat /proc/cmdline                     # should show modprobe.blacklist=nouveau,nova_core
lsmod | grep -E "nvidia|nouveau"      # nvidia present, nouveau absent
nvidia-smi                            # should report the GPU
lspci -k | grep -A3 VGA               # "Kernel driver in use: nvidia"
glxinfo | grep "OpenGL renderer"      # NVIDIA renderer, not Mesa/zink/NVK

All of that came back clean:

$ nvidia-smi --query-gpu=driver_version,name --format=csv
driver_version, name
610.43.03, NVIDIA GeForce RTX 3060

Worth noting: dracut is set up (via /usr/lib/dracut/dracut.conf.d/99-nvidia-dracut.conf) to deliberately leave the nvidia modules out of the initramfs. That’s expected behavior, not a misconfiguration, the driver loads from userspace later in the boot process. No initramfs rebuild needed.

Step 5: an unrelated monitor bug

Not part of the migration exactly, but it happened in the same window of getting the machine dialed in, so it’s going in this write-up. My external LG 34” ultrawide monitor (3440x1440 native, 21:9) looked stretched no matter what resolution I picked in Settings. Turned out GNOME/Mutter was driving it at 1920x1080, a 16:9 resolution, and since the panel doesn’t letterbox a mismatched aspect ratio, it just stretched the image horizontally to fill the full 21:9 width. Any 16:9 resolution produced the same stretch, which is why it looked like nothing I picked fixed it.

The monitor’s EDID reports 4096x2160@24Hz as its “preferred” mode and calls itself LG SMART WQHD, both of which are red herrings for what’s actually a 34” ultrawide panel. I confirmed the real state with Mutter’s D-Bus interface directly:

gdbus call --session --dest org.gnome.Mutter.DisplayConfig \
  --object-path /org/gnome/Mutter/DisplayConfig \
  --method org.gnome.Mutter.DisplayConfig.GetCurrentState

and set it to the correct native mode with 1.25x scaling (3440x1440 at 1.0x is uncomfortably small to read):

gdbus call --session --dest org.gnome.Mutter.DisplayConfig \
  --object-path /org/gnome/Mutter/DisplayConfig \
  --method org.gnome.Mutter.DisplayConfig.ApplyMonitorsConfig \
  1 2 \
  "[(0, 0, 1.25, uint32 0, true, [('HDMI-2', '3440x1440@49.987', @a{sv} {})])]" \
  "{}"

The 2 at the start selects persistent mode, which writes the result to ~/.config/monitors.xml so it survives logout and reboot rather than only applying to the live session.

Step 6: setting up zsh and Oh My Zsh

Bash is fine, but I’ve used zsh with Oh My Zsh for years and a fresh install isn’t a good enough reason to switch. Installing it was routine:

sudo dnf install -y zsh
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
chsh -s $(which zsh)

That drops a default ~/.zshrc and an ~/.oh-my-zsh directory with custom/plugins and custom/themes folders for anything not bundled with the core install. From there it was a matter of rebuilding my actual config rather than living with the defaults.

Theme and plugins

I use the built in gentoo theme rather than the Oh My Zsh default, and only two plugins: git (for branch/status info in the prompt) and zsh-autosuggestions, which isn’t bundled and has to be cloned in manually:

git clone https://github.com/zsh-users/zsh-autosuggestions \
  ~/.oh-my-zsh/custom/plugins/zsh-autosuggestions

Once it’s sitting in custom/plugins/, Oh My Zsh picks it up automatically as long as it’s listed in the plugins array in .zshrc:

export ZSH="$HOME/.oh-my-zsh"
ZSH_THEME="gentoo"

plugins=(
  git
  zsh-autosuggestions
)

source $ZSH/oh-my-zsh.sh

A custom prompt on top of the theme

The gentoo theme’s default prompt is fine, but I override the git prompt segment colors and the whole PS1 to get a specific look, blues and purples for the username, host, and current directory, with git status folded in wherever there’s a repo:

ZSH_THEME_GIT_PROMPT_PREFIX="%{$(tput setaf 117)%}("
ZSH_THEME_GIT_PROMPT_SUFFIX="%{$(tput setaf 117)%}) "
ZSH_THEME_GIT_PROMPT_DIRTY="%{$(tput setaf 210)%}*"
ZSH_THEME_GIT_PROMPT_CLEAN=""

export PS1="%{$(tput setaf 39)%}%n%{$(tput setaf 45)%}@%{$(tput setaf 51)%}%m %{$(tput setaf 195)%}%1~ \$(git_prompt_info)%{$(tput sgr0)%}$ "

tput setaf <n> picks a 256 color palette entry rather than hardcoding raw ANSI codes, which makes each color easy to swap without decoding escape sequences by hand. git_prompt_info is a function Oh My Zsh’s git plugin provides, and calling it inside PS1 means the prompt only shows a git segment when the current directory is actually inside a repo.

Recoloring the whole terminal when connecting over SSH

This is the part of my config I like most. When I SSH into this machine from somewhere else on the network, say from another box at 10.0.0.x, I want the terminal to visually announce “you are on a remote connection” so I don’t accidentally run something destructive on the wrong machine while on autopilot. .zshrc checks for $SSH_CONNECTION, which zsh sets automatically for any shell started over SSH, and if it’s present, repaints the entire terminal color palette to a warm red/orange scheme using OSC escape sequences:

if [[ -n "$SSH_CONNECTION" ]]; then
  # Push hot (red/orange/yellow) colors to the remote terminal via OSC sequences
  printf '\e]11;#120800\e\\'   # background
  printf '\e]10;#ffcc88\e\\'   # foreground
  printf '\e]12;#ff6600\e\\'   # cursor
  printf '\e]4;0;#1a0800\e\\'  # black
  printf '\e]4;1;#ff3300\e\\'  # red
  printf '\e]4;2;#ff8800\e\\'  # green -> orange
  # ...and so on through all 16 palette slots

  ZSH_THEME_GIT_PROMPT_PREFIX="%{$(tput setaf 216)%}("
  ZSH_THEME_GIT_PROMPT_SUFFIX="%{$(tput setaf 216)%}) "
  ZSH_THEME_GIT_PROMPT_DIRTY="%{$(tput setaf 196)%}*"
  export PS1="%{$(tput setaf 196)%}%n%{$(tput setaf 202)%}@%{$(tput setaf 208)%}%m %{$(tput setaf 220)%}%1~ \$(git_prompt_info)%{$(tput sgr0)%}$ "
fi

\e]11;...\e\\ and \e]10;...\e\\ are OSC 10/11, which set the terminal’s default foreground and background colors directly, and \e]4;N;...\e\\ is OSC 4, which remaps palette slot N to a specific hex color. Any terminal emulator that supports these OSC sequences (most modern ones do) will pick this up the moment the shell prints it, no terminal side configuration required. The practical effect: local sessions on this desktop stay in cool blues, and the instant I’m working inside an SSH session on this box from somewhere else, everything shifts to warm orange, at a glance, no reading required.

Aliases

A handful of aliases round out the config. Nothing fancy, mostly shortcuts for things I do often enough that typing them out fully got annoying:

alias ll="ls -lah"

alias vm='qemu-system-x86_64 -m 1024 -cpu pentium3 -hda /home/sean/VMs/winxp/winxp.qcow2 \
  -boot c -vga std -usb -device usb-tablet -netdev user,id=n1 -device rtl8139,netdev=n1 \
  -rtc base=localtime -display gtk,zoom-to-fit=on'

vm boots a small Windows XP virtual machine I keep around under QEMU, useful for the odd case where something only runs on ancient Windows. The -cpu pentium3 and low memory allocation match what XP actually expects rather than throwing modern CPU features and RAM at an OS from 2001 that doesn’t know what to do with either.

Step 7: keeping backups going forward

Now that the machine is set up the way I want, I added an alias for ongoing backups to an external drive, rather than only backing up once during the migration and never again:

alias backup='mountpoint -q /media/sean/BACKUP && \
  rsync -aHAX --delete --info=progress2 /home/sean/ /media/sean/BACKUP/ || \
  echo "backup: /media/sean/BACKUP is not mounted, plug in the BACKUP drive first" >&2'

mountpoint -q checks first whether the drive is actually plugged in and mounted before doing anything, so a stray backup command with no drive attached fails with a clear message instead of either erroring out confusingly or, worse, silently doing nothing. --delete keeps the backup a mirror of the current home directory rather than an ever growing archive of files I’ve since removed. This time I kept -X in the flags, since this backup does need to preserve SELinux contexts, unlike the one time copy into ~/Downloads for reference.

Where things stand now

The desktop is fully on Fedora 44, running the proprietary NVIDIA driver with CUDA and hardware accelerated OpenGL confirmed working, the ultrawide monitor is displaying at its correct native resolution, and the shell feels like the same one I’ve been using for years, cool blue prompt locally, warm orange the moment I’m in over SSH. The whole migration came down to three tools doing almost all the real work: rsync for moving data both directions, dnf and RPM Fusion for getting the right driver installed, and a D-Bus call to Mutter for a display bug that had nothing to do with the migration but needed fixing anyway.

The main lesson worth carrying forward: when an rsync copy fails partway through with a vague error code, don’t guess, redirect verbose output to a log file and grep it for the actual error lines. The real cause is usually one specific line repeated hundreds of times, not hundreds of different problems.

FleetDM is an open source device management platform. It handles endpoint visibility, osquery based reporting, and MDM style management for macOS, Windows, Linux, iOS, iPadOS, and a few other platforms. It’s exactly the kind of tool I wanted for this project, something open source that I control instead of a SaaS product I’m renting.

Once I decided to do it, the plan was straightforward: spin up an Ubuntu server on my Proxmox host in my homelab and self host Fleet on it. This post covers standing up Fleet itself. Enrolling all my devices, two MacBooks, some iPads, iPhones, a Windows laptop, and a handful of other things, is its own project I’ll cover separately.

The plan

My Proxmox host is a small home server. Fleet needs Docker, and I wanted it isolated from everything else already running on that box, so the plan was to give it its own dedicated Ubuntu server VM rather than tucking it into an existing container. That VM is the only thing this post is about: getting a clean, dedicated place for Fleet to live so it can start managing the rest of my devices.

Creating the VM

Fleet’s own deployment guide walks through creating a VM and running through the Ubuntu Server installer manually. Since I wanted this to be repeatable and scriptable, I used the Ubuntu 24.04 cloud image with cloud-init instead of the interactive ISO installer. Same end result, an Ubuntu 24.04 VM, just no clicking through installer screens.

First I grabbed the cloud image:

curl -L -O https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img

Proxmox’s ability to pull large files directly from certain CDNs has been flaky for me in the past, so I downloaded it locally and copied it over with scp:

scp noble-server-cloudimg-amd64.img root@10.0.0.20:/var/lib/vz/template/cache/

Then, on the Proxmox host itself, I created the VM and attached the cloud image as its disk:

qm create 106 --name fleet --memory 4096 --cores 2 --cpu host \
  --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --ostype l26 --agent enabled=1

qm importdisk 106 /var/lib/vz/template/cache/noble-server-cloudimg-amd64.img local-lvm

qm set 106 --scsi0 local-lvm:vm-106-disk-0
qm set 106 --ide2 local-lvm:cloudinit
qm set 106 --boot order=scsi0
qm set 106 --serial0 socket --vga serial0
qm resize 106 scsi0 20G

The cloud image ships with a small disk, so the qm resize call is what actually gets me to the 20GB Fleet’s guide calls for as a minimum.

Next, cloud-init configuration for networking and access:

qm set 106 --ipconfig0 ip=10.0.0.90/24,gw=10.0.0.1
qm set 106 --nameserver 1.1.1.1
qm set 106 --ciuser ubuntu
qm set 106 --sshkeys ~/.ssh/id_ed25519.pub

And then start it up:

qm start 106

A minute or two later I had a fully booted Ubuntu 24.04 VM at 10.0.0.90, reachable over SSH with my key already in place. No installer screens, no console interaction needed.

Installing Docker

Fleet runs as a set of containers managed with Docker Compose, so the VM needs Docker installed. I followed Docker’s official install steps for Ubuntu rather than whatever version happens to be in Ubuntu’s default repos:

sudo apt update
sudo apt install -y ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Then add Docker’s repo to apt sources:

. /etc/os-release
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: ${UBUNTU_CODENAME:-$VERSION_CODENAME}
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

And install:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

I verified everything was working with the standard hello-world test:

sudo docker run hello-world

Got the expected “Hello from Docker!” message, so it was time to actually deploy Fleet.

Deploying Fleet with Docker Compose

Fleet publishes an official Docker Compose file and a sample environment file, so I made a directory for the deployment and pulled both down:

sudo mkdir -p /opt/fleet-deployment
cd /opt/fleet-deployment

sudo curl -O https://raw.githubusercontent.com/fleetdm/fleet/refs/heads/main/docs/solutions/docker-compose/docker-compose.yml
sudo curl -O https://raw.githubusercontent.com/fleetdm/fleet/refs/heads/main/docs/solutions/docker-compose/env.example

sudo cp env.example .env

The .env file needs a few values filled in before Fleet will actually come up: a MySQL root password, a password for Fleet’s database user, and a private key Fleet uses internally. I generated all three with openssl rather than typing something out by hand:

openssl rand -base64 24
openssl rand -base64 24
openssl rand -base64 32

Then dropped those into .env in place of MYSQL_ROOT_PASSWORD, MYSQL_PASSWORD, and FLEET_SERVER_PRIVATE_KEY.

Certificates

Fleet needs a TLS certificate, since clients talk to it over HTTPS on port 1337. For a home lab setup a self-signed cert is fine. The important part is getting the subjectAltName right, since modern TLS validation ignores the old CN field and only checks SANs.

sudo mkdir certs

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout certs/fleet.key \
  -out certs/fleet.crt \
  -subj "/CN=fleet.local" \
  -addext "subjectAltName=DNS:localhost,DNS:fleet.local,DNS:fleet,IP:127.0.0.1,IP:10.0.0.90"

The Fleet container runs as a non-root user internally, uid 100 and gid 101, so the cert and key need to be owned accordingly or the container won’t be able to read them:

sudo chown 100:101 certs/fleet.*

Bringing it up

With the environment file and certs in place, starting Fleet was just:

sudo docker compose up -d

Docker pulled the Fleet, MySQL, and Redis images and started all three containers. I checked status with:

sudo docker compose ps

Once MySQL and Redis showed healthy and the Fleet container passed its own health check, I hit https://10.0.0.90:1337 in a browser. Since it’s a self-signed cert, the browser throws up a warning first, which is expected and fine to click through for a home network. That drops you into Fleet’s first-run setup wizard, where you create an admin account, name your organization, and set the Fleet server URL that clients will use.

I named my org TechSnazzy, which is the name I’ve used for my personal IT projects for years now.

Zero hosts enrolled, which is exactly where things should be at this point. Fleet is live, reachable, and waiting for devices.

What’s next

Fleet is deployed and healthy on its own VM. The real work is still ahead of me: actually enrolling every device in the house into Fleet. Two MacBooks, a few iPads, a couple of iPhones, a Windows laptop, and a handful of other odds and ends. Each platform enrolls a little differently, so that’s going to be its own post, one that gets into the weeds on MDM profiles, osquery agent installs, and whatever headaches come up along the way.

Have you ever landed an opportunity that felt like everything you’d been working toward finally lined up?

I just wrapped up a contract I’m really proud of. It was a rare opportunity, and I’m grateful to have been part of getting things off the ground.

The team at Averro first contacted me and then E360 took a chance on me, and I was brought in as an IT Engineer to help a large, well-known retailer build out a modern device enrollment system from scratch. It was a greenfield project, the kind of work that sets the foundation for how employees will eventually get their hands on a device and get to work.

The technical side was challenging and rewarding, and I threw everything I had at it. Every bit of experience I’ve accumulated over the years rolled into one project. The result wasn’t fully finished (is it ever?), but it was something I’m proud of. And as meaningful as the work was, what I’ll remember most is the people. The level of talent and professionalism I encountered is something I won’t forget.

I’m grateful for this one, and excited to see where this kind of work takes me next.

For the past few weeks I’ve been experimenting with running my own local AI agent instead of relying on cloud APIs. This week I finally got OpenClaw working on a small Beelink mini PC, and it feels like an important milestone.

The system is running Ubuntu LTS 24.04, fully updated, and isolated on its own wireless guest network completely separate from my primary LAN. I hardened it further by binding services to localhost, restricting network exposure, limiting filesystem access to a controlled workspace, and running the agent inside a sandboxed container. The goal is simple: strong isolation, minimal attack surface, and full local control.

What makes this setup different is that it’s not using OpenAI, Anthropic, or Gemini APIs. It’s running entirely local using Ollama with the qwen2.5:3b model. This is a relatively small model, so it’s not as capable as larger cloud-hosted models accessed via API tokens. But it’s completely free to experiment with, which was the primary goal. For business or enterprise use, you could run larger models on more capable hardware or integrate API access to significantly increase capability.

Right now I can send it a DM in Discord and it responds directly from my own hardware. More importantly, there’s a key difference between a normal chat interface and an agent platform like OpenClaw. A typical LLM chat responds only when you manually ask it something. OpenClaw provides a framework where the model can be connected to tools, inputs, and conditions, enabling automation and workflows beyond simple questions and answers.

It took longer than expected to get everything working, mostly because my budget and resources are limited. I’m working with a small Beelink mini PC and essentially zero budget. If I had enterprise hardware or significant funding behind it, the setup and capabilities would be very different. But part of the value here is proving what’s possible with minimal resources and fully open tooling.

Now that it’s up and running, the focus shifts to exploring what it can actually do and whether there is practical value in running an isolated, local AI agent like this.

Have you ever thought about switching to Linux?

I started with Windows 3.11 in the early 1990s and have used every major version since, including Windows 11 most recently. Along the way I also became proficient with macOS, UNIX, and Linux. But my introduction to Linux was not as a hobby. It came from necessity.

In 2005, while working at a small MEMS engineering startup focused on ASIC design, I helped deploy and support a network of Red Hat Enterprise Linux workstations used by engineers for chip design and simulation. These systems ran specialized electronic design automation (EDA) tools designed primarily for Linux and UNIX environments. Stability and uptime were critical, and this was my first exposure to Linux as a true production operating system.

A couple years later, while studying for my Solaris certification, I received a free copy of Ubuntu. That opened the door to using Linux more broadly in home labs and personal projects. Over time I used Fedora, Ubuntu, and even experimented with Arch. Still, Windows remained my primary operating system for decades, including Windows 11 on my main workstation.

Until this week.

I migrated my primary desktop system from Windows 11 to Fedora KDE Plasma 43. I moved my files out of OneDrive, disabled auto renew on Microsoft 365, and committed to Linux as my daily environment. I configured the NVIDIA drivers, migrated my workflows, and validated that everything I rely on works as expected.

Modern Linux is no longer limited to servers or niche use cases. It is a mature, stable, and highly capable operating system that can serve as a primary desktop platform for many technical users.

Cost was one of the biggest motivators. Modern computing has become increasingly subscription driven, with recurring licensing fees for productivity tools, cloud storage, and hosted services. By switching to Linux, using free and open source software, and relying on local infrastructure such as my own NAS for storage and backups, I significantly reduced my ongoing software expenses.

Equally important is control and flexibility. Linux allows me to choose when and how systems are updated, which software is installed, and where my data is stored. It aligns closely with the same platform that powers cloud infrastructure, development environments, and most modern computing systems.

By combining Linux, free and open source software, local storage, and a small number of targeted subscriptions such as AI services, I now have the same core capabilities I had before, but with far lower ongoing cost and far greater control over my computing environment.

For the first time in over 30 years, my primary operating system is no longer Windows 11.

This time, it is Linux.

What is the future of AI, and is it really coming for everyone’s job? I do not have a crystal ball, but one thing is clear. Things are evolving fast.

For the past few years, AI has largely worked in a simple pattern. You write a prompt, and it returns a result. It has already become extremely effective at helping write Python, PowerShell, and other kinds of code, generate applications, and accelerate development. Tools like Codex (whether by macOS app, CLI, or VS Code extension), Claude Code, and other AI-assisted development environments have made it possible for almost anyone to build software and automate workflows.

But a major shift is now underway.

Emerging agent-based AI projects demonstrate a new model. Instead of simply responding to prompts, AI systems can now be configured to follow rules, make conditional decisions, and execute multi-step tasks. This changes the model from passive tool to active assistant, capable of operating with defined goals and behaviors.

Competition is accelerating rapidly. OpenAI, Anthropic, and others are expanding AI capabilities across desktop, mobile, and development environments. The direction is clear. AI is moving beyond isolated prompts toward persistent systems that assist continuously and integrate directly into daily workflows.

We have seen this pattern before. The “cloud” was once viewed primarily as a new way to deliver storage and compute over the internet. Today it represents the backbone of global computing infrastructure. Massive datacenters power everything from enterprise workloads to personal storage. Companies like NVIDIA have seen explosive growth in their data center business, reflecting the massive demand for AI infrastructure worldwide.

But the next phase may also become more personal.

As hardware continues to advance, local machines are becoming increasingly capable of running sophisticated AI workloads. This raises an interesting possibility. What happens when every individual has their own personal AI system running locally? A system capable of assisting, automating, and coordinating tasks on their behalf.

A computer on every desk was once the goal. Now it may be an intelligent assistant on every desk.

This raises important questions. Not just about jobs, but about how work itself evolves. The people who understand these systems, guide them, and integrate them effectively will be in a strong position moving forward.

These are simply observations from someone working in IT, watching the transition unfold in real time, and preparing for what comes next.

How long do you spend setting up and deploying new laptops?

Do you buy them ready to hand over, build them manually, or still image them with Acronis?

Endpoint deployment is one of those areas I kept coming back to, because when it’s good, IT runs smoother, and when it’s messy, everything else gets harder.

In a previous long-term role, our early deployment method was the classic approach with Acronis imaging. It was fast and it worked, but the problem was always the same. The image starts aging the moment you capture it. Windows updates, drivers, apps, and security baselines all drift. Before long, you’re spending more time maintaining the image than benefiting from it.

So I took the next step and built a more structured workflow using MDT server automation. That brought real improvements: better standardization, more control over drivers and installs, and a repeatable process that didn’t rely on undocumented steps or guesswork.

But the real end game was always modern management.

Eventually, I shifted toward Windows Autopilot and Microsoft Intune, with the goal of getting every endpoint cloud-managed. The challenge was that we weren’t starting from a clean slate. We still had on-prem Active Directory, a growing fleet of devices, and a lot of real-world constraints across multiple locations.

That’s where the work got interesting.

I stitched together a practical solution using PowerShell automation, deployment profiles, configuration policies, and app deployments to support both onboarding new devices through Autopilot, and repurposing existing devices into a modern enrollment flow.

Along the way, I also laid a foundation for security with Microsoft Defender for Endpoint, plus some basic Purview sensitivity labeling and DLP to start reducing risk without blocking productivity.

Was it perfect? No. Hybrid environments rarely are.

There were times devices became stale, duplicate entries appeared across Entra ID, Autopilot, and Intune, and some workflows still required manual steps like collecting hardware hashes or triggering enrollment from Windows settings. But even with a few rough edges, it made a real difference, especially when onboarding volume increased and the business needed consistency at scale.

Looking back, I never got the chance to fully finish and polish what I started in that previous environment. There was always another onboarding wave, another priority, and another fire to put out.

What’s been really rewarding lately is revisiting all of that work in my own TechSnazzy tenant, my lab environment, with the time to iron out the bugs and do it the way I always wanted to. Cleaner design, fewer manual touch points, and a foundation that’s fully repeatable.

It’s only a handful of devices, but seeing a modern endpoint lifecycle running smoothly end-to-end, with no guesswork, reminds me why I enjoy this so much.

Have you ever received a message from a recruiter where something just did not feel quite right?

Over the past few months, I have spent more time than usual on LinkedIn, and I know I am not alone.

Last July, my role at Standard Fiber came to an end after a long stretch there. Not long after, I joined FIT Solutions. It is a great company with good people, and I am genuinely glad I had the opportunity. In the end, it just was not the right long term fit for me.

Then the holidays arrived. Hiring slowed down, conversations paused, and now here we are at the start of a new year. So after all of that, and like many others, I find myself back here on LinkedIn figuring out my next steps.

As I have been connecting with people, I have noticed a pattern that is worth looking at.

Some messages come from profiles that look like recruiters or hiring contacts, but the interaction quickly shifts to asking for a resume or personal details without much context. Sometimes nothing is obviously wrong, but something feels off.

In many cases, this is a form of phishing.

The idea behind phishing is not always to steal something immediately. Often the goal is to gather information that can be used later. A resume can include your full name, contact details, work history, locations, and the tools or systems you have worked with. That is a lot of personal information to hand over too quickly.

If you are actively job hunting, here are a few things that have helped me slow down and think things through.

First, take a moment to look at the profile reaching out. Do they have a clear work history and a real company listed? Do their connections and activity seem consistent?

Second, notice how quickly they ask for your resume. Many legitimate recruiters are happy to have a short conversation first and explain the role before requesting documents.

Third, check the company outside of LinkedIn. A quick search can often confirm whether a role or organization is real.

Fourth, pay attention to where they ask you to send your resume. If someone claims to represent a company but asks you to email your resume to a generic address like hr-company@outlook.com or hr-company@gmail.com, that is usually a red flag. Legitimate companies almost always use their own domain for hiring communications.

Fifth, share less early on and trust your instincts. A brief summary of your background is usually enough until trust is established. If something feels rushed, vague, or uncomfortable, it is okay to pause or move on.

Most people on LinkedIn are there for the right reasons, and it is still a valuable place to network and find opportunities. This is just a reminder to move carefully, especially during times of transition when we are more open and more exposed.

If you are job searching right now, you are not alone.

Following up on my last blog post, I’m currently working through the MS-102 (Microsoft 365 Administrator) course, which is very cloud focused. Most of the material revolves around Microsoft 365 services, Entra ID, Intune, security, and compliance. Even so, I wanted a realistic lab environment to practice with, not just clicking through portals, but understanding how things fit together end to end.

That decision sent me down a bit of a rabbit hole.

After a lot of trial, error, and rethinking, I landed on a setup that I’m happy with. My old Intel NUC now runs Proxmox on bare metal as a Type 1 hypervisor, hosting two Linux servers for my password manager and Git repositories. Nothing flashy, just stable services I rely on.

For Active Directory, things took a different turn. I originally tried hosting Windows Server 2019 Standard on Windows 11 Pro using Hyper-V, but it was too bloated for the small Bee-Link mini PC I’m using. Performance was poor, it froze a lot, and it felt like I was spending too much time dealing with issues, so I scrapped it.

The new setup uses Fedora Workstation as the host OS with KVM/QEMU running the Windows Server 2019 domain controller VM. While this is technically a Type 2 hypervisor setup, KVM is a kernel level hypervisor, so in practice it behaves much closer to Type 1. Performance is excellent, stability is night and day better, and I can RDP into both the Fedora host and the DC with no extra remote access tools. Win win win.

Is this strictly necessary for MS-102? Probably not. But building out a working environment, even when it isn’t directly required, helps reinforce the bigger picture. In a production environment I would do deeper comparisons and planning, but for a home lab and learning setup, this has been a great experience.

The best part is that the only cost was the Windows Server license (which I got on eBay for cheap). Everything else is free, open source, and runs well on older or lower performance hardware. It took some configuration to get here, but it’s now documented and repeatable.

Back to MS-102, with a healthy dose of job searching sprinkled in between.