<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Automation on /var/log/janio</title><link>https://devops.sarmento.org/en/tags/automation/</link><description>Recent content in Automation 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/automation/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>Hugin on steroids: tags, links and editing in one TUI</title><link>https://devops.sarmento.org/en/posts/hugin-on-steroids-tags-links-and-editing-in-one-tui/</link><pubDate>Sat, 18 Apr 2026 13:13:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/hugin-on-steroids-tags-links-and-editing-in-one-tui/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/"&gt;post about Hugin&lt;/a&gt; I introduced the tool I use to generate tags and summaries for my Hugo blogs. Two weeks later, in the &lt;a href="https://devops.sarmento.org/en/posts/munin-internal-links-for-hugo-with-ai/"&gt;post about Munin&lt;/a&gt;, I showed its sibling: a second program that discovers and inserts internal links between posts using embeddings and an LLM.&lt;/p&gt;
&lt;p&gt;Both worked well. Separately, they worked well.&lt;/p&gt;
&lt;h2 id="the-problem-with-having-two-programs"&gt;The problem with having two programs&lt;/h2&gt;
&lt;p&gt;In theory, splitting responsibilities between tools is good practice. In practice, the workflow for processing a new post looked like this: open Hugin, navigate to the post, generate tags, generate summary, close Hugin. Open Munin, wait for the embedding model to load, navigate to the same post, check existing links, generate link suggestions, apply. If you needed to fix a typo in the title that only showed up after reviewing the post in Hugin, close everything and open Pages CMS or vim.&lt;/p&gt;</description></item><item><title>Hugin: tags and summaries for Hugo with AI</title><link>https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/</link><pubDate>Fri, 17 Apr 2026 11:06:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/</guid><description>&lt;p&gt;Anyone who maintains a &lt;a href="https://devops.sarmento.org/posts/why-leave-wordpress-and-what-to-build-instead-with-hugo-pages-cms-and-cloudflare/"&gt;static blog with Hugo&lt;/a&gt; knows there are two tasks nobody enjoys: classifying posts with tags and writing meta descriptions. These are the things you skip when publishing because the post is already done, the deploy is set up, and choosing between &amp;ldquo;selfhosted&amp;rdquo; and &amp;ldquo;self-hosted&amp;rdquo; isn&amp;rsquo;t exactly the best use of your time. The result is predictable: posts without tags, empty descriptions or ones copied from the first paragraph, and a taxonomy that hurts more than it helps.&lt;/p&gt;</description></item><item><title>Munin: internal links for Hugo with AI</title><link>https://devops.sarmento.org/en/posts/munin-internal-links-for-hugo-with-ai/</link><pubDate>Fri, 17 Apr 2026 10:49:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/munin-internal-links-for-hugo-with-ai/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/hugin-tags-and-summaries-for-hugo-with-ai/"&gt;post about Hugin&lt;/a&gt; I explained how I solved the tag and summary problem on my Hugo blog. But there was another problem, less obvious and more annoying: internal links. Those links that connect one post to another, help readers navigate related content, and that Google loves to see on a well-structured site.&lt;/p&gt;
&lt;p&gt;The truth is nobody links anything. You write a post about systemd timers, another about cron, another about launchd — and none of the three mentions the others. They&amp;rsquo;re content islands that could be connected. The obvious solution is to reread every post, remember which others exist, and manually insert links. With 30 posts, it&amp;rsquo;s doable. With 400, it&amp;rsquo;s insane.&lt;/p&gt;</description></item><item><title>Automatically deleting emails in Apple Mail with AppleScript + launchd</title><link>https://devops.sarmento.org/en/posts/automatically-deleting-emails-in-apple-mail-with-applescript-and-launchd/</link><pubDate>Mon, 30 Mar 2026 20:24:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/automatically-deleting-emails-in-apple-mail-with-applescript-and-launchd/</guid><description>&lt;p&gt;My inbox is always full of notifications with subjects like &lt;code&gt;[Ticket ID: 12345] Ticket Update&lt;/code&gt;. They&amp;rsquo;re useful for a few hours and then become noise. These aren&amp;rsquo;t emails that need to be archived, replied to, or revisited, so they just end up taking up mental space.&lt;/p&gt;
&lt;p&gt;Deleting them manually is the kind of small task that never becomes a priority, but silently costs you in distraction. So I decided to treat it like any other recurring problem: automate it locally, without relying on external services, no &lt;em&gt;webhooks&lt;/em&gt;, and no integrations. The idea is to periodically run a script that moves to the trash any &lt;a href="https://devops.sarmento.org/experiencias-com-mensagens-subliminares/"&gt;messages&lt;/a&gt; whose subject matches a specific pattern and that are older than 48 hours.&lt;/p&gt;</description></item><item><title>Automatically Converting Images to WEBP and AVIF</title><link>https://devops.sarmento.org/en/posts/automatically-converting-images-to-webp-and-avif/</link><pubDate>Thu, 26 Mar 2026 22:19:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/automatically-converting-images-to-webp-and-avif/</guid><description>&lt;p&gt;The two previous posts built the monitoring infrastructure — &lt;a href="https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/"&gt;&lt;code&gt;WatchPaths&lt;/code&gt; on macOS&lt;/a&gt;, &lt;a href="https://devops.sarmento.org/en/posts/monitoring-files-and-folders-on-linux-with-systemd-path-units-and-inotifywait/"&gt;systemd path units and &lt;code&gt;inotifywait&lt;/code&gt; on Linux&lt;/a&gt; — and promised the scripts would come later. The trigger is ready: launchd or systemd detects when something changes in a directory and fires a command. What is missing is the command itself.&lt;/p&gt;
&lt;p&gt;This post delivers the image conversion script that those triggers will fire. The goal is simple: PNGs and JPGs go into a folder, WEBP or AVIF come out. The originals are deleted or moved, depending on the configuration. The script detects which encoders are available on the machine and picks the best one among those installed, with a fallback chain that ensures it works even when the ideal tool is not present. If no compatible encoder is found, the script tells you what to install and from which package manager.&lt;/p&gt;</description></item><item><title>Monitoring Files and Folders with launchd: WatchPaths in Practice</title><link>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/</link><pubDate>Thu, 26 Mar 2026 18:56:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/"&gt;previous post about launchd&lt;/a&gt;, scheduling worked by time: &lt;code&gt;StartCalendarInterval&lt;/code&gt; defined &amp;ldquo;every day at 7 AM&amp;rdquo; and the system took care of the rest, including recovering missed executions when the Mac was asleep. For periodic tasks like sending a daily briefing or running a maintenance script, that model works perfectly — it is the functional equivalent of cron, but integrated into the macOS lifecycle.&lt;/p&gt;
&lt;p&gt;But not every automation makes sense tied to a clock. Some tasks only need to happen when something changes. A backup that runs every hour is wasting 23 executions per day if the database was only modified once. An image conversion that runs every 5 minutes has nothing to convert most of the time, and when it finally does, up to 5 minutes have passed since the file appeared. The time-based model works, but it is polling disguised as scheduling — and polling is almost always the least elegant solution to any synchronization problem.&lt;/p&gt;</description></item></channel></rss>