DEV Community: Thomas Jager

First sakila project log

Thomas Jager — Tue, 28 Oct 2025 12:33:40 +0000

📅 Date: 2025-10-16 → 2025-10-18

🔧 Tools: Python, Pydantic, MySQL, JSON, Git Submodules

⸻

How It Started

I hit a point where my project needed more than raw input() checks.
Validation logic was scattered between main.py, connectors, and random if/else.
Time to clean it up.

At the same time, my teacher asked to create a separate repo for homeworks, but I already use a monorepo. I finally decided to try something I wanted a long time:

create a second repo and attach it as git submodule.

So now advanced_python lives inside my main PythonJourney repo.

The Problem

User input validation became too complicated:

keyword must be validated
genre must exist in DB
years must be within allowed range

I needed one system that handles all validation in one place.

Also, performing validation directly against the DB was slow.
Each user input triggered a DB read.

The Fix:

1.Created a separate module dedicated only to validation.
All checks now run through Pydantic.

2.Extracted genres from the Sakila database and saved them into genre.json.

3.Created a cache module to load genres once and keep them in a dict
so validation is instant.

4.Added custom validators in Pydantic:

keyword validation
genre existence check (compared using cache dict)
year range validation

Updated main.py to send user input through Pydantic first, then run DB query.

What I Learned:

Validation belongs between user input and DB, not inside DB logic.
Pydantic simplifies input handling and makes code cleaner.
Cache is faster than querying the DB on every input.
Git submodules are perfect when you want to keep a monorepo but split projects.

✍ Personal Note
Not a huge feature, but this was the first time when the structure finally felt right.

Log015_sakila_mysql_pymongo

Thomas Jager — Fri, 17 Oct 2025 18:02:58 +0000

Start-here.page=about.post

title: "First School Project: Kino Search"

date: 2025-09-24

tags: [python, mysql, mongodb, school-project, learning]

summary: "My first real Python project — a console movie search app built with MySQL and MongoDB. Graded 1 (Sehr Gut)."

🎬 Kino Search — My First School Project

Graded 1 (Sehr Gut) - https://github.com/ThomasJager99/sakila_movie_search

“It started as a simple console movie search app.
Then it became my first real experience of building something that actually works.”
I. The Beginning

This was my first school project — a console application for movie search.
I built it completely from scratch: no templates, no frameworks, no IDE automation.
Just a terminal, a clean .venv, and a few libraries.

cd Projects/movie_search/
python -m venv .venv
source .venv/bin/activate
pip install pymysql pymongo python-dotenv tabulate

That’s where it all started — the moment when theory turned into practice.

⸻

II. Connecting the Databases

I created a .env file for database credentials and added it to .gitignore.

My first test script didn’t work — the school’s MySQL server was down.

Later it came back online, and my connection finally succeeded.

Then I connected MongoDB to handle logs.
A simple test created a document with my name and returned an ID.
That was the first “alive” moment of the project.

⸻

III. SQL vs NoSQL

Working with both databases side by side taught me a lot:

• MySQL — explicit open/close, manual sessions.
• MongoDB — persistent client, automatic connection pooling.

Different rules, different personalities, one task: make them cooperate.

⸻

IV. Refactoring the Code

After a few tests the code became messy — too many prints, repeated connections.
I cleaned everything up:

• Added _mysql_conn() encapsulation.
• Moved credentials and factories into config.py.
• Created log_writer.py for Mongo logging.
• Made each module communicate through config.py.

Now MySQL opens and closes cleanly for every query,
and MongoDB stays persistent through one global client.

⸻

V. Organizing the Project

To keep things under control, I expanded my PyCharm task markers:
TODO, WIP, BUG, NOTE, QUESTION.
Small detail, but it keeps focus on what matters.

⸻

VI. What I Learned

• How to manage two databases in one project.
• Why context managers matter for clean SQL sessions.
• How to refactor config and connection logic properly.
• How structure makes learning faster and calmer.

⸻

VII. Closing Thoughts

Kino Search was my first real experience of putting theory into code —
a simple console app, but a complete working system.
It was later graded 1 (Sehr Gut) — and that feels like a solid start.

PromptLock: When AI Meets Ransomware

Thomas Jager — Thu, 11 Sep 2025 07:44:00 +0000

So, this week I stumbled across something that instantly caught my eye: PromptLock. Researchers dug it up, and it's basically the first ransomware prototype that runs on top of a local AI model.

Yeah, not ChatGPT through an API, but an actual LLM sitting right there on your machine, helping the malware decide what to do.

What's Going On Here:

PromptLock uses a local model called gpt-oss:20b (running via Ollama).
Instead of shipping one fixed script, it tells the model: "Hey, write me some Lua code to scan these folders". Then next run it might generate a slightly different script.

Those scripts can:

list and filter your files
pick "valuable" stuff
encrypt or even exfiltrate it

Basically, it doesn't look the same each time, which is a nightmare for signature-based antiviruses.

Why It Matters:

It's cross-platform - Windows, Linux, macOS.
It's adaptive - behavior shifts each time.
And it's local - so no obvious API calls to track.

Now, not everyone's going to be hit by this. Most people don't have a giant LLM sitting on their personal laptop.

This smells way more like a corporate-level threat: servers, research labs, or any environment where local AI models are being tested.

For everyday users, your bigger risk is still the usual phishing mails and classic ransomware.

What We Can Actually Do:

Backups (the ones you test and actually restore).
Least privilege (don't run daily stuff as root/admin).
Watch your scripts - random Lua popping up on your box is never a good sign.
Behavior-based security tools over signature-based.

Nothing revolutionary here, but PromptLock shows how fast attackers adapt.

My Take

To me, the interesting bit isn't "oh no, AI is evil," but that malware authors are now treating LLMs as toolchains. They don't even need to write perfect malware anymore - they just need a model that can generate and tweak code on demand.

Feels like a new chapter in the cat-and-mouse game. But again, this isn't a doomsday scenario for every PC out there. It's a warning shot for enterprises and anyone experimenting with self-hosted AI.

Log014_CloudFlare_Zoho.mail_ec2.md

Thomas Jager — Thu, 04 Sep 2025 14:48:45 +0000

Start-here.page=about.post

📅 Date: 2025-09-04

🔧 Tools: Cloudflare, Zoho Mail, AWS EC2, Elastic IP, Apache, Certbot (Let’s En$

How It Started:

Today’s goal was to protect my website. I decided to start with Cloudflare and $

The Problem

To have a proper setup I needed:

Email address for the domain
DNS records for website + mail
Static IP for my AWS instance
SSL certificate installed directly on the server

The Fix

Domain + SSL via Cloudflare:

Bought a domain on Cloudflare
Activated free SSL included in the plan

Zoho Mail setup:

Used Zoho’s free plan (5 GB/mailbox, up to 5 accounts)
Authorized DNS with Zoho and added MX records (mx.zoho.eu)
Configured priority levels (10 → 20 → 30) for redundancy

DNS Records:

Added www as a CNAME alias
Set MX for mail delivery
Bound domain to AWS Elastic IP (so DNS won’t break after reboot)

Elastic IP:

Allocated Elastic IP in AWS
Attached it to the EC2 instance to prevent IP changes

SSL Certificate (Let’s Encrypt + Certbot):

Installed certbot on the EC2 instance
Generated SSL certificate with certbot
Configured Apache to use HTTPS

What I Learned:

Cloudflare free plan already includes Universal SSL, but server-side SSL is s$
MX records define where domain mail goes, priority numbers ensure fallback or$
Elastic IP is essential for stable DNS pointing to AWS.
Certbot automates SSL certificate creation and Apache integration.
Real setup = domain → Cloudflare proxy → AWS server with SSL.

✍ Personal Note:
All of this was mostly for learning — now my portfolio website has HTTPS.

Log013 - AWS, Debian 13, Fail2ban, Logrotate, Docker, AlmaLinux, Apache, AWS S3, CloudFront, AWS CLI.

Thomas Jager — Fri, 29 Aug 2025 14:04:25 +0000

Start-here.page=about.post

📅 Date: 2025-08-29

🔧 Tools: AWS, Debian 13, Fail2ban, Logrotate, Docker, AlmaLinux, Apache, AWS S3, CloudFront, AWS CLI

How It Started

I continued hardening my AWS server and setting up proper logging and monitoring. At the same time, I experimented with AlmaLinux in Docker to get a taste of corporate Linux environments. On the frontend side, I played with AI-generated React templates and finally connected AWS S3 with CloudFront to serve static files.

The Problem:

Setting up fail2ban and logrotate required extra tweaking.
After switching the SSH port, I initially locked myself out until I fixed both the AWS firewall rules and the server’s configs.
AlmaLinux containers are extremely minimal — no passwd, no shadow-tools, no utilities.
Apache cached a doomed image and refused to update it on the website.
With S3 → I had to figure out how to keep my bucket private but still serve files publicly.

The Fix:

Installed logrotate on AWS, set up fail2ban for SSH.
Reinstalled htop and tmux on Debian 13 to make SSH work easier.
Backed up and locked down SSH keys on an external drive.
Adjusted SSH config → added rules in AWS firewall first, then updated the server configs. Learned about jail.d/sshd_config.d for persistent overrides.
Spun up an AlmaLinux container (800 MB base) → installed passwd, shadow-tools, and basic utils with dnf.
Fixed Apache image issue by replacing the faulty picture with a valid one.
Set up AWS CLI on Mac, created a dedicated IAM user with keys, and configured ~/.zshrc for easier usage.
Created private S3 bucket + CloudFront distribution → now static content (images, etc.) is served globally while keeping the bucket private.

What I Learned:

Persistent SSH configs live in /etc/ssh/sshd_config.d/ and survive updates.
AlmaLinux base containers are minimal — need to manually add tools.
Apache may serve old/corrupted assets → sometimes it’s the file, not the cache.
AWS best practice → never generate keys as root, always use IAM users.
S3 + CloudFront combo = perfect way to serve static content privately but globally.
Commands Used

Logs cleanup on Debian

sudo journalctl --vacuum-size=200M

Install logrotate

sudo apt install logrotate

Fail2ban setup (Debian)

sudo apt install fail2ban

Useful tools

sudo apt install htop tmux

Change password utilities on AlmaLinux

sudo dnf install passwd shadow-tools

AWS S3: upload/download files

aws s3 cp ./cat.png s3://my-bucket/cat.png aws s3 ls s3://my-bucket

AWS CloudFront: invalidate cache

aws cloudfront create-invalidation
--distribution-id
--paths "/*"

✍ Personal Note: Today I finally got the “aha moment” with S3 + CloudFront: private bucket as the source, CDN as the face. Feels good to see my site pulling images from “millions of warehouses around the world.”

Log012 - Docker, Apache, EC2 etc.

Thomas Jager — Sat, 23 Aug 2025 18:31:58 +0000

Start-here.page=about.post

📅 Date: 2025-08-23

🔧 Tools: nginx, Docker, GPG, shred, logrotate, AWS EC2, SSH, Apache

How It Started

Kept working on my local server and fixing the webpage.
Started learning Docker on my Mac and explored file deletion concepts.
Tried to configure logrotate on Debian.
Decided to set up my first AWS Debian server as a playground for future portfolio work.

The Problem

GitHub link on my local webpage pointed to a 404.
Locale errors popped up every time I connected to the new AWS server.
Logrotate configuration wasn’t clear at first.
Learned that deleting files doesn’t actually erase them from HDD/SSD.

The Fix

Fixed the broken GitHub link by editing /var/www/html/index.nginx.
Studied secure file deletion:
On HDD use:

shred -u -v -z filename.txt

On SSD, due to TRIM, true deletion requires vendor-specific tools.
Configured logrotate with custom adjustments.
Installed Docker on Mac and, along the way, learned about GPG and key signatures.
Set up the first AWS Debian server and fixed locale issues with:

sudo dpkg-reconfigure locales

choosing en_US.UTF-8.

Planned next step: install and test Apache (httpd).
Created an SSH config on Mac for easier access to servers:

Host aws
HostName
User admin
IdentityFile ~/.ssh/.pem

What I Learned

Sometimes errors are trivial — one line in the config can fix a 404.
HDD vs SSD file deletion is fundamentally different: SSDs require special tools.
Logrotate is essential to keep the system from flooding with logs.
GPG and signatures are part of the foundation of secure software distribution.
AWS Debian requires fixing locales manually.
SSH config is a game-changer when working with multiple servers.

✍ Personal Note:
Feels like I’m slowly building a “server zoo”: local Debian with nginx, AWS with Apache, and Docker on my Mac.

Log011 - UFW, nginx and a dream.

Thomas Jager — Sat, 16 Aug 2025 16:32:10 +0000

Start-here.page=About.post

📅 Date: 2025-08-16

🔧 Tools: ufw, nginx, apt, systemctl

How It Started:

The idea was to install UFW, allow the necessary ports, and install nginx — then put something on it to test locally in browser.

The Process:

Install simple firewall — UFW
sudo apt update && sudo apt install ufw

Installation went successfully, nothing to complain about. I allowed port 22 to maintain SSH connection and did it before enabling the firewall, like a smart move:

sudo ufw allow 22

This added a new rule: SSH is allowed. And what I really like about UFW is its default policy — everything is denied unless allowed.

Allow nginx to talk to the browser Before enabling the firewall, I allowed another port:
sudo ufw allow 80

This is needed for HTTP.

Install and set up the web service — nginx:
sudo apt install nginx sudo systemctl start nginx sudo systemctl enable nginx

Although enable might not be necessary — after installation, nginx was already set to autostart on boot (as seen in systemctl status).

Result:
After a couple of iterations, I managed to create a small useful website — with all the links I need for my study. A small win for me. But it’s the foundation for future things.

What I Learned

• Always allow SSH before enabling the firewall.

• ufw is dead simple and efficient — good choice for minimal systems.

• nginx installs fast and works out of the box.

• Port 80 should be explicitly opened with ufw allow 80.

• Even minimal Debian is capable of serving something useful in a couple of minutes.

✍ Personal Note: Little win for me. From here, I’ll build up to more.

Log010 — wpa_supplicant trouble

Thomas Jager — Fri, 15 Aug 2025 15:22:48 +0000

Start-here.page=About.post

📅 Date: 2025-08-14

🔧 Tools: NetworkManager, ip, dhclient, rfkill, systemctl, wpa_supplicant, SSH, ssh-keygen

How It Started

I was setting up a fresh Debian 13 system on my server and wanted to migrate from using wpa_supplicant manually to managing my connection with NetworkManager. Along the way, I also began syncing my workflow between my Mac and the server, using SSH.

The Problem

NetworkManager broke the IP settings when I tried to restart it.
SSH wouldn’t connect after the server rebooted because IP addresses kept changing (e.g. from .121 back to .120, which conflicted with saved keys on my Mac).
Even after installing all the firmware and ensuring no blocks via rfkill, NetworkManager couldn’t manage the connection because wpa_supplicant was running independently.
The Fix

Manual IP Assignment (before DHCP setup):

sudo ip addr add 192.189.156.120/24 dev wlp3s0
sudo ip link set wlp3s0 up
sudo ip route add default via 192.189.156.1
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf

Install DHCP Client:
sudo apt install isc-dhcp-client
sudo ip link set wlp3s0 up
sudo dhclient -r wlp3s0
sudo dhclient wlp3s0

Check Internet:

ip a
ping 8.8.8.8
ping google.com
Verify Wi-Fi Module Status:
sudo apt install rfkill
rfkill list

Disable wpa_supplicant Process:

sudo systemctl stop wpa_supplicant

sudo systemctl disable wpa_supplicant

Later: sudo systemctl mask wpa_supplicant (for hard stop)

Fix SSH Key Conflict on Mac:
ssh-keygen -R 192.189.156.120

Reconnect to update known_hosts

Comment Out Auto-wpa_supplicant Launch:
Edit /etc/network/interfaces and comment out any lines that autostart wpa_supplicant

Stress Test:
Performed 5 reboots. Verified that IP remains stable (e.g., 192.189.156.120) only after masking wpa_supplicant and removing DHCP-based IP churn.
What I Learned

wpa_supplicant can launch outside of NetworkManager and interfere.

mask in systemctl completely disables the unit, redirecting it to /dev/null.

DHCP client assigns dynamic IPs on reboot unless static configuration is forced.

ssh-keygen -R is a lifesaver for known_hosts mismatch.

/etc/network/interfaces still matters in CLI-only Debian setups.

rfkill is critical for diagnosing Wi-Fi module blocks.

✍ Personal Note:

This was an interesting experience, because I made a lot of unnecessary moves. Like with every beginning - just like in Kendo - before you can strike properly, you’ll make a bunch of mistakes. But all of them are worth it.

Log009 - Debian 13

Thomas Jager — Fri, 15 Aug 2025 15:17:33 +0000

Start-here.page=About.post

📅 Date: 2025-08-14 🔧 Tools: USB with Debian 13

How It Started

It all started when I realized that my system, even after removing the GUI, was still heavy. It was a great experience troubleshooting the issues that came after deleting the GUI along with a bunch of variables and caches.

I used sudo apt --purge and ended up losing SSH, drivers, and a bunch of other things. I managed to fix most of them, but the system was already a mess.

So today, I rebooted and installed a fresh Debian 13 (light) on my server.

The Problem

Removed almost all network components.
Deleted drivers, especially ath10k_pci (internet-related).
Made a big mess in the file system.
Had trouble with a 5G Wifi connection — Debian 12 wouldn’t let me use my 5Gb internet because it wasn’t friendly with my drivers.

The Fix

Most file system issues were solved after spending a lot of time cleaning things up. I created one main directory for everything and built a tree with manuals and notes inside it.
The network was trickier — I had to use a USB stick, find the right driver manually, download it, and then set up wpa_supplicant & wpa_passphrase to create the first connection. After that, I installed Network Manager.
The 5G issue wasn’t completely solved. I replaced my firmware with a newer one, which gave me a 5G connection, but the speed was only 15 Mb/s.
In the end, I decided to completely erase the system. First, I created a tar -czf backup of the main directory and saved it to an external drive. Then I installed Debian 13 — now I’m building my environment from scratch, starting with a clean 1.4 GB base.

What I Learned

How to set up a network connection from scratch.
How to organize space better.
How to create a personalized environment.
How to use usermod to rename the server (did it twice).
Gained a deeper understanding of my system.

Log001 - 008/ From Ubuntu to Debian journey.

Thomas Jager — Fri, 15 Aug 2025 15:10:50 +0000

Start-here.page=About.post

A bit of context…

I first discovered Linux a little over 3 months ago — and honestly, it was love at first boot. From the very beginning, I chose Ubuntu, the most beginner-friendly distro, and started exploring everything I could get my hands on: SSH, Nginx, UFW… you name it.

For the first few weeks, it felt like I had entered a new world.

But after a month of living in Linux day and night, it started to feel… easy. Too easy.

I realized I wanted more control. A cleaner, more focused environment. That’s when I started looking into alternatives — something closer to the bare metal, but still stable.

After some research, I settled on Debian 12. It felt like the right choice for my learning goals and the server project I had in mind.

So, I made the jump.

Log 001

⚙Week 1 — Distro Migration: Ubuntu → Debian 12

Background:

• First contact with Linux: ~3 months ago

• Initial distro: Ubuntu (for accessibility and package availability)

• Explored basics: SSH, Nginx, UFW, local networking

Motivation to switch:

• Ubuntu became too “user-friendly” for learning deeper system control

• Wanted a cleaner, more minimal system

• Seeking full control for headless server setup

Decision:
• Switched to Debian 12

• Chosen for:

Stability
Better suitability for terminal-based workflows
Educational value for learning real Linux internals

Status: Migration complete. Debian is now the base OS for server experiments.

LOG 002

Install Process:

Ubuntu removed
Debian 12 installed (successful on 3rd attempt)
Chosen for lightweight footprint (~5 GB with minimal GUI)
GUI kept temporarily for orientation (XFCE)

Wi-Fi Issue:
• 5GHz reception broken due to hostapd update

• Conflict between access point tools and receiver module

• Hardware supports 5GHz, but driver setup unstable

Initial Configuration:

• SSH Remote Access enabled

• Performance mode set via CLI

• Root access used to grant sudo to user (sudoers config missing by default)

• Initial SSH connection unstable — high packet loss

Status: Debian system installed, partially configured. Further tuning in progress.

LOG 003

Test:

• Source: ~/scripts/ directory on Ubuntu

• Contents: mostly shell scripts in nested folders

• Packed into tar.zip archive

• Transferred to Debian system and unpacked

Observation:

• On Ubuntu: archive size ~68 MB

• On Debian (unpacked): directory size ~7.2 MB

• No visible difference in files or structure

Conclusion:

• Ubuntu system likely added extended attributes, hidden metadata, cache or indexing data to file structures

• Debian maintains a cleaner FS footprint on identical data

Takeaway: Debian provides significantly leaner storage behavior for plain-text scripts and directories. Useful for minimal setups or scripting environments.

LOG 004

Server identity and hostname updated.

I’ve decided to name my personal development server. The machine is a six-year-old laptop with the following specs:

• Intel Core i5 • 120 GB SSD

• 20 GB DDR4 RAM (manually upgraded)

While working with it on a daily basis — SSH, packages, configurations — I realized that naming the machine would be a meaningful step. From this point forward, the hostname and identity are set to:

makko@kujira (kujira = クジラ = whale in Japanese, specifically referring to the sperm whale: マッコウクジラ / makko kujira)

Hostname, prompt, and system references have been updated accordingly.

This marks the beginning of my server journey.

LOG 005

Power state inconsistencies and crontab/rtcwake issues

Recently attempted to automate power management on my Debian server: wake at 6:00 AM, shut down at 00:00.

Steps taken:

• Created a root-level crontab job to use rtcwake

• Target: rtcwake -l -m no -t [timestamp]

• Simultaneously scheduled shutdown via sudo poweroff

Observed issues:
• rtcwake did not correctly set the wake timer via crontab

• System stayed powered on through the night

• Only user-level crontab messages (like greetings) executed as expected

Additional problem encountered:

• After full shutdown via poweroff, the server powers on ~10 minutes later with only the LED on — no POST or boot

• System appears stuck in an undefined power state

Temporary solutions:

• Disabled Wake-on-LAN in BIOS

• Cleaned and adjusted crontab entries for both root and user

Conclusion: Current automation using crontab and rtcwake is unreliable. Will research and eventually implement custom system daemons for robust control.

Additional: After some digging, I found the main reason my server wasn’t sleeping/waking on time — a misconfigured root crontab.

I updated my script and discovered a neat feature:

date -d "Tomorrow 6:00" +%s

This returns a timestamp for 6:00 AM tomorrow. The -d flag surprisingly accepts natural language inputs like "next Friday", which seems to be a GNU/Linux-specific thing — quite handy.

I manually tested this logic:

• Scheduled wake-up for 7 minutes later

• Set sleep in 20 seconds

• Verified wakealarm log — it worked

Then I rewrote the root crontab like this:

58 23 * * * /home/makko/dir/dir/sleep.script.sh >> /home/makko/sleep_log.md 2>&1

Now both stdout and stderr are logged, so I can debug directly if anything fails.

We’ll see if this new setup behaves better.

LOG 006

Issue: crontab under root failed to execute scheduled sleep/wake script due to missing PATH environment.

Symptoms:
• Script worked manually (sudo ./sleep.sh)

• Cron triggered suspend, but failed to locate rtcwake: rtcwake: command not foud

Diagnosis: Cron runs in a limited environment and does not inherit user-defined environment variables (like those in .bashrc or .profile). As a result, its $PATH is incomplete.

Steps Taken:

Verified $PATH via echo $PATH in normal terminal and compared it to cron.
Identified that rtcwake is located in /usr/sbin which was missing from cron’s path.
Added full path export directly in the script: Result:

• Script now sets wake timer and system enters suspend mode correctly.

• System wakes up at the intended time (e.g. 06:30) using rtcwake.

Conclusion: Always ensure critical binaries are included in $PATH when executing scripts via crontab, especially under root. Cron’s limited environment requires explicit context setup.

Plan: – Add a 20-minute warning before shutdown. (The laptop shut down last night while I was working — forgot about the crontab.)

LOG 007

Lid closed, system alive — configuring logind.conf

Task: Prevent the server (a repurposed laptop) from suspending when the lid is closed.

Steps:

Switched to root.

Edited the config file: /etc/systemd/logind.conf

Found this line (commented by default): #HandleLidSwitch=suspend

Uncommented it and changed value to: HandleLidSwitch=ignore

Rebooted system.

Result: Now, the machine stays fully functional with the lid closed. SSH sessions stay alive, workflows uninterrupted.

Also explored /sys/class/power_supply/BAT1/ for battery monitoring: • capacity — battery percentage • status — current charging state

LOG 008

Startup monitor script via .bashrc

Implemented a custom Bash script that runs every time the terminal is launched (via ~/.bashrc). While it’s not a daemon, it acts as a simple visual status dashboard.

Functionality includes:

• Welcome message on shell launch

• Battery level readout

• Charging status (Charging, Discharging, or Full)

• CPU model info

• Core temperature and voltage reporting

• Basic network diagnostics (ping to laptop and router with ping -c 5)

Notes: • The ping -c flag allows for fixed-length diagnostics — clearer output for terminal-based checks • Output design (colors, formatting) took significantly longer than the actual logic

Goal: Create a personal visual health-check system for the server - lightweight, non-intrusive, and tailored for manual inspection. Future plans: turn this into a daemon for background monitoring and automated alerts.

🧭 Start Here: Linux Server Logbook

Thomas Jager — Fri, 15 Aug 2025 14:46:44 +0000

Welcome to my personal devlog series.

A logbook of how I learn Linux by building and breaking things on my own server.
This is hands-on learning, and i love it.

💻 My Hardware

• CPU: Intel Core i5-7200U @ 2.5GHz (Turbo 3.11GHz)

• GPU: NVIDIA MX150, 2GB GDDR5

• RAM: Upgraded to 20GB DDR4

• Storage: 126GB SSD Sandisk

• Wi-Fi: 802.11ac

• Ports: Thunderbolt + standard I/O

• Current OC: Debian GNU/Linux 13 (trixie) / Space: fn 1,5Gb.

•Server name: "マッコウクジラ — makkō kujira - sperm whale"

📂 What is this logbook?

This is a collection of logs documenting:

• install and reinstall systems manually

• fight with wpa_supplicant and systemd masking

• configure static IPs and chase down DHCP demons

• run a fully terminal-based setup with no GUI

• plan to build a proper homelab and NAS — and more later

📌 How the logs are structured

Each post follows this format:

📅 Date: YYYY-MM-DD

🔧 Tools:

How It Started

(Short intro)

The Problem

(What went wrong)

The Fix

(How I solved it)

What I Learned

(Quick list)

✍ Personal Note:
(Optional reflection or joke)

🔗 Index of logs

10.

🧷 How to keep this post “pinned”

Since dev.to doesn’t support pinned posts:

• This post includes the #start-here tag

• I’ll link back to it in each future log

• It’s also added to my profile bio

• You can bookmark it or follow the series tag