The SecureByDefault Brief #014: Automatic updates were on. My server was still running an old kernel.

Gmail is free, but you pay with your data. Proton Mail is different.

We don’t scan your messages. We don’t sell your behavior. We don’t follow you across the internet.

Proton Mail gives you full-featured, private email without surveillance or creepy profiling. It’s email that respects your time, your attention, and your boundaries.

Email doesn’t have to cost your privacy.

Ditch the Gmail data grab

Every time I log in to my test server, it greets me with the same three messages.

For a while I treated that like the "check engine" light I'd learned to ignore. After #013, where the lesson was that what you can see isn't always what's true, I decided to find out what those lines actually meant.

First, refresh the list of available packages. This does not install anything:

Mine ended with 13 packages can be upgraded. To see them:

The list was ordinary: apparmor, cloud-init, snapd, tmux, the libglib2.0 packages, and a few others. No kernel.

If you want to know what an upgrade would do before it does it, ask apt to simulate it:

The -s means simulate. The lines that start with Conf are what it would configure. Nothing is installed.

Updates replace files on disk. But a program that's already running keeps using the old copy it loaded into memory. The kernel and core libraries are the big examples. A new version can be sitting on disk while the old one is still in charge.

Ubuntu leaves a flag file when a reboot is needed, and a second file saying why:

The first printed *** System restart required ***. The second listed libc6 and three kernel images: 6.8.0-142, 146, and 147.

Then I compared the kernel I was running with the ones installed:

The first command said I was running 6.8.0-134-generic. The second showed two kernels installed: 134 and 147.

I was running kernel 134. Kernel 147 was already installed and waiting. The server had been collecting kernel updates it never used.

That was the part that bothered me. I thought this was handled. So I checked:

It said enabled. The config file /etc/apt/apt.conf.d/20auto-upgrades had both Update-Package-Lists "1" and Unattended-Upgrade "1", and two timers (apt-daily and apt-daily-upgrade) were scheduled to run every day.

So why was I behind? Two reasons showed up.

It doesn't reboot by default. I searched for the setting:

The lines were commented out, with Automatic-Reboot "false" as the example value. Installing a new kernel is one thing. Booting into it is another, and on my server, nothing does that for you.

It only handles some updates. I read the log:

The log listed the origins it's allowed to install from: the base release, the security pocket (noble-security), and the two Ubuntu ESM pockets. And then:

Yet 13 packages were waiting. apt list had shown where they came from: noble-updates, which isn't on that list. So "automatic updates are on" did not mean "everything is applied." It meant "security updates from these sources are applied." That's a good default, but it's not the same thing, and it's worth checking on your own server instead of assuming.

The banner's second line, "2 additional security updates can be applied with ESM Apps," points at Ubuntu Pro, which is a separate Canonical service. I looked, but didn't touch anything:

It said the machine wasn't attached to an Ubuntu Pro subscription, with esm-apps available. When I ran apt upgrade later, it named the two packages: libhavege2 and haveged. So those two stay unpatched on my server until I enable that service, and I didn't for this lab. Canonical's site says there's a free personal tier, but check https://ubuntu.com/pro for the current terms before you decide.

The banner also said a new release, 26.04.1 LTS, was available, with a prompt to run do-release-upgrade. That's a major version upgrade, not a routine patch. I did not run it, and I wouldn't on a server I depend on without a backup and a plan.

On a disposable test server, I applied the 13:

It showed me the list, said 13 upgraded, 0 newly installed, 0 to remove and 0 not upgraded, estimated 37.9 MB to download, and asked me to confirm. Afterward, a second run said there was nothing left to do.

Even with those 13 installed, the restart flag was still set. Updating packages doesn't clear it. Only the reboot does.

This is the step that deserves the same caution as #012.

Before I rebooted, I did what I did in #012: I kept a second SSH session open and knew where my provider's web console was, in case the server didn't come back.

Then:

The server printed The system will reboot now!, and my connection dropped. I watched from my PC, checking whether SSH answered:

It printed False, then True. The server was unreachable for about five minutes. That's a long time if something depends on it, so plan for it.

Same habit as #012: don't assume it worked, check.

uptime said the server had been up for 2 minutes. uname -r now said 6.8.0-147-generic. And the flag file was gone:

Then I checked that the reboot hadn't undone anything I'd set up:

UFW was still active with only OpenSSH allowed. ss showed the same listeners as #013, with new process IDs. And systemctl --failed said 0 loaded units listed.

A reboot is a good time to confirm your hardening survived it.

Use a disposable Ubuntu server, not one anyone depends on. It took me about 47 minutes, including the reboot. Give yourself an hour the first time.

Save the before and after output and what surprised you. Then write down what you'd want to automate and what you'd rather do by hand.

Only do this on your own server, and don't run do-release-upgrade or attach Ubuntu Pro unless you've decided to.

Ubuntu Pro and ESM
https://ubuntu.com/pro

This is the page the login banner points to. It explains what the paid and free tiers cover. Read it before you enable anything.

Why spend your evenings on kernels, updates, and reboots? Because employers keep asking for people who can keep servers running and explain what they found. Here are four current remote support roles, from early career to mid level.

Listings can close quickly. I checked each one on the employer's own page while preparing this issue, but always check the employer's page before applying.

Remote U.S. | $42K-$52K | about 2 years

First-line support at an AI cloud infrastructure company. They ask for roughly two years with shell scripting, Python, and SQL, plus an understanding of SSH and the terminal and experience with Linux server versions. The posting says the pay range may cover several career levels. Know before you apply: it may require weekend work (Saturday or Sunday) and an assigned shift.

View the role

Remote U.S. | $53.5K-$67.1K | degree, bootcamp, or 2+ years of related experience

Support for EasyPost's GlobalShip enterprise shipping software. You'd work with support techs and integration engineers on client configurations, daily shipping tasks, and troubleshooting, and help test and deploy software updates. They ask for basic SQL and basic Windows computer and server administration. You must be authorized and based in the United States.

View the role

Remote | $95K-$115K | hands-on support experience

A technical support role (the posting says it is not a software engineering job) at a legal technology company. You'd investigate customer issues, resolve what you can, and hand off the rest to engineers with a clear, well-scoped ticket, working with customers' IT teams and tools like Jira, logs, and dashboards. They ask for working knowledge of at least one programming language, SQL, and email delivery basics such as bounces, SPF, and DKIM. The posting doesn't state a minimum number of years, and I couldn't confirm which countries it's open to, so check eligibility.

View the role

Remote U.S. (limited states) | $30-$40 per hour | 3+ years

Technical support at a cloud infrastructure company. They want 3+ years of enterprise or advanced support experience and strong Linux command-line troubleshooting, with containers and Kubernetes as a plus. Know before you apply: it's a 24/7 operations environment with scheduled shift coverage, and Vultr is currently accepting applications only from residents of a list of U.S. states, so check yours.

View the role

What these have in common

Look at the four together and the same things keep coming up: Linux and the command line, SSH, SQL, reading logs, writing clearly, and knowing when to escalate. None of that guarantees a job. Nothing does. But these skills keep showing up because employers keep needing them, and every one of them is something you can practice on a cheap server or a free VM this weekend.

I'm also building SecureByDefault Learning Paths, a free GitHub repo that organizes Linux, networking, troubleshooting, cloud, hands-on projects, and career paths into a learning order. It's a work in progress and I add to it regularly.

https://github.com/SecureByDefault-io/securebydefault-learning-paths

New to Linux?

The free Linux Starter Kit includes the commands, a practice plan, log examples, and a beginner server checklist.

If someone forwarded you this issue, you can subscribe here: https://newsletter.securebydefault.io/

Disclosure: the two links in this section are my referral links. If you sign up through one and meet that program's requirements, I may receive a referral reward. I'm trying them in this issue to learn whether you want side-work options in this newsletter, and I'll be watching how many of you click.

This is a different category from the roles above. These are contract platforms, not jobs. Project availability and hours vary, and neither one guarantees you any work or income.

Handshake AI

Handshake describes its AI Fellowship as flexible, project-based contract work, not a full-time job, with no guaranteed hours. Task availability depends on the needs of its partner labs. Eligibility depends on your location and work authorization, so read their requirements before you sign up.

Check out Handshake AI (referral link)

Mercor

Mercor lists contract projects for independent contractors. Its own postings say a project's length can change and that projects can be shortened or ended early. Pay and requirements vary by project.

Explore Mercor (referral link)

Both links above are referral links, as described at the top of this section.

We've covered who's knocking, what SSH accepts, what's listening, and what's running old code. Next time: who has actually been on this server, and what did they do? The login history, the sudo trail, and how to read both on your own machine.

Talk soon,

Ron
SecureByDefault