I use Apple devices very often. Overall, I like macOS. Certainly more than Windows.

One of the things I find extremely useful is a command I discovered not too long ago: pbcopy.

pbcopy can be used to copy to the clipboard whatever it receives from standard input. For example, when I am in a shell, I often use a command like this:

cat filename.md | pbcopy

There is one limitation, though: this only works locally. It works when I am using my Mac and I want to copy something from the macOS shell.

When I connect to a remote (*BSD, Linux, illumos based) server via ssh, pbcopy is not available. Or, more precisely, even if I create a command with the same name on the server, that command cannot directly talk to the clipboard of my Mac in the usual way.

Luckily, modern terminal emulators have a few tricks available.

I use iTerm2 for most of my ssh sessions and, once I realised how useful it would be to have something similar to pbcopy in remote sessions too, I created a small script that works both on Linux, the BSDs and illumox based OSes.

The caveat is that the remote server cannot "magically" access the clipboard of my Mac. So the trick works because the remote command prints a special terminal escape sequence, and the local terminal emulator interprets it.

The sequence is called OSC 52. In short, it allows a program running inside the terminal to ask the terminal emulator to put some base64-encoded text into the local clipboard. This means that support depends on the terminal emulator I am using locally.

I use iTerm2, which supports OSC 52. Other terminal emulators support it too, so the idea is not tied exclusively to iTerm2. However, Apple's default Terminal.app does not appear to support OSC 52, so I would not expect this specific solution to work there.

So, in practice:

• with iTerm2, it works;
• with other OSC 52-compatible terminals, it should work (I haven't tested it, but should work with kitty, Ghostty, etc.);
• with Apple's Terminal.app, at least at the time of writing, it should not.

Settings -> General -> Selection -> Applications in terminal may access clipboard

This option allows programs running inside the terminal to access the clipboard through escape sequences.

Of course, this has security implications. A program running in the terminal, including a program running on a remote server through ssh, may be able to write to the local clipboard. For my use case this is acceptable, but it is worth knowing what is happening.

All I need to do is create a command, a small sh script. I log into the server where I want to create the command. In my case, I usually create a file called /usr/local/bin/pbcopy with the following content:

#!/bin/sh
printf '\033]52;c;%s\a' "$(base64 | tr -d '\n')"

chmod a+rx /usr/local/bin/pbcopy

cat filename.md | pbcopy

https://it-notes.dragas.net/2026/05/26/copying-remote-command-output-to-your-macos-clipboard/

#ITNotes #NoteHUB #macos #networking #server

I have already written about how FediMeteo was born (https://it-notes.dragas.net/2025/02/26/fedimeteo-how-a-tiny-freebsd-vps-became-a-global-weather-service-for-thousands/), and about how HAProxy helps reduce the number of requests that reach snac (https://it-notes.dragas.net/2026/05/18/fedimeteo-haproxy-and-the-art-of-not-wasting-snac-threads/).

Seen from the outside, FediMeteo almost seems still. There is a static homepage, regenerated every hour. There are the city pages, with their forecasts. There are RSS feeds waiting to be fetched, JSON objects waiting to be requested, Fediverse instances refreshing data, subscribing, unsubscribing, retrieving profiles, and reading notes.

That is the visible part.

Behind it, however, FediMeteo (https://fedimeteo.com) is much more than a homepage, a few ActivityPub accounts, and a well-behaved reverse proxy. It is a chain of small pieces, in proper Unix style, each trying to do one thing and do it as well as possible.

That chain, although almost invisible from the outside, was not born already tidy. It changed, was rewritten, adapted to new countries, timezones, ambiguous city names, external service limits, and also to my own mistakes.

Some mistakes were small. Others were much less so.

Because FediMeteo is a human project and, as such, imperfect. Imperfect in the way humans are imperfect, which today almost seems unfashionable. I like that.

The first version of the bot was almost embarrassingly simple, and I was proud of that.

It took a city name as input, asked Nominatim (https://nominatim.org) for the coordinates through geopy, called the Open-Meteo (https://open-meteo.com) API for the current weather and the next several days, and printed a markdown block with current conditions, the forecast for today, the next twelve hours, and the coming days. The text was in Italian. The cities were Italian. The timezone was Europe/Rome. There was nothing to calculate.

Around the script, a small sh wrapper read a list of cities and, for each one, ran the Python program and piped its output into snac note_unlisted. A cron job ran the wrapper every six hours. The output was loose markdown, which snac happily renders, and the integration was: standard output goes into standard input. Nothing fancier than that.

I like this kind of design. It is the part of the Unix philosophy that survives even when fashions change.

When I started adding other European countries, I did not need to change much. I separated the operational logic from the localized strings, moved the strings into one JSON file per country, and spread the cron entries so that not every country posted in the same minute. Each country had its own snac instance, in its own FreeBSD jail, with its own dataset. The bot, internally, was almost the same script as before.

This worked because Europe is, in essence, two or three timezones across most of the countries I cared about.

Then I added Germany, and Germany taught me my first lesson about names.

There are several places called Neustadt in Germany. There is a Frankfurt am Main, and a Frankfurt an der Oder, and they are not the same city. There is a Halle in Saxony-Anhalt and a Halle in North Rhine-Westphalia. Asking Nominatim for "Frankfurt, Germany" produced one of the two, consistently, but not always the one I wanted. Some German users wrote to me, politely, to point out that the forecast for "their" Frankfurt was, in fact, for the other one.

I started thinking about disambiguation, but only enough to fix the immediate cases. The bot still took a single city name. The ambiguous ones I worked around by editing the cities file and hoping for the best.

In hindsight, this was the seed of what would happen later.

The United States broke every assumption the bot had grown up with.

The first problem was the number of cities. I wanted reasonable coverage at state level, which meant identifying the main cities for each of the fifty states. The list ended up at more than 1200 entries. That alone is more cities than every other country in the project combined.

The second problem was timezones. The contiguous United States covers four of them, and Alaska and Hawaii bring the total to six. A "current weather at 12:00" line generated at the same instant for New York and for Los Angeles is technically the same instant, but the two cities are living different parts of the day, and the forecast for "today" is not even quite the same window. A bot that pretended every city was on the same clock would be wrong, sometimes embarrassingly so, every single day.

The third problem was the name thing again, only larger. There are dozens of Springfields. There is a Portland in Oregon and a Portland in Maine. The Germany workaround - editing the cities file by hand and hoping Nominatim picked the right city - was clearly not going to scale to a country where the same name is also a state.

I sat with this for a couple of days before admitting what I already knew.

The bot needed to be rewritten.

What made this hard was not the rewriting itself. It was the requirement to do it without breaking everything else.

By the time I decided to add the United States, the infrastructure around the bot had grown into something I trusted. Jails, snapshots, backup jobs, cron schedules, snac instances on production paths, the HAProxy layer, the homepage cron that aggregated follower counts, and a long list of cities being processed in series every six hours. None of that knew or cared about the bot's internal shape. All of it cared, very much, about the bot's external behavior: a city name and a country code go in, valid markdown comes out, and that markdown ends up in a timeline.

So the contract was clear, even if I had never written it down anywhere. The command-line interface, the output format, the exit codes, the way the wrapper script invoked it, the structure of the JSON country configs - all of it had to keep working. Italian had to keep working. German had to keep working. The cron job that ran every six hours had to keep producing the same shape of output, just with new countries added.

What I changed was almost everything below the surface.

The city argument grew an optional __state suffix, with a double underscore as separator:

python3 main.py springfield__illinois us
python3 main.py springfield__massachusetts us
python3 main.py new_york__new_york us

I am skipping a lot of small detail here, but the principle was always the same: every new degree of freedom had to be expressible as an optional field in the config or as an optional CLI flag. If a country did not set the new field, the old behavior continued, identical to before.

I tested this by running the new bot against the old country configs and comparing the output line by line. Where it differed, it was a bug in the new bot. Not in the test.

The first cycle after deploying the rewrite was, for every country except the United States, indistinguishable from the cycle before. That was the point.

This is the part of the story I dislike telling, which is precisely why I should tell it.

At some point during the development, while debugging an Open-Meteo response that did not look right, I added a print statement to the error path that dumped the full request URL whenever something went wrong. The full URL of the Open-Meteo customer endpoint includes the apikey query parameter. The print was meant for development. I forgot to remove it.

I deployed.

The next time Open-Meteo had an outage - and small ones happen, sometimes for several minutes at a time - the bot dutifully printed the failing request URL into the post body. For every city. For every cycle that ran during the outage. The wrapper script piped the output into snac note_unlisted without complaint. The posts went out, federated across the Fediverse, with my API key sitting in the text for anyone who cared to read.

Some users were kind enough to write me and tell me. Others were less kind, and made fun of me. Both groups were correct. This should not have happened.

I reported the incident to the Open-Meteo team, who were extremely understanding. They rotated the key immediately and gave me a fresh one. I removed the debug print, and then I did the slightly more useful thing, which was to add redaction at multiple layers - in the bot's output, in the daemon's logging, and in the debug helpers themselves. URL query parameters that look like API keys are masked. Environment variables and config keys named apikey or OPEN_METEO_APIKEY are redacted before any string reaches stdout or a log file. Even JSON-like fields that include open_meteo_apikey are scrubbed if they ever appear in something the program prints.

The lesson is not "be more careful." The lesson is that debug paths leak, sooner or later, so the secrets have to be unreachable from the debug paths in the first place. Now they are.

That afternoon, when I realised what was happening, I closed everything for a minute and looked out of the window. Then I started fixing.

Nominatim is a public service, and it is generous, but it is not infinite. Every city in the project needs coordinates, and at the start of the project every cycle would re-ask Nominatim for every city. Most of the time this worked. Sometimes it did not.

There was one cycle, before I added caching, when Nominatim simply did not respond for one of my queries. The geopy call timed out. The bot raised an exception. The wrapper script gave up on that city and moved on to the next one. A few users noticed that a particular city had not received its forecast that day, and asked what had happened.

I added a coordinate cache, and I am still grateful that I did.

The cache is intentionally boring. The first time the bot resolves a city, it writes the latitude and longitude into a small file under /tmp, named after the city, and the state when present. Every subsequent run reads the file. If the file exists, no Nominatim call is made. If the file is missing, the bot calls Nominatim and writes the file. After the first successful lookup, the cache becomes the source of truth for the coordinates of that city.

This is lighter on Nominatim, faster for every cycle, and much more resilient against transient failures. It is also nice for a reason I did not anticipate.

Nominatim is a geocoder, and like every geocoder it has opinions.

I live in Ferrara, so when I added Italy I made sure Ferrara was in the list, and I checked the first cycle to make sure everything looked right. The forecast came out fine. The temperature was reasonable. The icon matched the sky outside my window. I closed the laptop and forgot about it.

Then, one evening months later, I looked more carefully at the coordinates Nominatim had returned for "Ferrara, Italy", and I realised they did not point to the city. They pointed to a location closer to the centroid of the province, which is a much larger area and mostly countryside. The forecast had been, on average, for a field somewhere outside town, not for the city center.

I am not entirely sure why I had not noticed earlier. Probably because the weather in Ferrara and the weather in the fields outside Ferrara is, on most days, indistinguishable to anyone who is not paying attention. But this is the kind of detail I do not want to leave wrong, especially for my own city.

There are other places where geocoding lands slightly off. Sometimes it is a few kilometers, sometimes a different neighborhood, sometimes genuinely the wrong place.

Because the cache is just a file per city, the fix is also just a file per city. I open the cache file, replace the latitude and longitude with the correct values, save. The next cycle uses the corrected coordinates. No code change, no redeploy, no special tooling. I keep a small list of patched cities in a separate text file, so that if I ever rebuild the cache, I do not lose the manual corrections.

This is the kind of operational simplicity I like. A cache made of plain files costs almost nothing and quietly pays back every time a small problem appears.

For every report it generates, the bot also writes a simplified English text snapshot to /tmp/.txt, or /tmp/__.txt when there is a state.

This is intentional, and it is not a debug artifact. I am not ready to say what I am doing with it yet, but it is part of a future direction for the project. Text is a useful intermediate format, and having a clean, language-neutral representation of every forecast sitting on disk costs almost nothing and might be worth a great deal later.

I prefer to let ideas mature in private before I commit to them in public. So I will leave it at this for the moment.

A full cycle for the United States takes hours.

It is not because the work is heavy. It is because I deliberately inserted a small sleep between cities, to give snac time to dispatch the previous post before the next one is generated. With more than 1200 cities in series, even a short pause adds up. I am not in a hurry. Forecasts that arrive a few minutes apart from each other are not a problem, and the bot was already a polite citizen elsewhere. A polite cycle is fine.

The problem with a slow cycle is not the duration. The problem is what happens to it.

In the original design, the cycle was launched by cron. Every six hours, cron called the wrapper script, the wrapper iterated through the cities file, and for each city it ran the bot and piped the output into snac. There was no scheduler in the project at all. Cron was the scheduler. The wrapper was just a loop.

Restarting snac was harmless. The wrapper would call snac note_unlisted per city, and if snac happened to be unavailable for a moment, that single call might fail, but the loop kept moving and snac was usually back within seconds. Snac itself was not what held the cycle together.

What held the cycle together was the wrapper process. And the wrapper process lived inside the jail.

If the FreeBSD jail was restarted while the wrapper was running, the loop stopped wherever it happened to be. The cron schedule did not care. Six hours later, the next cron tick started a new cycle from the first city, and the cities that had been about to be processed at the moment of the restart were simply skipped for that window. For the United States, this could mean several hundred cities going without an update.

There was a worse case, and it took me longer than it should have to recognise it. If the host was rebooting exactly in the minute when cron should have fired, cron simply did not fire. There was no daemon waiting to pick up the missed tick. The cycle never even started. Six hours of forecasts would be lost, in silence, with nothing in any log to suggest anything had gone wrong.

I lived with this for a long time. Reboots were rare, the impact was limited, and adding state was the kind of thing I always meant to do "next week."

What finally changed it was not a dramatic incident. It was the slow accumulation of small ones. A scheduled VPS reboot. A jail restart after an upgrade. Each one on its own was nothing. Together, they were a steady drip of missed cycles.

So I wrote a daemon.

The crontab entries for the bot went away. There is now a long-running process inside the jail, started at boot, and it does the scheduling itself. The schedule is a list of hours and a minute, read from a JSON config. The daemon wakes up once a minute, checks whether it is time to start a cycle, and either starts one or waits.

The interesting part is the state file.

As the daemon walks through the cities file, it writes its position to a small JSON file: which cities file it is processing, and the index of the next city to handle. The write happens at the boundary between one city and the next, because that is the only place where resuming makes sense. If the daemon is interrupted mid-city, that city is retried on resume; no half-finished post escapes.

When the daemon starts, it reads the state file. If it finds one matching the current cities file, it resumes from the saved index. If the cities file has changed since the state was written, the daemon starts fresh. The check is deliberately conservative: a renamed or modified cities file is treated as a different cycle, because the indices would otherwise be meaningless.

The result is the behavior I should have had from the start. If the host reboots while the United States cycle is running, the daemon comes back up with the jail, reads the state, and continues from where it left off. Every city still gets its update, just with a small gap corresponding to the reboot itself. The cycle finishes. The state file is reset. Life goes on.

And the worst case from the cron days is gone. The daemon does not need anyone to fire it. As long as the jail is running, the daemon is running, and the next scheduled cycle will happen when its hour comes, regardless of what was happening at any specific minute.

Of all the changes I have made to the project, this is the one I like most. It is not exciting work. It is the kind of thing that earns no applause because, when it works, it produces no visible event. But it removes a whole class of small daily annoyances, and it makes a slow process robust against the boring kind of failure: the kind nobody plans for, but that always eventually happens.

The current bot does considerably more than the original Italian script. It handles per-city timezones, three weather providers with automatic fallback, unit conversion for temperature, wind, and precipitation, optional air quality, pressure trend indicators when the provider supplies pressure data, a simplified English text snapshot for future use, a coordinate cache that can be patched by hand, secret redaction at multiple layers, a heartbeat that adapts to whichever HTTP client is installed on the host, and a scheduler-and-resume daemon that survives reboots.

But from the outside, almost nothing has changed.

The European country configs work the same way they always did. The wrapper scripts are unchanged. The snac integration is the same one-line pipe. The HAProxy layer in front does not know or care that the bot was rewritten. The homepage cron that counts followers and regenerates the static page works exactly as before.

The original Italian script does not exist as a file anymore, but it survives as a default. A country config with timezone set to Europe/Rome and no special options behaves, today, exactly as the first version of the bot would have. Everything else is opt-in.

I like this kind of work.

https://it-notes.dragas.net/2026/05/25/fedimeteo-timezones-and-the-art-of-not-breaking-what-already-works/

#ITNotes #NoteHUB #fedimeteo #fediverse #jail #networking #ownyourdata #server #snac #snac2 #social #web

Ok yeah I think I'll be able to switch from dnsmasq to running dhcp+dns on the mikrotik....

it'll let me use firewall address-lists populated by static leases, which should let me build better rules

I think I should also be able to create a script that populates ipv6 addresses via mac lookups (if the device also has a dhcpv4 address)

#Homelab #Networking #Mikrotik

Ok monitoring traffic flow via netflow->opentelemetry -> parsing script really wasn't the right idea, without a significant amount of effort to track connection status, too many return flows get tracked.

The right idea is to just put a log statement at the end of the firewall chains to see what makes it to the default-accept

The goal is to trace down and account for all traffic them turn those into default-deny rules, then the logs can be fed into Loki to power alerts
#Homelab #Networking

Roughly 17 years (-ish) after taking the one/only test available back then, I've returned and taken the "new" IPv6 tests and am now an IPv6 Sage. *flex* ask me about my glue records, they work out.

https://ipv6.he.net/

#dns #ipv6 #networking #nerd #::1

Not really here nor there, but I thought I would reiterate that #commonLisp 's @kentpitman and myself #interview ed @bagder about #curl and #AI on May 10th, one day before that #news article.

https://toobnix.org/w/rPKt4GRBwLeWzF3VcMFWNo

Curl is a popular #networking #software

https://curl.se/
https://en.wikipedia.org/wiki/CURL
https://en.wikipedia.org/wiki/Kent_Pitman

#curl #unix #cli #C #libcurl #linux

A little video I picked up in r/shittysysadmin on reddit.
It speaks to me 🤪😎😬
#sysadmin #DNS #networking #routing #internet

OpenBSD 7.9 released https://undeadly.org/cgi?action=article;sid=20260519132757 #openbsd #newrelease #openbsd79 #security #development #networking #foryourlaptop #freesoftware #libresoftware

When I wrote about FediMeteo (https://it-notes.dragas.net/2025/02/26/fedimeteo-how-a-tiny-freebsd-vps-became-a-global-weather-service-for-thousands/) for the first time, I told the story from the beginning: the idea born almost by chance while checking the weather for a holiday, the memory of my grandfather, who for years had been my personal meteorologist, the decision to build something small and useful, and then the surprise of seeing people actually use it. What began as a personal experiment quickly became a small global service, still running with the same philosophy: FreeBSD, jails, simple scripts, snac, text, emoji, and a lot of small pieces doing their work quietly.

That article was mostly about the birth and growth of the project. This one is about one of the less romantic parts of the same story, although I have to admit that I find a certain beauty in it too: keeping the service light as it grows.

FediMeteo (https://fedimeteo.com) is still intentionally simple from the outside. A homepage, some numbers, a list of countries, and many ActivityPub accounts publishing weather forecasts. The posts are text and emoji. There is no JavaScript requirement to read the pages, no heavy frontend, no unnecessary media attached to every forecast, and no dynamic homepage recalculated at every visit just to show the same numbers. This is not accidental. It is the way I wanted the service to behave from the beginning.

But the more the service is used, the more the small details matter. A request that looks harmless when there are ten followers may become a repeated request when there are thousands of followers, remote instances, crawlers, previews, and other servers fetching the same public objects. In the Fediverse, the same small thing can be asked many times by many different places, each one with a perfectly legitimate reason. The backend doesn't care: it just needs to deal with the requests.

And in FediMeteo, the backend is snac (https://codeberg.org/grunfink/snac2).

I like snac very much precisely because it is small, clear, and efficient. It is not a giant application that tries to be everything. It does a focused job and does it well. But this also means that I want to respect its shape. I do not want to waste its threads on work that the reverse proxy can safely do. A snac thread serving the same public avatar again and again is not a tragedy, but it is still a waste. A snac thread answering the same public ActivityPub object several times in the same minute is doing real work, but often not necessary work.

This is the reason behind the HAProxy (https://www.haproxy.org) tuning I am currently using in front of FediMeteo.

It is not about making the configuration look clever. It is about keeping snac quiet.

A continuation of the same idea

This is especially important because snac uses a limited number of threads. I like that. Limits are healthy. They force us to understand what the service is doing, and they prevent a small program from pretending to be an infinite resource. But limits also make waste visible. If a few threads are busy serving files that could have been served from cache, those threads are not available for something more useful.

With FediMeteo the implementation is different because the reverse proxy is HAProxy, but the reasoning is the same. I have many small snac instances, each one in its own FreeBSD (Bastille (https://github.com/BastilleBSD/bastille)) jail, and one public entry point that has to route, terminate TLS, compress, cache, and generally remove as much repetitive work as possible from the backends.

This is, in a way, the natural continuation of the original FediMeteo design. In the first article I wrote that I wanted to manage everything according to the Unix philosophy: small pieces working together. This is another piece of that same puzzle. HAProxy does the edge work. snac does the ActivityPub work. Scripts generate forecasts. cron launches updates. ZFS gives me snapshots. FreeBSD jails keep countries separated. Nothing is particularly heroic by itself, but the whole system becomes pleasant because each part has a clear responsibility.

Why there is almost no media

FediMeteo does not use media in its forecasts.

No images attached to the posts, no generated weather cards, no maps for each city, no decorative banners. The forecasts are text and emoji. This was a deliberate decision. Weather information does not become more useful just because it is put inside an image, and every media file used by the service would become something to store, serve, cache, federate, expire, back up, and occasionally debug.

Text and emoji are enough. They are accessible, light, readable in text browsers, friendly to timelines, and understandable even when someone does not know the local language perfectly. This was one of the original design principles of FediMeteo, and it also helps the infrastructure. Less media means less work, fewer cache entries, fewer repeated fetches, fewer surprises.

There is one exception: the avatar.

All FediMeteo accounts use the same avatar, and this is also intentional. I could have used a different avatar for each country, or for each city, or created something visually richer. It would have been nicer in some screenshots, perhaps. It would also have been operationally worse.

With one shared avatar, the reverse proxy has one very useful object to cache. It is public, identical for everyone, small, requested often, and therefore almost always hot in cache. HAProxy can serve it directly instead of asking each snac instance to return the same file. Since avatars are requested by remote instances, browsers, profile previews, and all sorts of federation-related fetches, this single decision removes a surprising amount of pointless backend traffic.

So the avatar is not only a visual identity. It is part of the architecture.

This is the kind of optimization I like most, because it starts before the software. It starts with deciding not to create a problem.

The homepage is static because it can be static

It is a static HTML page generated from a template. Once per hour, a cron script updates the numbers and statistics. It counts the data I want to show, regenerates the page, and then the page remains static until the next run.

This is not because I cannot make a dynamic page. It is because I do not need one. Boring is good.

The homepage does not need to query all the country instances on every visit. It does not need a database request for each user who opens it. It does not need to ask snac anything in real time. The numbers are useful, but they do not need to be updated every second. Once per hour is enough, and it also fits the spirit of the whole project: do the work when it is needed, then serve the result cheaply.

I have seen too many small services become heavy because the first implementation was convenient rather than appropriate. A cron job and a template are not fashionable, but they are often exactly what a page like this needs.

Many countries, one entry point

fedimeteo.com
www.fedimeteo.com
it.fedimeteo.com
uk.fedimeteo.com
jp.fedimeteo.com
us.fedimeteo.com
usa.fedimeteo.com
can.fedimeteo.com
canada.fedimeteo.com

At the beginning, it is always tempting to write one ACL after another in the HAProxy frontend. It is quick, it is explicit, and for five hostnames it is perfectly fine. But FediMeteo did not remain at five hostnames. As countries and aliases grew, a long chain of ACLs would have turned the frontend into a list of names instead of a description of how the proxy behaves.

So I moved the hostname to backend mapping into a map file:

fedimeteo.com        backend_fedimeteo
www.fedimeteo.com    backend_fedimeteo
it.fedimeteo.com     backend_it
uk.fedimeteo.com     backend_uk
jp.fedimeteo.com     backend_jp
us.fedimeteo.com     backend_us
usa.fedimeteo.com    backend_us
can.fedimeteo.com    backend_ca
canada.fedimeteo.com backend_ca

use_backend %[req.hdr(host),field(1,:),lower,map(/usr/local/etc/fedimeteo.map,backend_fedimeteo)]

I like this because it keeps the configuration honest. The frontend contains the policy. The map contains the data. Adding a country means adding an entry to the map and defining a backend. I do not need to make the frontend more complicated every time the service grows.

Backends as small compartments

backend backend_it
    mode http
    http-reuse safe
    server srv1 10.0.0.2:8001 maxconn 30
backend backend_uk
    mode http
    http-reuse safe
    server srv1 10.0.0.7:8001 maxconn 30
backend backend_jp
    mode http
    http-reuse safe
    server srv1 10.0.0.32:8001 maxconn 30

The maxconn 30 value is not a magic number. It is a ceiling. I want each small backend to have a visible limit in front of it. If something starts hammering a country instance, I prefer the pressure to appear at the HAProxy layer instead of becoming unlimited concurrent work inside snac.

http-reuse safe lets HAProxy reuse backend connections where appropriate. This is another small reduction in unnecessary work. Opening connections repeatedly is not the biggest problem in the world, but avoiding it is still better, especially when many small services sit behind the same proxy.

The front door

frontend https_in
    bind :::443 v4v6 ssl crt /usr/local/etc/certs/ alpn h2,http/1.1
    mode http
    option http-keep-alive

ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

acl letsencrypt-acl path_beg /.well-known/acme-challenge/
http-request redirect scheme https code 301 unless letsencrypt-acl
use_backend letsencrypt-backend if letsencrypt-acl

http-request set-header X-Real-IP %[src]
http-request set-header X-Forwarded-Proto https

http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Two caches, because the requests are different

cache mediacache
  total-max-size 128
  max-object-size 10000000
  max-age 3600
  process-vary on
  max-secondary-entries 12
cache jsoncache
  total-max-size 16
  max-object-size 1000000
  max-age 60
  process-vary on
  max-secondary-entries 12

The media cache is larger and has a longer maximum age. In FediMeteo, this mostly means the shared avatar and a few static-looking objects. Since there is intentionally almost no media, the important cached object is requested very often and remains warm.

The JSON cache is smaller and short-lived. It is there for public ActivityPub GET requests, not to store federation state forever. A 60 second cache is enough to collapse many repeated requests that arrive close together in time, without pretending that ActivityPub responses should be treated like immutable files.

This distinction is important. Caching is not one decision. It is a set of small decisions about what a response means, who can see it, how often it changes, and what happens if it is served again.

Recognizing media

acl is_media path_end -i .jpg .jpeg .png .gif .webp .svg .ico .mp4 .webm .mp3 .ogg .wav .flac .mov .avi .mkv .m4v

http-request set-var(txn.is_media) bool(true) if is_media

http-request cache-use mediacache if { var(txn.is_media) -m bool true }

http-response set-header Cache-Control "max-age=3600, public" if { var(txn.is_media) -m bool true }
http-response del-header Set-Cookie if { var(txn.is_media) -m bool true }
http-response del-header Vary if { var(txn.is_media) -m bool true }
http-response cache-store mediacache if { var(txn.is_media) -m bool true }

This is aggressive only if removed from its context. In this service, with this media policy, it is a reasonable choice. FediMeteo is not serving private media under these paths. It is mostly serving the same public avatar over and over.

For the same reason, I clean the request before it reaches the backend:

http-request del-header Authorization if { var(txn.is_media) -m bool true }
http-request del-header Cookie        if { var(txn.is_media) -m bool true }

The result is exactly what I want: the shared avatar becomes an almost perfect cache object. Small, public, repeatedly requested, and served by HAProxy instead of snac.

ActivityPub JSON microcaching

acl is_ap_json   req.hdr(Accept),lower -m sub application/activity+json
acl is_ap_ldjson req.hdr(Accept),lower -m sub application/ld+json
acl is_outbox    path_end /outbox
acl is_get       method GET
acl has_auth     req.hdr(Authorization) -m found
acl has_cookie   req.hdr(Cookie) -m found

So I only mark public ActivityPub GET requests as cacheable:

http-request set-var(txn.is_activitypub) bool(true) if is_get !is_outbox is_ap_json !has_auth !has_cookie
http-request set-var(txn.is_activitypub) bool(true) if is_get !is_outbox is_ap_ldjson !has_auth !has_cookie

It must be a GET, because I am not caching deliveries or anything that changes state. It must not be /outbox, because outbox collections are not the traffic I want to cache here. It must not have Authorization, and it must not have cookies, because authenticated or user-specific requests do not belong in a shared public cache.

Then the cache can be used and populated:

http-request cache-use jsoncache if { var(txn.is_activitypub) -m bool true }
http-response set-header Cache-Control "max-age=60, public" if { var(txn.is_activitypub) -m bool true }
http-response cache-store jsoncache if { var(txn.is_activitypub) -m bool true }

This is microcaching in the most practical sense. It reduces repeated work without changing the nature of the service.

Static media paths

acl is_short_path path_reg ^/[^/]+/s/
http-request cache-use mediacache if is_short_path

In FediMeteo this is less central than on a normal social instance, because I deliberately do not use media except for the avatar and basic static objects. Still, the rule fits the general policy: let HAProxy handle repeatable edge work, and let snac spend its threads where they are actually needed.

Vary, but not without limits

process-vary on
max-secondary-entries 12

For media, I remove Vary before storing the response. A shared avatar does not need to vary by Accept. For ActivityPub JSON, I am more careful because the representation matters.

Again, the important thing is not the number itself. It is the decision to make variation explicit and limited.

Seeing whether it works

http-response set-header X-Cache-Status HIT if !{ srv_id -m found }
http-response set-header X-Cache-Status MISS if { srv_id -m found }

Did this request reach snac?

A test can be as simple as:

curl -I https://it.fedimeteo.com/path/to/avatar.png
curl -I https://it.fedimeteo.com/path/to/avatar.png

For ActivityPub JSON, the test must use the right Accept header:

curl -I \
  -H 'Accept: application/activity+json' \
  https://it.fedimeteo.com/some/activitypub/object

curl -I \
  -H 'Cookie: test=value' \
  -H 'Accept: application/activity+json' \
  https://it.fedimeteo.com/some/activitypub/object
curl -I \
  -H 'Authorization: Bearer fake' \
  -H 'Accept: application/activity+json' \
  https://it.fedimeteo.com/some/activitypub/object

Compression and operational paths

filter compression
compression algo gzip
compression type text/css text/html text/javascript application/javascript text/plain text/xml application/json application/activity+json

There is also a local Prometheus exporter:

frontend prometheus
  bind 127.0.0.1:8405
  mode http
  http-request use-service prometheus-exporter
  no log

What this changes in practice

The map keeps hostname routing manageable. The backend definitions keep each country isolated and limited. The static homepage avoids dynamic work for something that changes once per hour. The shared avatar gives HAProxy one very hot media object to serve directly. The media cache keeps public files away from snac. The JSON microcache absorbs short ActivityPub bursts. Header cleanup prevents useless variation. Connection reuse avoids unnecessary backend connection churn.

But all of this is only a longer way of saying one thing:

fewer requests reach snac.

That is the metric I care about here.

Not because snac is slow. If anything, FediMeteo exists in its current form because snac is efficient enough to make this kind of project possible on a very small VPS. But precisely because the whole architecture is small and pleasant, I do not want to waste resources where there is no need.

This is also consistent with the rest of the project. Forecasts are serialized by scripts. Updates happen every six hours. The homepage is regenerated hourly. Countries live in separate jails. Snapshots and backups are handled outside the application. No single component tries to be the entire system.

HAProxy is just another small piece, but it sits in the right place to remove a lot of repeated work.

Caveats

It matches FediMeteo as it is now: almost no media, one shared avatar, static homepage, public forecasts, many small snac instances, and ActivityPub traffic that can benefit from a short public cache when there are no cookies or authorization headers.

If I decide one day to use media in forecasts, the media cache rules will need to be reviewed. If I use different avatars for each city or country, the cache will still work, but I will lose the very nice property of one shared, always-hot avatar. If ActivityPub responses become actor-dependent, public JSON caching must be reconsidered. If one country grows a very different traffic pattern from the others, it may deserve a different limit or policy.

This is why I do not like presenting configurations as magic. A good configuration is a written form of the assumptions behind a service. When the assumptions change, the configuration must change too.

Conclusion

The HAProxy layer follows this idea. It terminates TLS, routes hostnames through a map, reuses backend connections, serves the shared avatar from cache, microcaches public ActivityPub JSON, avoids authenticated and cookie-based traffic, and gives me a small diagnostic header to see what is happening.

There is no single brilliant directive here. There is only the usual work of matching infrastructure to reality.

FediMeteo publishes weather forecasts as text and emoji. The homepage is static HTML updated every hour. The accounts share the same avatar because it is enough, and because it is better for the cache. Each country has its own snac instance in its own FreeBSD jail. HAProxy stands in front of them and tries, quietly, not to bother them unless it has to.

I like this kind of infrastructure.

Not because it is invisible, but because when it works well, it leaves very little to say.

https://it-notes.dragas.net/2026/05/18/fedimeteo-haproxy-and-the-art-of-not-wasting-snac-threads/

#ITNotes #NoteHUB #fediverse #freebsd #haproxy #hosting #jail #networking #ownyourdata #server #snac #snac2 #social #web

Automatic expiry at timeout for pf(4) overload tables https://undeadly.org/cgi?action=article;sid=20260513064948 #openbsd #pf #packetfilter #overload #overloadtables #statetracking #timeout #expiry #autoexpiry #autotimeout #networking #networktrickery

#NetMCR (https://www.netmcr.uk/) is on again this Thursday (14th) in #Manchester.

There's no talk scheduled as yet, so feel free to propose one, or just go along to chat to other nerds 😝, have some weird 🍻, and if you're hungry, 🍔 and 🍟!

#Networking #MeetUp

Let's find out how to get predictable IPv6 addresses assigned to OpenBSD VMs https://undeadly.org/cgi?action=article;sid=20260512115225 #openbsd #networking #ipv6 #predictable #dynamic #autoconf #development #freesoftware #libresoftware

#DENOG18 is back in Essen!

🗓 November 15 - 17, 2026
📍 Haus der Technik (HDT), Essen

Tickets are now available!
Secure your Early Bird ticket until July 3rd and join the DENOG community for three days of networking, knowledge sharing, and great conversations.

👉 Get your ticket here:
https://www.denog.de/de/meetings/denog18/

Stay tuned for more updates! We can’t wait to see you in Essen!

#DENOG18 #DENOG #Networking #Essen

Alt...

ticket

Trying to figure out networking and (OpenBSD) pf at the same time...

Basically, I have a secondary IPv4 address on my OpenBSD webserver that I want to forward to my IPv6-only Wii - as if the IPv4 address was the Wii's.

What forwarding mode is appropriate? nat-to, af-to, rdr-to?

#OpenBSD #pf #networking

Day 1 at DEVWorld Amsterdam is a wrap 🇳🇱

Back again tomorrow and we’re also sponsoring the photo booth. Stop by, say hi, and build yourself a keycap fidget toy.

#DevWorld #Amsterdam #Tailscale #Networking #DevTools #Cloud #Security #Developers

LibreNMS (https://www.librenms.org) has been a faithful companion for years now. It quietly handles the monitoring of my servers, devices, and services without demanding much in return - exactly what you want from a tool whose job is to watch over everything else. It's a solid alternative to heavier solutions like Zabbix, and it gives you alerts, data, and graphs on virtually anything reachable over SNMP.

I usually install it on a host that is not reachable from the outside, then let it poll all the devices through a VPN: a single observation point, clean perimeter. The ability to create multiple dashboards - and to filter them by user - has also let me give clients a transparent window onto their own servers. Transparency, in my experience, is always the better long-term bet.

Together with Uptime-Kuma (https://it-notes.dragas.net/2024/07/22/install-uptime-kuma-freebsd-jail/) (and the good old Nagios/Munin pair), LibreNMS lives in a FreeBSD jail on my monitoring servers and just does its job.

This post walks through a plain installation of LibreNMS on FreeBSD: package-based, no reverse proxy, no HTTPS, no fancy hardening. The goal is to get to a working setup you can build on top of.

Assumptions

• FreeBSD 15.0-RELEASE, in a jail or on a dedicated VM/host
• nginx + php-fpm + MySQL 8.4
• LibreNMS installed from the official package — not via git clone

Installation

pkg install librenms mysql84-server python3 nginx

pkg install php84-opcache

MySQL

cd /usr/local/etc/mysql
cp my.cnf.sample my.cnf

innodb_file_per_table=1
lower_case_table_names=0

service mysql-server enable
service mysql-server start

mysql

CREATE DATABASE librenms CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'librenms'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON librenms.* TO 'librenms'@'localhost';
exit

php-fpm

listen = /var/run/php-fpm-librenms.sock
listen.owner = www
listen.group = www
listen.mode = 0660

cd /usr/local/etc
cp php.ini-production php.ini

date.timezone = Europe/Rome

nginx

server {
    listen      80;
    #server_name yourServerName
    root        /usr/local/www/librenms/html;
    index       index.php;
    charset utf-8;
    gzip on;
    gzip_types text/css application/javascript text/javascript application/x-javascript image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon;
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location /api/v0 {
        try_files $uri $uri/ /api_v0.php?$query_string;
    }
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        set $path_info $fastcgi_path_info;
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_param SERVER_SOFTWARE "";
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $path_info;
        fastcgi_index index.php;
        fastcgi_pass unix:/var/run/php-fpm-librenms.sock;
        fastcgi_buffers 256 4k;
        fastcgi_intercept_errors on;
        fastcgi_read_timeout 14400;
    }
    location ~ /\.(?!well-known).* {
        deny all;
    }
}

service nginx enable
service nginx start
service php_fpm enable
service php_fpm start

LibreNMS configuration

cp /usr/local/www/librenms/config.php.default /usr/local/www/librenms/config.php

Create the directory for RRD graphs and set ownership:

mkdir -p /var/db/librenms/rrd
chown -R www:www /var/db/librenms
chmod 775 /var/db/librenms/rrd

cd /usr/local/www/librenms
cp .env.example .env
chown www .env

• DB_DATABASE - librenms
• DB_USERNAME - librenms
• DB_PASSWORD - the one you actually used (not password, please)

INSTALL=true

ls -la /usr/local/www/librenms/storage /usr/local/www/librenms/bootstrap/cache

su -m www -c "php artisan key:generate"

chmod 600 .env

su -m www -c "lnms config:clear"
su -m www -c "lnms config:cache"

Web installer

su -m www -c "lnms config:clear"
su -m www -c "lnms config:cache"

Polling service

service librenms enable
service librenms start

Validate

cd /usr/local/www/librenms
su -m www -c './validate.php'

Next steps

https://it-notes.dragas.net/2026/05/07/monitor-your-services-with-librenms-on-freebsd/

#ITNotes #NoteHUB #freebsd #hosting #jail #monitoring #networking #ownyourdata #security #server #tutorial

I built a TLS router that forwards connections based on SNI (Server Name Indication). That means, it accepts TLS connections (like https), checks the desired target hostname, then forwards the encrypted stream to the backend that's configured for the hostname.

It hands off the actual forwarding task to the Linux kernel via eBPF, which makes this a zero-copy operation. As a result, services behind the router are _noticably_ snappier than with the userspace based solutions (that copied the incoming data to userland, copied it from one socket to the other there, back to kernel for further distribution) that I used until now.

Through that, it keeps the client's IP address visible to the client natively instead of fronting everything with the proxy's address.

As a convenience, it can figure out the backend by docker/podman container name, removing the need to "expose" the ports through docker/podman own infrastructure (which is, again, a copy via userspace in some scenarios), including figuring out the new IP address on container restarts.

Other implementations parse out the TLS records manually, trying to get to the SNI data in the ClientHello record with the least amount of effort possible. In contrast, my router uses the Go TLS library, which should make it generally more robust and future proof, given that the library is in use in much more critical scenarios than mine.

It also means that ECH (Encrypted ClientHello) should work to hide the target domain name from the outside world (the router still needs the private key used for ECH to figure out routing, but even with that, it still can't read the data stream itself). That said, I don't have the ECH setup to test it, so that's more of a theoretical option for now.

It runs on my personal infra and makes Jellyfin much snappier, and I'll roll it out to more servers that I maintain as I gain confidence that it's robust enough. Still cleaning up the code, but I'll release it as Free Software sometimes soon.
#freesoftware #Linux #networking

#DevConf_CZ 2026 schedule is live!

Get ready for two days packed with insightful talks, inspiring speakers, and dozens of engaging topics. Whether you're looking to deepen your expertise, explore new trends, or connect with the community, there's something for everyone.

Start planning your experience today and make the most of everything this event has to offer. We can’t wait to see you there!
https://www.devconf.info/cz/schedule

#Conference #Networking #OpenSourceCommunity #LearningAndDevelopment

Alt...

Schedule is live!

Twenty-five years ago today, on 28 April 2001, we tested our TCP/IP over avian carriers (RFC1149) implementation.

See "The implementation of the Carrier Pigeon Internet Protocol, RFC1149, 25 years later",
https://nxdomain.no/~peter/rfc1149_implementation_25_years_later.html

#networking #tcpip #carrierpigeon #rfc1149 #25years

Friends, I wrote a book. It's now out in its fourth edition.

More in "The Book of PF, 4th Edition: It's Here, It's Real" https://nxdomain.no/~peter/its_real_its_here.html

For background, "Yes, The Book of PF, 4th Edition Is Coming Soon" https://nxdomain.no/~peter/yes_the_book_of_pf_4th_ed_is_coming.html

Get the book: https://nostarch.com/book-of-pf-4e

@nostarch #bookofpf #pf #networking #openbsd #freebsd #networktrickery #cybersecurity

Calling all Linux and off-grid comms enthusiasts! 🚀 Meshtastic developer @jp_bennett is heading to London next month to speak at Ubuntu Summit 26.04.

He’ll be giving a hands-on demonstration of Meshtastic running on Linux, along with a overview of the project. If you're attending the summit, be sure to add this one to your schedule!

Check out the details here: 👇
https://discourse.ubuntu.com/t/hands-on-meshtastic/79497

#UbuntuSummit #Meshtastic #OpenSource #Ubuntu #Linux #Networking

The implementation of the Carrier Pigeon Internet Protocol, RFC1149, 25 years later https://nxdomain.no/~peter/rfc1149_implementation_25_years_later.html #rfc1149 #networking #tcpip #carrierpigeons #pigeons #networkpigeons #ping

Using The New Bridges of FreeBSD 15
https://blog.feld.me/posts/2026/02/using-new-bridges-freebsd-15/

#freebsd #bhyve #jails #networking #vlan

Iran is claiming that the US used backdoors into networking kit to disturb their communications. The Chinese press are just loving it, after all they are the ones (the US says) who are putting all of those backdoors in.

https://www.theregister.com/2026/04/21/iran_claims_us_used_backdoors

#IT #Networking #Backdoors #Security #USA #China

Interesting read on the way LLM bots retrieve pages from a website

Explanations are clear precise and surgical

https://surfacedby.com/blog/nginx-logs-ai-traffic-vs-referral-traffic

#LLM #AI #slop #nginx #traffic #programming #referral #traffic #networking #robots #txt #claude #chatgpt #bing #meta #metaAI

All networking and HDMI links (purple), core home stuff (green), and miscellaneous flood cabling (black) divided up by room then type (to allow for testing), and (2nd photo) undifferentiated speaker cabling.

Very definitely NOT tidy, but eventually all of these will be mega-bundled together by type. Once we finish off this storage room ceiling they’ll emerge from drop holes.

The corner will have two racks - one for compute/storage and one for AV distribution.

#OharaConstruction #networking

Alt...

A wall of cables, grouped into six vertical columns, tied to a rough wood wall.

Alt...

A wooden wall with a huge bundle of speaker cables pinned to it.

Thanks for the replies. Given I’ve manually tested the most worrisome cables I think I’m going to close up where I can but slowly terminate and test half of each redundant cable pair I’ve prewired.

Feeling much less anxious now.

#networking #cable #cat6 #ethernet

My gut is the latter… #networking #cable #cat6 #ethernet

Help! I’ve prewired an old European apartment with CAT6a, around 50 drops to a sigle area. They run above suspended ceiling and behind plasterboard on brick.

Before I close off walls and ceilings I need to test them all. I’ve started doing the testing with a wire pair continuty tester. This works but it’s slow.

So, is there a technique or tool that might be quicker?

Or am I better just terminating them all with keystones and testing with regular kit?

#networking #cable #cat6 #ethernet

New post: Part 4 of running my own AS.

A direct BGP session with Hetzner on FogIXP, a fourth FreeBSD edge in Zürich, and a MikroTik at home speaking iBGP into the /48 - so my home LAN now has provider-independent IPv6 and exits AS201379 like any other site.

Plus a two-condition route-map that steers DTAG-bound traffic over Vultr.

https://blog.hofstede.it/running-your-own-as-direct-hetzner-peering-a-fourth-edge-and-bringing-the-home-lan-into-the-fabric/

#BGP #FreeBSD #IPv6 #FRR #MikroTik #Networking

Successfully virtualized a MikroTik Router ("Cloud Hosted Router") on FreeBSD 15.0-RELEASE with BHYVE

Works absolutely great (920 Mbit/s throughput on a 1GBps license!)

#freebsd #mikrotik #routeros #networking

rpki-client 9.8 released https://undeadly.org/cgi?action=article;sid=20260415115612 #openbsd #rpkiclient #rpki #routing #security #bgp #networking #libresoftware #freesofware

OpenBGPD 9.1 released https://www.undeadly.org/cgi?action=article;sid=20260414025522 #openbsd #openbgpd #bgp #routing #networking #libresoftware #freesoftware

pfsync(4) Packet Header Field Renamed to Avoid AI Bug Report Noise https://www.undeadly.org/cgi?action=article;sid=20260413055845 #openbsd #pfsync #networking #redundancy #carp #pf #packetfilter #development #libresoftware #freesoftware

In the world of BSD conferendes, BSDCan 2026 https://bsdcan.org is next, on June 17-20 in Ottawa, Canada.

Read more about the BSD conferences in "What is BSD? Come to a conference to find out!" https://nxdomain.no/~peter/what_is_bsd_come_to_a_conference_to_find_out.html #netbsd #openbsd #freebsd #conference #freesoftware #libresoftware #development #networking #sysadmin

Can anyone recommend a decent 2 port PCI network card?

Not PCIe or PCI-X!!!!

Bonus if its compatible with #NetBSD and has 1Gb ports

#Networking #oldcomputing

#IPv6 test as as German Telefonica roaming customer in the Belgian "Orange" network: [insert sad face here]

#networking #orange