DEV Community: Richard Chamberlain

Grafana Log Dashboards — From Fleet Overview to Per-Host Detail

Richard Chamberlain — Sun, 05 Apr 2026 18:19:58 +0000

Grafana Log Dashboards — From Fleet Overview to Per-Host Detail

Email-based monitoring has a failure mode: the inbox fills up, mail rules get created, and eventually something critical gets missed.

Two Grafana dashboards break that pattern.
The three-screen flow:

→ Network Overview: error count column, red when problems exist, click to investigate → Log Summary: errors, warnings, failed logins, invalid users, sudo events, total log lines → Host Logs: log volume time series + three pre-filtered log panels
What's new on Host Logs:

✓ All Logs — full unfiltered stream for context ✓ Errors & Warnings — pre-filtered, first stop when stat panels are red ✓ Auth & Security — raw auth log with user, IP, and timestamp ✓ Annotations on the time series for marking events during investigation
The design principle:

Each screen narrows the scope. Two clicks from signal to log lines.

grafana #loki #linux #observability #logmonitoring #promtail #dashboard #sysadmin

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/Linux-Log-Dashboards/

Grafana Network Overview — Every Device, One Screen

Richard Chamberlain — Sun, 29 Mar 2026 14:20:40 +0000

Most monitoring setups have the data. What they are missing is a way to see all of it at once.
What this dashboard does:

→ Groups every monitored host by subnet → Shows status, CPU, memory, and disk — one row per device → Uses threshold colouring — plain for healthy, yellow/red for problems → Links each hostname to Node Exporter Full for per-host detail → Powered entirely by Prometheus and Node Exporter — no extra agents
The design principle:

A healthy environment should look quiet. Colour only appears when something needs attention. If every cell is lit up, nothing stands out.
The two-screen workflow:

Overview — scan it, identify which host needs attention

Node Exporter Full — click the hostname, find the cause

grafana #prometheus #linux #observability #nodexporter #dashboard #sysadmin

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/Grafana-Network-Overview/

Grafana — The Single Pane of Glass

Richard Chamberlain — Sun, 22 Mar 2026 19:20:12 +0000

Prometheus tells you how your systems are behaving. Loki tells you what happened. OpenSCAP tells you whether you are compliant. But three tools means three places to look.

What Grafana adds:

→ One dashboard connecting all three data sources
→ Correlation by time — metrics and logs from the same incident in one view
→ Compliance status alongside operational health
→ Unified alerting regardless of which source triggers

What Grafana is (and is not):

✓ A visualization and alerting platform
✓ A connector to Prometheus, Loki, and SCAPinoculars
✗ Not a data collector — it reads what already exists
✗ Not a replacement for Prometheus, Loki, or OpenSCAP

The best security posture is not the one with the most tools. It is the one where you can see everything clearly enough to act on it.

linux #grafana #observability #prometheus #loki #openscap #singleglassofpane #sysadmin

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/Grafana/

OpenSCAP: Compliance Scanning for the Linux Corporate Desktop

Richard Chamberlain — Sun, 08 Mar 2026 13:08:27 +0000

Compliance audits used to mean a person with a clipboard. OpenSCAP automates the entire process.
What I built:

→ OpenSCAP on Rocky Linux (SSG from dnf), Ubuntu 24.04 (SSG from upstream GitHub), and Fedora Kinoite (baked into OSTree image) → CIS profile auto-discovery handling Rocky vs Oracle Linux profile ID differences → SCAPinoculars exposing ARF XML results as Prometheus metrics on port 2112 → Compliance metrics alongside CPU, memory, and logs in Grafana → Custom RPM packaging for SCAPinoculars and OSTree Kinoite integration
What it solves:

✓ Cross-distribution compliance scanning with one consistent workflow
✓ Compliance results visible continuously — not just at audit time
✓ Configuration drift detected immediately via Grafana alerts
✓ Prometheus + Loki + OpenSCAP unified in one Grafana dashboard

Quirks documented:

SCAPinoculars v0.0.3 ignores --report-dir and --port flags
Ubuntu ssg-base package has no datastream XML — use upstream ZIP
Rocky + Fedora repos enabled: use --disablerepo="fedora*" at install

linux #openscap #compliance #cis #prometheus #grafana #kinoite #ansible #sysadmin

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/OpenSCAP/

Loki: From Naming Servers After Gods to Monitoring Them

Richard Chamberlain — Sun, 01 Mar 2026 14:27:11 +0000

Prometheus tells you how your systems behave. Loki tells you what happened.
What I built:

→ Grafana Loki server with systemd (Rocky Linux)
→ Custom Promtail RPM for Kinoite OSTree compatibility
→ systemd-journal log shipping from servers and desktops
→ SELinux file contexts for GitHub-sourced binaries
→ Label-based log organization matching Prometheus scheme

What it solves:

✓ Centralized logs from servers and immutable desktops
✓ LogQL queries across all systems without SSH
✓ Historical log context for incident investigation
✓ Foundation for Grafana alerting and OnCall integration

Prometheus + Loki + Grafana = full observability stack.

linux #loki #grafana #logaggregation #promtail #observability #kinoite

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/Loki/

Bringing Prometheus Monitoring to the Linux Corporate Desktop

Richard Chamberlain — Sun, 22 Feb 2026 15:40:34 +0000

Enterprises monitor servers. Desktops? Usually ignored—until something breaks.
What I built:
→ Prometheus server with Ansible deployment
→ node_exporter on Kinoite desktops (OSTree builds)
→ Service discovery with environment/role labels
→ Firewall security (restricted metric access)
→ Historical time-series metrics for trend analysis

What it solves:

✓ Blind spots in desktop infrastructure
✓ Reactive troubleshooting
✓ No historical metrics
✓ Capacity planning guesswork
✓ Inconsistent monitoring approaches

If desktops are infrastructure, monitor them like infrastructure.

linux #prometheus #monitoring #observability #desktopmanagement

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/Prometheus/

Enterprise Desktop Update Lifecycle with Kinoite

Richard Chamberlain — Sun, 15 Feb 2026 13:38:15 +0000

Enterprise Desktop Update Lifecycle with Kinoite

Remember Knoppix? That safe feeling—boot from CD, use Linux, nothing breaks, nothing permanent?

Now scale that to enterprise desktops.
What I built:

→ Custom OS images per department (JSON-defined) → Ansible automation for builds and deployments → Dev-test-prod pipeline with promotion → Atomic updates with instant rollback → Zero configuration drift across hundreds of desktops
What it solves:

✓ Manual desktop configuration eliminated ✓ Update failures can't break systems ✓ Testing before production deployment ✓ Rollback in seconds, not hours ✓ Department-specific customization at scale

From Knoppix safety to enterprise reliability.

linux #kinoite #automation #desktopmanagement #ostree

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/Lifecycle-with-Kinoite/

OS Updates on the Corporate Linux Desktop

Richard Chamberlain — Sun, 01 Feb 2026 17:19:37 +0000

OS Updates on the Corporate Linux Desktop

Remember when "please update your systems ASAP" emails meant crossing your fingers? There's a better way.
What I built:

→ Self-hosted OSTree repository for Kinoite deployments → Dev/prod pipeline for testing before production → Image-based updates with instant rollback → Complete control over update timing and content
What it solves:

✓ Test updates before deploying to users ✓ Deploy exact tested images (not "similar" ones) ✓ Instant rollback if anything breaks ✓ No dependency on external update servers

Full configuration walkthrough with examples and explanations.

linux #ostree #rpmostree #updates #kinoite #enterprise

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/OSTree/

Controlling Software on the Corporate Linux Desktop

Richard Chamberlain — Mon, 26 Jan 2026 11:10:59 +0000

Ever worked somewhere that did software audits? Remember the scrambling to uninstall unapproved tools right before the review—only to reinstall them the next week?

Yeah, I lived that too. Here's the better way.
What I built:

→ Internal Flatpak repository on Rocky Linux 9.7
→ GPG-signed applications for trust and integrity
→ Apache HTTPS distribution with network-level controls
→ Automated client configuration

What it solves:

✓ Audit compliance without the panic
✓ Controlled software distribution without blocking productivity
✓ Clear provenance for every application

linux #flatpak #enterprise #devops #security

[Read the full article] → https://richard-sebos.github.io/sebostechnology/posts/Flatpak-Repo/

Making Linux Work as a Corporate Desktop

Richard Chamberlain — Sun, 18 Jan 2026 21:08:55 +0000

🔒 Corporate Linux Desktop Security: The Immutable Advantage

Quick take: Traditional Linux desktops are mutable—attackers can modify system files and persist malware. Immutable distros like Fedora Silverblue flip that model: the base system is read-only, updates are atomic, and rollback is instant.

The Problem with Traditional Desktops

Configuration drift: Every system becomes unique over time
Update failures: Partial installations leave broken states
Malware persistence: Attackers modify /usr/bin, install rootkits
Recovery time: Hours to restore from backup

The Immutable Solution

Fedora Silverblue uses OSTree for atomic, versioned filesystem management:

# Current deployment
rpm-ostree status
● fedora:fedora/40/x86_64/silverblue
  Version: 40.20241215.0
  Commit: a3f5b8c7d9e6...

# Update failed? Instant rollback
rpm-ostree rollback
systemctl reboot
# 30 seconds to recovery

Key Benefits:

🔐 Immutable /usr

System files read-only during operation
Malware can't persist in system directories
Unauthorized changes don't stick

⚛️ Atomic Updates

All-or-nothing deployments
No partial failure states
Boot menu fallback automatic

📦 Flatpak Sandboxing

Applications isolated from base OS
Granular permission controls
IT maintains approved app repositories

🛡️ SELinux Enforcement

Mandatory access control at kernel level
Default-deny security model
Even root processes constrained

Real-World Security Scenario

Attack: Browser exploit gains code execution

Traditional Desktop:

Full filesystem access
Can modify system binaries
Establish persistence in startup scripts
Install rootkit in /usr

Silverblue:

Flatpak sandbox limits filesystem access
Can't write to read-only /usr
SELinux constrains even if sandbox escaped
Rollback removes any user-space changes

Who Should Care?

Enterprise IT: Deploying hundreds of consistent, secure workstations
DevOps: Treating desktops like immutable infrastructure
Security teams: Reducing attack surface and incident response time
Homelabbers: Learning enterprise tech, stable personal systems

Learn More

Deep dive into architecture, deployment strategies, and real-world use cases:

🔗 Making Linux Work as a Corporate Desktop

linux #cybersecurity #silverblue #immutableos #devops #selinux #flatpak #ostree #infosec

Prototyping Enterprise Infrastructure in Proxmox: 11+ VMs, 8 VLANs, and Ansible Automation

Richard Chamberlain — Sun, 04 Jan 2026 17:53:10 +0000

After seven years running Proxmox in my homelab, I'm tackling my most complex project yet—prototyping a complete SMB infrastructure with 11+ VMs, 8 network segments, and comprehensive automation.

Why Prototype Virtually?

Testing infrastructure in VMs before production deployment catches problems early:

Network misconfigurations discovered in VLANs before buying physical switches
Resource constraints identified before ordering hardware
Backup failures found during testing instead of disasters
Automation issues debugged in isolated environments
Disaster recovery practiced without actual disasters

The Infrastructure

Network Design (8 VLANs)

10.0.100.0/24 – Management and monitoring
10.0.110.0/24 – Base infrastructure servers
10.0.120.0/24 – Application servers
10.0.130.0/24 – General workstations
10.0.131.0/24 – Manager workstations
10.0.132.0/24 – IT workstations
10.0.140.0/24 – Guest Wi-Fi and IoT
10.0.150.0/24 – Public-facing services

All inter-VLAN routing handled by an OPNSense VM. This lets me test firewall rules, routing policies, and network segmentation before deploying to physical infrastructure.

User Management

Proxmox supports PAM and Proxmox VE users. I use both:

PAM admin: SSH access + web UI (root disabled)
PVE users: Limited permissions, no shell access
Ansible user: API-only access for automation

Pro tip: Shut down pveproxy when not using the web UI:

systemctl stop pveproxy   # Stop when not needed
systemctl start pveproxy  # Start when needed

Resource Pools (Used Correctly)

I previously misused resource pools as tags. They're actually for delegation and access control:

smb-servers: Core infrastructure
smb-workstations: Desktop/laptop VMs
smb-project-admin@pve: Full access across pools
smb-admin@pve: Server pool only

Backup Strategy

Dual-layer backups for redundancy:

Local (10TB): 7 daily, 4 weekly, 2 monthly
External (4TB): 1 daily, 2 weekly, 1 monthly

And I actually test restore procedures. Backups are worthless if you've never validated them.

Automation

Ansible user with Proxmox API access enables infrastructure as code:

VM provisioning from templates
Network configuration (VLAN assignments)
Resource management
Backup scheduling

Configurations stored in GitHub—destroy everything and rebuild from source.

Is This Overkill?

For a homelab? Yes. For learning? Absolutely not.

Overengineering in the lab teaches enterprise concepts (VLANs, RBAC, disaster recovery, automation) without production risk. When something breaks, fixing it builds troubleshooting skills.

Hardware

Dual-socket Lenovo D20 (24 cores) with:

CPU host passthrough for VMs
Memory ballooning across VMs
Initial allocation: 4GB servers, 8GB workstations

What's Next

I'm documenting the full build over 3-6 months:

SMB infrastructure planning
Ansible automation setup
Samba Active Directory deployment
File and print services
Linux workstation configuration
SELinux hardening
Monitoring and backup automation

Read the Full Article

Complete details on my Proxmox prototyping methodology: Prototyping a Larger Project with Proxmox

proxmox #virtualization #infrastructure #linux #devops #networking #ansible

Building Enterprise Security for Small Business with Linux and Open Source

Richard Chamberlain — Sun, 28 Dec 2025 19:11:09 +0000

The most dangerous phrase in the language is, 'We've always done it this way.'" — Grace Hopper

For small businesses, "doing it the Windows way" might be the dangerous default.
The Challenge

Small businesses face enterprise-level security threats but rarely have enterprise budgets. They need:

Centralized user management
Access control and permissions
Audit logging for compliance
Secure remote administration
Consistent configuration management

Traditional answer: Windows Server, Active Directory, third-party security tools. Cost: thousands per year in licensing.
The Alternative

Linux provides enterprise security capabilities without licensing costs:

Authentication: Samba AD (Linux-based domain controller) Authorization: DAC/ACL (file permissions) Protection: SELinux/AppArmor (mandatory access control) Monitoring: Auditd (security event logging) Management: Ansible (infrastructure-as-code) Services: CUPS (printing), SSH (remote access)
The Project

I'm building this as a complete proof-of-concept over 3-6 months:

Environment: 11-VM Proxmox setup Target: Small business (10-50 employees) Goal: Enterprise-grade security at SMB budget

Components:

Samba AD domain controller
File servers with centralized auth
Print server (CUPS)
Ansible control node for automation
Domain-joined Linux desktops
Monitoring and backup systems

Why This Matters

For business owners: Understand there are alternatives to expensive licensing For IT professionals: See what Linux can deliver in real-world business environments For Linux enthusiasts: Practical guide to enterprise infrastructure
The Series

Article 1: Introduction (this one) - Why this project matters
Article 2: Proxmox virtualization best practices
Article 3: SMB infrastructure planning
Article 4: Ansible automation setup
Articles 5-8: Core services deployment
Articles 9-10: Desktop environment configuration
Articles 11-12: Security hardening and monitoring

The Question

Does business actually need this?

Given:

SaaS moving apps to browsers (less OS dependency)
Cost pressures to reduce licensing
Security requirements increasing
Mature Linux tools available

Maybe the question is: Why aren't more small businesses considering this?

What would you want to see in this series? What concerns or questions should I address?

linux #security #opensource #devops #sysadmin #business