<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Linux on /var/log/janio</title><link>https://devops.sarmento.org/en/tags/linux/</link><description>Recent content in Linux on /var/log/janio</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 26 May 2026 06:23:46 +0000</lastBuildDate><atom:link href="https://devops.sarmento.org/en/tags/linux/index.xml" rel="self" type="application/rss+xml"/><item><title>Secret Management on macOS and Linux: a Practical-Theoretical Approach</title><link>https://devops.sarmento.org/en/posts/secret-management-macos-linux/</link><pubDate>Sun, 17 May 2026 11:54:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/secret-management-macos-linux/</guid><description>&lt;p&gt;At some point in the life of almost every sysadmin, there comes a slightly uncomfortable realization: too many secrets are scattered across the environment.&lt;/p&gt;
&lt;p&gt;A password inside a &lt;code&gt;.env&lt;/code&gt; file here, a token buried in shell history there, a forgotten webhook inside a &lt;code&gt;docker-compose.yml&lt;/code&gt;, an API key hardcoded into a “temporary” script that somehow survived for two years in production. None of those things seem catastrophic individually. The problem is that infrastructure rarely collapses because of one gigantic mistake; most of the time, it collapses under the accumulated weight of dozens of tiny operational shortcuts.&lt;/p&gt;</description></item><item><title>Cleaning up old Snap revisions to free up space on Ubuntu</title><link>https://devops.sarmento.org/en/posts/cleaning-up-old-snap-revisions-to-free-up-space-on-ubuntu/</link><pubDate>Fri, 17 Apr 2026 11:05:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/cleaning-up-old-snap-revisions-to-free-up-space-on-ubuntu/</guid><description>&lt;p&gt;If you&amp;rsquo;ve been using Ubuntu for a while, you&amp;rsquo;ve probably noticed that the &lt;code&gt;/var/lib/snapd&lt;/code&gt; directory grows silently and steadily. The reason isn&amp;rsquo;t the Snap packages you&amp;rsquo;ve installed — it&amp;rsquo;s the old copies the system automatically keeps every time one of those packages is updated. On a system with dozens of snaps, it&amp;rsquo;s common to find 5, 8, or even more gigabytes occupied by revisions you&amp;rsquo;ll never use. This issue is especially troublesome on smaller partitions, SSDs with limited space, or VMs with tight disk capacity. The good news is that identifying and removing this excess takes just a few minutes, as long as you know where to look and what not to delete.&lt;/p&gt;</description></item><item><title>Monitoring Files and Folders on Linux with systemd path units (and inotifywait for those without root)</title><link>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/</link><pubDate>Fri, 17 Apr 2026 11:05:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/"&gt;previous post&lt;/a&gt;, macOS&amp;rsquo;s launchd watched files and directories with &lt;code&gt;WatchPaths&lt;/code&gt; to fire scripts automatically when something changed. The model is reactive — instead of running a backup every hour or a conversion every five minutes, the system watches the path on disk and only runs the job when it detects an actual modification. No polling, no waste, no vulnerability window between the change and the action.&lt;/p&gt;
&lt;p&gt;Linux has the same capability, but implemented differently and with more options. systemd offers path units — &lt;code&gt;.path&lt;/code&gt; files that monitor filesystem paths and automatically activate an associated service when the condition is met. It is the direct equivalent of launchd&amp;rsquo;s &lt;code&gt;WatchPaths&lt;/code&gt;, with the same declarative philosophy: you describe what to watch in a configuration file, the system handles the rest. For anyone working on servers or desktops with systemd, which at this point means practically every mainstream distribution, path units are the right tool.&lt;/p&gt;</description></item><item><title>Tailscale in the Homelab — Remote Access Without Opening Ports</title><link>https://devops.sarmento.org/en/posts/tailscale-in-the-homelab-remote-access-without-opening-ports/</link><pubDate>Sun, 29 Mar 2026 21:58:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/tailscale-in-the-homelab-remote-access-without-opening-ports/</guid><description>&lt;p&gt;Anyone who runs a homelab — or even a single Raspberry Pi hosting services — eventually hits the same obstacle: how do you access those devices from outside the local network? The classic answer involves opening ports on the router, setting up port forwarding, dealing with dynamic IPs via DDNS, and hoping no bot discovers that SSH port exposed to the internet. It works, but the attack surface grows with every open port, and the maintenance becomes a silent headache that only shows up when something breaks.&lt;/p&gt;</description></item><item><title>Systemd Timers: Time to Retire cron</title><link>https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/</link><pubDate>Mon, 23 Mar 2026 06:21:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/</guid><description>&lt;p&gt;If you have been managing Debian or Ubuntu servers for any length of time, you probably have a comfort relationship with cron. One line in the crontab, five scheduling fields, and the path to a script — done. cron has worked this way since the 1970s, and that simplicity is exactly what kept it relevant for so long.&lt;/p&gt;
&lt;p&gt;The problem is that &amp;ldquo;it works&amp;rdquo; and &amp;ldquo;it works well in 2026&amp;rdquo; are different things. When a job fails silently at three in the morning, when you need to figure out which of twenty crontabs scattered across the system contains that one specific task, or when the server reboots and simply misses the execution that should have happened during downtime — those are the moments when cron shows it was designed for an era with different expectations around observability and resilience.&lt;/p&gt;</description></item><item><title>Comments on static sites with Isso — lightweight, self-hosted, and tracking-free</title><link>https://devops.sarmento.org/en/posts/comments-on-static-sites-with-isso-lightweight-self-hosted-and-tracking-free/</link><pubDate>Sat, 21 Mar 2026 00:00:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/comments-on-static-sites-with-isso-lightweight-self-hosted-and-tracking-free/</guid><description>&lt;p&gt;A static site has no backend. No database, no application server processing requests — and that&amp;rsquo;s exactly what makes it fast, cheap, and resilient. But that simplicity comes at a cost when you need anything that depends on persistent state, and comments are the most obvious case. In WordPress or Ghost, the commenting system is part of the application. In a site generated by Hugo, Jekyll, or Eleventy, that layer simply doesn&amp;rsquo;t exist.&lt;/p&gt;</description></item><item><title>Hello, World!</title><link>https://devops.sarmento.org/en/posts/hello-world/</link><pubDate>Thu, 19 Mar 2026 01:00:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/hello-world/</guid><description>&lt;p&gt;This is the English side of &lt;strong&gt;/var/log/janio&lt;/strong&gt; — a blog about Linux, macOS, self-hosting, homelab, and the small tools that make daily life in the terminal a little better.&lt;/p&gt;
&lt;p&gt;Most of the content lives on the Portuguese side for now. Posts will be translated or written directly in English as the blog grows. If you read Portuguese, there&amp;rsquo;s a lot more waiting for you on the other side of the language switcher.&lt;/p&gt;</description></item></channel></rss>