Linux Server Patch and End-of-Life Dashboard for Small IT Teams

The problem: nobody knows which server is behind

Small IT teams, a university lab, a software house with a dozen client VPS, an NGO with servers at two providers, often manage machines they did not set up. Each server was patched when someone remembered. Some have not rebooted in a year and are running an old kernel even though updates were installed. One is still on an Ubuntu release whose standard support has ended, and nobody noticed because nothing broke.

The information exists on each machine: the package manager knows what is pending, the OS writes a flag when a reboot is needed, and the release version is in a file. What is missing is one place that collects it, ranks the risk and tells a busy person what to do this week.

What already exists and the gap

• Canonical Landscape manages Ubuntu fleets with package updates, grouping and compliance, but it is Ubuntu-focused and designed for organisations with a formal support relationship.
• Ansible can gather facts and apply updates across servers, but it is a tool you drive, not a dashboard that watches and reminds.
• Wazuh includes vulnerability detection among many security features, and running it well is a project in itself.
• endoflife.date publishes lifecycle dates for hundreds of products with a JSON API, but it knows nothing about your servers.

The gap is a small, cheap tool that answers three questions for a mixed fleet: what is unpatched, what needs a reboot, what is running out of support.

What you build

• Agent: a single binary or script run by a systemd timer every few hours. It reads the OS release file, asks apt or dnf for pending updates, separates security updates, checks the reboot-required flag and sends a signed JSON report.
• API: registers servers, validates tokens, stores reports and keeps history so you can show how long an update has been pending.
• Dashboard: a fleet table with filters by provider, tag and risk, plus a server page with its history.
• Lifecycle service: fetches end-of-life dates from endoflife.date, caches them and matches them to each server's OS version.
• Weekly report: an email to each team with overdue items and a clear action list.

The technically interesting part

The interesting part is turning raw package data into a risk ranking people trust. "Pending updates" is noisy: forty updates might all be documentation packages, while one might be a kernel security fix. You need to classify updates reliably on each distro, track how long each has been pending, combine that with reboot status and OS lifecycle, and produce a ranking with a reason attached ("security updates pending 23 days, reboot needed since kernel update"). Show evaluators how the ranking is computed and test it against cases you construct deliberately.

How to evaluate it

• Accuracy: on ten or more servers, compare the agent's counts of pending security updates with the package manager's own output. Any mismatch must be explained.
• Overhead: CPU time, memory and network per agent run on the smallest VPS you can find.
• Timeliness: time from a new security update being published to it appearing on the dashboard.
• Usefulness: give the weekly report to three people who manage servers and ask them which item they would act on first; check it matches your ranking.

Suggested plan

1. Weeks 1 to 3: agent for Ubuntu and Debian, API and database.
2. Weeks 4 to 6: history, risk ranking and the fleet dashboard.
3. Weeks 7 to 9: lifecycle service, RPM-based distro support and tagging.
4. Weeks 10 to 12: weekly report, security review of agent authentication, test fleet.
5. Weeks 13 to 14: evaluation and write-up.

Path to a product

The first users are a software house or hosting reseller that manages client VPS and wants a monthly proof of maintenance. Price per server per month with a free tier of a few servers so individual developers try it. Managed service providers are the natural next market because patch reports are something they already promise clients.

Scope warning

Do not build a remote shell, configuration management or a vulnerability scanner that maps every package to every CVE. Do not auto-apply updates in the first version; visibility first, action later. Windows support is a separate project.

Learn what you need on Sefism

• DevOps and cloud roadmap : Linux administration and automation fundamentals.
• roadmap.sh: Linux : package managers, systemd and the files your agent reads.
• Linux Upskill Challenge : hands-on practice running and patching a real server.
• jq Manual : inspect the agent's JSON reports quickly while debugging.
• Where to start in cybersecurity or IT operations : how a project like this fits an IT operations career.

Get help with this idea

Keep the agent tiny and the ranking honest, and this becomes a tool people keep using after your viva. A mentor can help you pin down the scope, choose a stack you can finish with, and design an evaluation your examiners will respect. You build it; we help you think it through. New here? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session