<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Macos on /var/log/janio</title><link>https://devops.sarmento.org/en/tags/macos/</link><description>Recent content in Macos 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/macos/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>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>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><item><title>Scheduling Tasks on macOS with launchd: No cron, No Workarounds</title><link>https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/</link><pubDate>Mon, 23 Mar 2026 21:29:00 +0000</pubDate><guid>https://devops.sarmento.org/en/posts/scheduling-tasks-on-macos-with-launchd-no-cron-no-workarounds/</guid><description>&lt;p&gt;In the &lt;a href="https://devops.sarmento.org/en/posts/systemd-timers-time-to-retire-cron/"&gt;previous post&lt;/a&gt; I showed how systemd timers replace cron on Debian and Ubuntu servers with concrete advantages: integrated logging, missed execution recovery, declarative dependencies, and resource control. The logic is compelling and the migration is straightforward — as long as you are on a system running systemd. But if your daily routine includes a Mac, it is a different story.&lt;/p&gt;
&lt;p&gt;macOS has its own scheduling system, predating systemd and built on a different philosophy. It is called &lt;a href="https://devops.sarmento.org/posts/monitoring-files-and-folders-with-launchd-watchpaths-in-practice/"&gt;launchd&lt;/a&gt;, it has been around since Mac OS X Tiger in 2005, and it is responsible for practically everything that runs in the background on the system — from internal Apple services to that Spotify updater you never asked to install. Despite being the official and recommended way to schedule tasks on a Mac, launchd lives in a kind of blind spot: people coming from Linux tend to reach for cron out of reflex, and Mac users without a sysadmin background do not even know the option exists.&lt;/p&gt;</description></item></channel></rss>