Linux Security

When a service spits out a JSON blob that contains a list of users, the data is usually nested and has more fields than you actually need. Turning that into a flat CSV is a common thing to do for automation scripts, reporting, or feeding into spreadsheets. The two most reliable command‑line tools for this job are jq (a JSON processor) and awk (a text filter). Together they give you a fast, secure, and scriptable pipeline.

The sticky bit in a nutshell

The sticky bit (+t) on a directory means that only the file’s owner, the directory’s owner, or root can delete or rename files inside it. /tmp is traditionally set to 1777 (octal) – owner root, group root, permissions rwxrwxrwt. That lets any user create files, but stops them from messing with each other’s data.

What happened after the update

Some kernel releases changed the default mount options for tmpfs or how tmpfs‑based /tmp is handled. If /tmp is mounted as tmpfs without the sticky bit, the kernel quietly clears the +t flag. The directory stays world‑writable, but the protection that stops users from deleting each other’s files disappears. Applications that expect the sticky bit now refuse to write, because they see the directory as insecure.

Why Move /var/log to a tmpfs?

On most production boxes and home‑lab rigs the root file system is a single ext4 or btrfs partition that also holds /var/log. After a few months the logs can eat up gigabytes of space, especially on servers that churn out audit, kernel, or app logs. A full root partition can block package upgrades, kernel updates, or even prevent a boot if the filesystem gets remounted read‑only. Moving /var/log to a tmpfs frees the disk right away, keeps the logs in RAM, and cuts out the need to compress or rotate them manually.

Why a kernel update can drop you into emergency mode because /boot won’t mount

A fresh kernel can change the initramfs or the boot‑loader’s config, and if the loader can’t find the /boot partition the system drops into that classic emergency shell:

Emergency shell (root=rw) – press Ctrl‑D to continue

Below is a no‑fluff, hands‑on walk‑through that keeps the commands you need, the trade‑offs, and a few security reminders.

1. Inspect the emergency environment

First, make sure the culprit is really the /boot mount. In the emergency shell run:

I’m ready to help refine the article, but I’ll need the original text first. Could you paste it here?

I’m ready to help polish it, but I’ll need the article text first. Could you paste the draft you’d like me to rewrite?

When a VPS loses its /etc directory, the system can become unbootable or at least unusable until the configuration files are restored. If you have been running Borg backups (the recommended tool for incremental, deduplicated snapshots) the recovery path is clear: locate the snapshot that contains the last good /etc, extract it, and replace the missing directory. This walkthrough shows the exact commands, trade‑offs, and security checks you should perform on a current 2026 VPS environment.

Why Bluetooth headphones keep dropping on GNOME 48

Bluetooth audio on GNOME 48 is now handled by PipeWire instead of the old PulseAudio stack. The new stack is cleaner, but it also turns on a “low‑power” mode that can make a headset drop after a few minutes of idle time or when you close the laptop lid. The real culprit is usually the kernel’s power‑management for the Bluetooth controller and PipeWire’s default settings.

The underlying problem

When a systemd timer stops firing after a kernel upgrade, the first thing that comes to mind is “something broke during the reboot.” In reality the timer is still in the unit files; it’s the time‑keeping that gets reset. The kernel’s real‑time clock (RTC) is re‑synchronised, and any timers that were scheduled for a time in the past are dropped unless you tell systemd to treat them as persistent.

Quick Memory Hunt with systemd‑cgtop

When a server starts to feel sluggish, most folks jump straight to CPU or disk I/O. Memory is the silent saboteur that slips under the radar until it’s too late. On modern Linux, every service lives in a cgroup, and systemd‑cgtop gives you a live, per‑service view of how that cgroup is eating RAM. Unlike top or ps, it aggregates the numbers for you, so you can spot the offender in a glance.