Camille
Stennis

I’ve spent years making content. Today I built the system that puts it on a screen.

What I did

I built a digital signage pipeline for a fictional stadium concourse, start to finish, with free tools.

The content side: a concessions menu board designed in Photopea, animated in DaVinci Resolve’s Fusion page, and a 15-second sponsor spot for a made-up brand, Rinkside Grill. Everything exported as H.264 at 1080p, 29.97. Before anything touched a screen, I checked every file in MediaInfo from the terminal: codec, resolution, frame rate, bitrate, audio track.

The system side: Xibo, an open-source signage CMS, running in Docker on a new Ubuntu VM in Proxmox, behind my OPNsense firewall. The screen is a Windows player on my Active Directory domain. I built three layouts and scheduled them by event phase: Doors Open, In Game, Postgame. Then I watched the screen switch on its own.

What broke

• A sponsor-style ProRes file wouldn’t upload. Xibo’s video module only allows wmv, avi, mpg, mpeg, webm, and mp4, so the .mov was grayed out in the file picker. I transcoded it to H.264 in Shutter Encoder instead of adding .mov to the list. Renaming a file changes the label, not the codec.
• The transcode came out at H.264 Level 5.1. A 1080p, 29.97 file only needs Level 4.1, and some older players won’t take more. Same codec, different spec.
• My Mac couldn’t reach the new VM. First fix: a WAN rule in OPNsense. Second fix: the firewall’s logs showed traffic passing in but replies never coming back. OPNsense was sending them to my home router instead (reply-to). Disabling reply-to on WAN rules fixed it.
• Mid-install, every VM in my lab froze at once. The LVM thin pool hit 100% while Docker pulled images. Old snapshots with saved RAM were holding most of the space. I extended the pool, resumed every VM, and deleted the snapshots I didn’t need. 100% down to about 51%.
• After the freeze, the player’s clock ran about 7 minutes behind. Paused VMs don’t keep time, and a signage schedule runs on the player’s clock.

What I learned

Check the file before you check the player. MediaInfo answered most of my playback questions before I ever opened the CMS.

A firewall rule passing traffic doesn’t mean the conversation works. The logs showed the packet getting in. The fix was the way back out.

Thin provisioning is a promise, not storage. My VM disks were promised about 712 GB on a 156 GB pool. Snapshots with RAM made it worse. Next time I take one, I uncheck Include RAM.

What’s next

Sync the lab clocks to a real time source, add a sponsor-only daypart, and write a pre-event QC checklist for the screens.

Watch the demo on YouTube

Permalink to this entry →

So I just wanted to access an authentic Debian bash shell for Linux Admin class, but uh… my home server never turned back on after a recent power outage. Whoops!

What I did

This turned into a fun exercise in power outage planning. I was on my couch in the living room going through Linux homework and I decided I wanted to remote into my Ubuntu VM sitting on my home server. But I couldn’t connect! I tried pinging it, nothing. I tried troubleshooting, and confirmed that my home server had a static IP, so that wasn’t the issue. Even though my home did experience a couple of power outages this week. I initially thought DHCP assigned it a new IP, but as mentioned - it was static.

Claude suggested checking the physical server terminal for the current IP, what a concept! So I scooted off the couch to the location of my home lab in my office and to my surprise… the server wasn’t even on! Power was off. Layer 1 troubleshooting, check that the device you’re attempting to connect to is actually turned on.

This wasn’t the first time this had happened, I just forgot. My server was not configured to automatically turn back off once power was reestablished following an outage. It was time to change that. I rebooted the Dell Optiplex and pressed F2 upon startup to enter BIOS settings, and scrolled down to AC Recovery to enable it. I now will no longer have to physically walk to my home lab server after a power outage to turn it back on.

What broke

• BIOS setting for AC Recovery was not enabled prior to a power outage and I was unable to remotely connect.

What I learned

Enable power recovery when setting up a new server rather than wait for a power outage to teach you the consequences of not doing so.

What else I did

Since I was already in the homelab, I thought now would be a good time to finally set up remote acess to my VMs when not connected to the local network. Like when I’m at school or traveling elsewhere.

I made a Debian container, not a new VM, to host Tailscale in Proxmox. Tailscale is a mesh VPN that let’s you connect from any location. Set up was pretty straight forward. Proxmox has great templates for containers, which are great for conserving storage and RAM. Full VMs eat up more resources, and I just wanted access to a linux kernel outside of my macOS.

While creating the container I did forget to configure the Network device for it and couldn’t access the internet to download Tailscale, an encrypted peer-to-peer connection. This was an easy fix of assigning IPv4 to DHCP so that it pulled whatever IP was available. I did this instead of setting a static IP because Tailscale was going to assign it’s own static IP on top that I would be using instead. Voila! My containter had internet access.

What broke

• Network configs did not have a gateway assigned, needed an IPv4 address to communicate upstream.

What I learned

That even after all of this… my college network blocks remote connectivity LOL. I’m currently sitting in class on my celullar hotspot as a workaround, oh well.

Permalink to this entry →

I’ve run production teams for years. Today I built the server one would work from.

What I did

I set up a shared file server on Ubuntu 24.04 for a fictional podcast team. Two shows. Six episodes. Raw, edit, and final folders for each one, built with a single brace expansion command.

Then I locked it down. Three users, two groups, three levels of access. A producer who can reach everything. An editor who can work in the shows but can’t touch the archive. An outsider who can see the front door and nothing behind it.

I didn’t stop at setting permissions. I tested them as each user and saved the results. Six tests. All six matched.

What broke

• A typo gave a user the shell /bing/bash. She couldn’t have logged in. I found it in /etc/passwd and fixed it.
• usermod -G without -a wiped a user’s groups. On an admin account, that’s how you lose sudo.
• sudo -u asked for a password that doesn’t exist. sudo -l showed why: my account could only run commands as root. I switched to runuser.
• Wildcards stopped working once folders were locked, because they expand as you. Files first, then folders.

What I learned

Setgid puts new files in the right group. Umask decides whether that group can edit them. A shared folder needs both. I proved it: one teammate created two files, and the other could edit only one of them.

What’s next

Chapters 10 and up: processes, the environment, and shell scripting. The runbook in this repo is a list of commands right now. Next, it becomes a script.

View the repo on GitHub

Permalink to this entry →

What I did

Today, Oct 16, 2026, I migrated camillestennis.com from Base44, a no-code site builder, to a site I built with Astro and host on AWS.

My first plan was Cloudflare Pages. I switched to AWS because I’m studying AWS and wanted the build to match. Before creating anything, I set a $5 AWS Budget alert.

I rebuilt the site as a static Astro site, with the code in a public GitHub repo. Terraform manages the infrastructure: a private S3 bucket with Block Public Access on, and CloudFront in front of it. Origin Access Control means only my CloudFront distribution can read the bucket.

I added a CloudFront Function to rewrite clean URLs like /about to /about/index.html. S3 is file storage, so it doesn’t do that on its own. I also set up an ACM certificate, validated through DNS, and Route 53 alias records, A and AAAA, for the bare domain and www.

I created the Route 53 hosted zone by hand in the console for practice. Before pointing the domain at it, I tested it with dig against the AWS nameservers.

I moved DNS from Squarespace to Route 53 while the old site stayed up, then cut over to CloudFront. The main domain had no downtime.

The hosted zone costs about 50 cents a month. Everything else fits in the free tier.

What broke

My first git push failed with “Repository not found.” The repo didn’t exist on GitHub yet. I created it from the terminal with the GitHub CLI using gh repo create.

dig showed eight nameservers for my domain, four squarespacedns.com and four nsone.net. All eight turned out to be Squarespace defaults. The Squarespace nameserver page wasn’t editable, so I had to switch to Squarespace nameservers first, then to custom ones to enter the four Route 53 servers.

Instead of waiting for my own DNS cache to update, I checked the .com registry directly with dig NS camillestennis.com @a.gtld-servers.net +norecurse. My cache could hold the old answer for up to 48 hours. The registry check showed me the change in seconds.

During cutover, I had to delete the old www CNAME before Terraform could create the alias records. DNS won’t allow a CNAME and an A record on the same name.

My headshot and AWS badge didn’t load on the live site. The image files were 0 bytes. curl got a redirect but didn’t follow it, saved an empty file, and still exited 0. The rest of my command chain kept going. I re-ran it with -L to follow redirects and checked file sizes before deploying.

What I learned

An exit code of 0 means the command didn’t error. It doesn’t prove I got what I wanted. Check the output, like file size or checksum. It’s the same lesson as verifying the OPNsense installer in Entry 04.

Ask the source of truth. Querying the registry directly told me in seconds what my cached DNS could have hidden for hours.

If Terraform manages a resource, change it in Terraform. Editing it in the console creates drift, which the next apply undoes.

Alias records let the bare domain point at CloudFront. A CNAME can’t do that.

What’s next

I’ll set up GitHub Actions with OIDC so every push builds and deploys automatically, with no AWS keys stored in GitHub.

I’ll import the hand-built hosted zone into Terraform with terraform import.

I’ll cancel Base44 once the new site has run cleanly for a few days.

Moving a site to AWS too? I’d love to hear what you’re working on.

Permalink to this entry →

What I broke

I worked four failures as tickets. With wrong DNS on the workstation, domain login failed while the domain controller still answered pings. When I stopped the DHCP service, the workstation gave itself a 169.254 address. With the domain controller offline, users who had signed in before got in with cached credentials, but new users couldn’t. “No internet” was really no DNS. For an account lockout, I verified identity, then unlocked the account.

What surprised me

My first DNS break didn’t show up at all. Cached lookups kept working until a reboot. That’s exactly how “it worked yesterday” tickets happen.

What’s next

A second domain controller would remove the single point of failure. BitLocker encryption and a full Windows reinstall are next in the lab.

Permalink to this entry →

What I did

I built a Windows Server 2025 domain controller with a static IP and promoted it to a new Active Directory forest. I set DNS forwarding to the firewall and added a reverse lookup zone. I migrated DHCP from the firewall to the domain controller in a planned order, avoiding two DHCP servers on one network. I built a Windows 11 workstation, joined it to the domain, and created a user who must change their password at first login. I confirmed the login went through the domain controller.

What broke

Neither Windows installer could see the disk or network until I loaded VirtIO drivers. A health check, dcdiag, flagged two failures. Their timestamps matched the first reboot after promotion. I confirmed the services were working before calling them startup noise.

What I learned

Active Directory lives and dies by DNS. That’s why the domain controller hands out its own address as the DNS server.

Permalink to this entry →

What I did

I created an isolated lab network bridge in Proxmox and installed OPNsense as the gateway between my home network and the lab. I set up NAT, DHCP, and DNS.

What broke

The first install failed with disk read errors because the installer image was truncated during upload. I downloaded it directly to the server and verified it with a SHA-256 checksum. The default config briefly put the firewall’s LAN side on my home network, using my home router’s address range. That created a rogue DHCP risk, so I disconnected it until I reassigned the interfaces. After the setup wizard, I was locked out of the firewall’s web interface. The browser said “timed out,” not “refused,” which told me packets were being silently dropped. I wrote a narrow rule allowing HTTPS only from my home network.

What I learned

I verify images before installing. “Timed out” versus “refused” helps me tell a firewall problem from a dead service. I also traced a packet hop by hop through two layers of NAT.

Permalink to this entry →

What I decided

• Retired my plan to build a SOC simulation (Active Directory, Sysmon, Wazuh, attack simulation).
• Refocused the homelab into a network lab, aimed at the CCNA.
• Updated my certification path: AWS Cloud Practitioner, then CompTIA Security+, then CCNA, then AWS Solutions Architect Associate.

Why

While mapping out the SOC build, I noticed where my attention actually went. Every time I got into the network layer (IP addressing, how traffic moves between machines, VLANs) I wanted to keep going. When the work moved up to the applications and alerts sitting on top of the system, my interest faded. I like the bones of a system. Networking is the part that hooks me, so that’s where I’m building.

This isn’t a restart. Everything from Entries 01 and 02 still counts: Proxmox, static IPs, SSH, and Docker all live on the network. My Terraform project was VPC work, which is networking in the cloud.

What’s next

• Build my first topologies in Cisco Packet Tracer: switches, routers, VLANs, and subnetting.
• Buy a managed switch (still on the list from Entry 01) and segment my home network.
• Later: run GNS3 or EVE-NG on the Proxmox box for more realistic labs. 16GB of RAM may get tight, so I’m watching that.

Studying for the CCNA too? I’d love to compare notes.

Update, Oct 2026: I brought Windows and Active Directory back as an IT support lab to match the help desk and field tech roles I’m interviewing for.

Permalink to this entry →

What I did

• Installed Docker on my Ubuntu VM (the virtual computer I built last time).
• Set up Portainer, a dashboard that lets me see and manage everything Docker is running, without typing commands for every little thing.
• Deployed my first container: a small web server running a test page.

The plain-English version

Think of my physical computer as an apartment building. Proxmox (the software I installed directly on the hardware) is what let me carve that building into separate apartments, each one a fully independent “unit” with its own walls, its own everything. My Ubuntu VM is one of those apartments.

Docker works differently, and inside that one apartment. Instead of building more walls, Docker is more like buying a bunch of matching, ready-to-go furniture sets, each one a “container”, and dropping them into different rooms of the same apartment. Each one is self-contained and comes with everything it needs already assembled, but they’re all still sharing the same electricity and plumbing (the apartment’s operating system) underneath. That’s the real difference between a VM and a container: a VM is its own separate apartment, a container is a self-sufficient room inside one.

Portainer, then, is just the building manager’s clipboard, a single dashboard where I can see every “furniture set” I’ve dropped in, check if it’s working, and add or remove them, instead of manually checking each room myself.

For today’s test, the “furniture set” I dropped in was a basic webpage. Not exciting on its own, but it proved the whole chain works: hardware, to virtual apartment, to container, to something visibly running that I could pull up in a browser.

What broke / what I learned

• Portainer’s first-time setup has a short security timer. If you don’t finish creating your admin account fast enough, it locks you out and you have to restart it and grab a fresh access code. Mildly chaotic, but a good reminder that even setup screens are built with security-first thinking.
• Small syntax trip-up: typing $actualname instead of $USER in a command. In this world, a $ in front of something means “look up this stored value,” not “insert this literal word.” One character, big difference in outcome, exactly the kind of precision this field rewards.

What’s next

• Get more comfortable deploying containers through Portainer’s interface.
• Start building toward the bigger picture: a mock “company” (a fake office network) inside my homelab, complete with its own user accounts and machines, so I can practice real security monitoring on something realistic instead of just an empty VM.

Permalink to this entry →

What I did

• Sourced and assembled a full homelab rig from scratch: a $188 refurbished Dell OptiPlex 3060 SFF, a monitor, keyboard/mouse, and a dual-connector USB drive, all bought used or on a budget.
• Wired the machine into my home network, confirmed the NIC and static IP entirely from the command line before ever touching a browser.
• Installed Proxmox VE (a bare-metal hypervisor) directly onto the hardware, configured with a static IPv4 address instead of the default IPv6.
• Created and installed my first virtual machine (Ubuntu Server 24.04), fully isolated from the host.
• Set up SSH so I can manage that VM entirely from my laptop, no monitor or keyboard required going forward.

What broke / what I learned

• My HDMI cable didn’t fit the OptiPlex’s port. Turned out the “HDMI” label on the refurb listing was wrong: it was actually DisplayPort. Fell back to VGA for the one-time setup screen instead of buying the wrong adapter twice.
• balenaEtcher (the tool I planned to use to flash my installer USB) threw a bug on both local file and URL flashing. Skipped it entirely and used dd via Terminal instead, which is honestly the more “real” way people do this anyway.
• Learned the hard way that Proxmox’s default free-tier repo setup throws update errors until you manually disable the enterprise repos, an easy one-line fix once I knew to look for it, but not obvious from the UI alone.
• Biggest lesson: almost nothing about this was plug-and-play. Every step had a small decision to make or a small thing to debug, which is exactly the muscle I’m trying to build for SOC work.

What’s next

• Install Docker on the Ubuntu VM and get my first containerized service running.
• Buy a managed switch and start segmenting my network into VLANs.
• Eventually: build out log aggregation so I can practice actually monitoring what I’ve built, not just running it.

Following along or building your own? I’d love to hear what you’re working on.

Permalink to this entry →