Best #FreeBSD vulnerability, or bestest #FreeBSD vulnerability?

https://bumsrake.de/

Quick fact: if you've ever streamed content on Netflix, used a PlayStation, or sent a packet through a Juniper router, you've touched FreeBSD.

Learn more about how FreeBSD is used today: https://freebsdfoundation.org/end-user-stories/

#FreeBSD #OpenSource #Infrastructure #FreeBSDDay #SysAdmin

Dirty Pipe FreeBSD "Bumsrakete": https://bumsrake.de or https://www.freebsd.org/security/advisories/FreeBSD-SA-26:26.ktls.asc

CVSS 13 of 10 😂 Cant stop laughing 🙈😁

#infosec #freebsd #bumsrakete

mac_portacl isn't loaded by default? Out of the box any user can bind to any port?

I mean easy enough to change, but surprising.

#freebsd

FreeBSD 15.0-RELEASE-p10

Nice one! 💪 #RunBSD

@david_chisnall thanks … I was keen to try Linuxulator as directed in the FreeBSD Handbook. The end result seemed quite bonkers, it seems that there's a gap in official documentation.

<https://www.reddit.com/r/freebsd/comments/1tyh6ma/comment/oqkxrf9/> – there's a request for someone to make a bug report.

#FreeBSD #Linuxulator #documentation

For #FreeBSD users that don't subscribing to freebsd-current ML:
cristos@ posted a heads-up that audio devices would be created with recently added audio group (GID=43) in future releases.
https://lists.freebsd.org/archives/freebsd-current/2026-June/010328.html

This group is already added to stable/15 to be used in virtual_oss, too, but not merged into releng/15.1 at least for now.
https://cgit.freebsd.org/src/commit/?h=stable/15&id=a181c51e5f4d0f5ed0fa175cf5a268be63b3961b

But as this change in the heads-up means POLA violation because it affects anyone using #audio devices regardless using virtual_oss or not, I think the change (seemingly not yet landed) would NOT be MFC'ed into stable/15.

*BSD virtual machines on MacBook Pro M2 with UTM.

These are setup for command-line usage only, like servers. The operating system icons were available under settings for each machine, a nice touch!

Does macOS count as *BSD, in the grand scheme of things?

#FreeBSD #OpenBSD #UTM #macOS

Alt...

Screen shot of UTM in MacOS, showing OpenBSD 7.9 and FreeBSD 15.0 machines

Hello #freebsd folks. I'd like to get into FreeBSD and play around with it. What book is recommended to start with? @stefano do you have any recommendations?

Have this Thinkpad T480 that still is quite capable. I'd like to use it as my learning testbed.

Mark your calendars, FreeBSD Week is almost here.

June 19 marks FreeBSD Day, celebrating 33 years since the FreeBSD project began.

Throughout the week, we’ll be sharing community stories, project highlights, FreeBSD history, and a few surprises along the way.

Whether you’ve been running FreeBSD for decades or are just getting started, there’s something for you.

Stay tuned.

Learn more: https://freebsdfoundation.org/freebsd-day/

#FreeBSDDay #DevSummit #BSDCan #FreeBSD #OpenSource

Do you want to come to Brussels, mingle with BSD people, perhaps do a talk, a tutorial or a BOF session?

The Call for papers https://2026.eurobsdcon.org/cfp/ is open until June 20th, for the conference in Brussels September 9-13, 2026.

We also offer pre-submission guidance/mentoring, see within.

Wonder what BSD and the conferences are about? See https://nxdomain.no/~peter/what_is_bsd_come_to_a_conference_to_find_out.html

@EuroBSDCon #freebsd #netbsd #openbsd #freesoftware #libresoftware #brussels #bruxelles

Development of my personal FreeBSD installer keeps moving forward!

Lots of new ideas and features are currently in the works: the out-of-the-box GUI experience, completion of the Simple and Expert installation modes, automatic hardware detection and configuration (now also GPU support as well).

I'll be publishing a new blog post soon with more details. Stay tuned! 😄

#FreeBSD #BSD #OpenSource #FOSS #UNIX #Coding #Programming #SysAdmin #DevOps #DesktopBSD #Tech #OSS #Lua

Alt...

Screenshot of my new FreeBSD installer. The first setup screen lets users choose between Auto, Simple, and Expert installation modes through a keyboard-friendly text interface. Simple mode is currently selected.

Latest 𝗩𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗡𝗲𝘄𝘀 - 𝟮𝟬𝟮𝟲/𝟬𝟲/𝟬𝟴 (Valuable News - 2026/06/08) available.

https://vermaden.wordpress.com/2026/06/08/valuable-news-2026-06-08/

Past releases: https://vermaden.wordpress.com/news/

#verblog #vernews #news #bsd #freebsd #openbsd #netbsd #linux #unix #zfs #opnsense #ghostbsd #solaris #vermadenday

Hello Fediverse,

I'm happy to announce our very own Mastodon instance called "FediBlue", a new friendly place in the Fediverse for all people that are interested in free and open source software, especially Linux, BSD and illumos.

FediBlue is part of our ongoing effort to strengthen the FOSS community by publishing content about it and help projects gaining visibility in a time where many companies try to force their services on users, train AIs with people's data and collect as many data as they could.

Alongside the wonderful BSD Cafe community, where I'm also at, FediBlue should provide another very friendly and welcoming place in the Fediverse. In the next days, the Dark Blue Project presence will move completely to FediBlue.

https://mastodon.fediblue.de

#mastodon #opensource #freesoftware #linux #freebsd #openbsd #netbsd #illumos #darkblueproject #fediblue

How to add things such as wget and apt to Ubuntu 26.04 LTS in Linuxulator on FreeBSD?

https://www.reddit.com/r/Ubuntu/comments/1tz7dln/how_to_add_things_such_as_wget_and_apt_to_ubuntu/

What's the easiest way to install apt, in the absence of wget?

Alternatively: what's the easiest way to install wget, in the absence of apt?

#FreeBSD #apt #Linux #Linuxulator #Ubuntu

LOL NOPE.

Getting ports setup is a fucking trainwreck.
“If you use ports, don't use pkg unless you’re SUPER CAREFUL to not mess dependencies up”
"to install ports, first you have to install git”
"to install git, use pkg”

How is the does one of the primary software installation methods rely on a third-party tool that doesn't come by default (for base systems) and then REQUIRE following contraindicated instructions?

Le sigh. Maybe I'll do it anyway…

#FreeBSD

@gregatron5

I agree with @BastilleBSD .

Furthermore: Where did you see that written down? Because it's not from the #FreeBSD Handbook, and it's in fact outright contradicted by the Handbook which says that 'Both packages and ports understand dependencies.'.

https://docs.freebsd.org/en/books/handbook/ports/

It's not an accurate statement of the only two major problems, which are (a) that a port could be built with non-default options selected by the sysop and then erroneously overridden by installing/upgrading the package; and (b) one has to ensure that the ports tree tracks the (appropriate) release branch of the operating system and not development head, because that's what the package repositories do.

Address (b), which is in the Handbook's instructions, and simply don't mess with options, and really it is smooth sailing. After all, a port is under the covers a way of locally building a package and installing it with pkg.

Apropos "It doesn’t always have to be Linux - An intro to FreeBSD" 🙂

I've had Pi-hole running on Raspberry Pi OS for a decade (more?), but now I'm trying FreeBSD and AdGuard Home on a Raspberry Pi 4. A little bit apprehensive about the ufs file system, but let's see!

#freebsd #raspberrypi #adguardhome

https://github.com/AdguardTeam/AdGuardHome

Alt...

Screen shot of AdGuard Home web interface, showing a couple of hosts using the service

RE: https://mastodon.bsd.cafe/@stefano/116703115443140625

@jana thanks!

I would have added just one point: base system updates no longer require freebsd-update …

#FreeBSD #pkg #pkgbase

Stefano Marinelli » 🌐 2026-06-06 / 2026-06-06
@stefano@mastodon.bsd.cafe

EDIT: here's the link to the video: https://media.ccc.de/v/gpn24-611-it-doesn-t-always-have-to-be-linux-an-intro-to-freebsd

I just finished watching @jana 's wonderful presentation via livestream.

Thank you for mentioning me, and it fills my heart with joy to see that BSD Cafe inspired this journey into the wonderful world of BSDs.

In just 20 minutes, so many unique features of FreeBSD were covered in such a positive and encouraging tone - I believe a lot of people will be intrigued after this presentation. In 20 minutes, I wouldn't have managed to say even half of the things Jana successfully illustrated.

I highly recommend everyone watch the recording as soon as it becomes available.

Thank you, Jana, on behalf of the whole BSD community (and especially from its barista)!

#RunBSD #FreeBSD #ThankYou

@stefano
@jana

Thank you Jana for this great talk and introduction to FreeBSD.

#GPN24

#Linux #BSD #FreeBSD #RunBSD #Linux #OpenSOurce

EDIT: here's the link to the video: https://media.ccc.de/v/gpn24-611-it-doesn-t-always-have-to-be-linux-an-intro-to-freebsd

I just finished watching @jana 's wonderful presentation via livestream.

Thank you for mentioning me, and it fills my heart with joy to see that BSD Cafe inspired this journey into the wonderful world of BSDs.

In just 20 minutes, so many unique features of FreeBSD were covered in such a positive and encouraging tone - I believe a lot of people will be intrigued after this presentation. In 20 minutes, I wouldn't have managed to say even half of the things Jana successfully illustrated.

I highly recommend everyone watch the recording as soon as it becomes available.

Thank you, Jana, on behalf of the whole BSD community (and especially from its barista)!

#RunBSD #FreeBSD #ThankYou

Hello, BSD and Linux friends!

Don't miss @jana 's great presentation later today: "How is FreeBSD different from Linux, what does it do well and why should I care?"

The live stream can be found here: https://streaming.media.ccc.de/gpn24/vortragssaal

The recording will be available afterwards in: https://media.ccc.de/c/gpn24

https://cfp.gulas.ch/gpn24/talk/ZSNZ89/

#Linux #BSD #FreeBSD #RunBSD #Linux #OpenSOurce

LinuxKPI: 802.11: add support for suspend/resume · freebsd/freebsd-src@11d69a4 : r/freebsd

https://www.reddit.com/r/freebsd/comments/1tne7yu/linuxkpi_80211_add_support_for_suspendresume/

If you need the iwlwifi driver and mobility – a laptop, for example:

― FreeBSD-STABLE will be more useful than FreeBSD 15.1-RELEASE.

#FreeBSD #WiFi #wireless #iwlwifi #Intel

Jails don't compete with containers. They don't substitute virtual machines. Jails just fill a gap.

#freebsd #virtualization #jail #container

http://tomsitcafe.com/2026/06/05/freebsd-jails/

Not sure who decided it was a good idea to integrate Rust dependencies into Python modules.

Installing a 1GiB Rust package to build wheel is a waste of bandwidth and time.

#FreeBSD #Python #Rust #WHY

Alt...

x Preparing metadata (pyproject.toml) did not run successfully. | exit code: 1 > [5 lines of output] /tmp/pip-build-env-4onzua_e/overlay/lib/python3.11/site-packages/setuptools/_vendor/wheel/bdist_wheel.py:4: FutureWarning: The 'wheel' package is no longer the canonical location of the 'bdist_wheel' command, and will be removed in a future release. Please update to setuptools v70.1 or later which contains an integrated version of this command. warn ( Python reports SOABI: cpython-311 Unsupported platform: 311 Rust not found, installing into a temporary directory [end of output]

The FreeBSD Developer Summit is happening this month.

Join us June 17–18 in Ottawa, Canada, for two days of focused technical discussions, working groups, and project updates shaping the future of FreeBSD.

The Summit is co-located with BSDCan (June 19–20), offering additional opportunities to connect with the broader BSD community.

Registration is open:
https://bit.ly/4dwDdrI

Dev Summit details:
https://wiki.freebsd.org/DevSummit/202606

#FreeBSD #DevSummit #BSDCan #OpenSource #SystemsEngineering

RE: https://burningboard.net/@Larvitz/116692823826003186

Bastille ftw

#FreeBSD #bastilleBSD

(I'm experimenting with Docker Engine 29.0+ here and, maybe, I'm reinventing the wheel, but...)

I do like #FreeBSD and I like #ZFS. So, I thought, I can use OpenZFS on linux too... With docker... Right... Well....

ZFS storage driver is apparently slow as hell and overlay2 don't really work on ZFS.
So, the best option I found, just create a zvolume, format it with something linux frendly and go with it.
But that's kinda killing entire ZFS idea of having pools of storage you can mess howere you need.

But hey, docker only need overlay for root on it's containers. I can keep everything else on zfs.
And that where it's became interesting (rabit hole)...

Nothing goes to rootfs... MM, why? o_O

https://gist.github.com/anparker/c4c7a6c2f96a253ba6f4fed344d9037c

My first Mastodon 4.5.11 to 4.6.0 beta1 upgrade on FreeBSD has been smooth and successful.
In the coming days, I'll perform more tests (like rising the char limits, etc) to be sure that, when it will be stable, the BSD Cafe upgrade will be smooth as well.

#Mastodon #FreeBSD

The May 2026 FreeBSD Foundation Newsletter is here!

This month, we’re sharing:

- A reminder that FreeBSD Day is June 19, plus a simple way to celebrate (and support the Foundation) through the FreeBSD Foundation Shop
- BSDCan + the FreeBSD Developer Summit are coming up June 17–20 in Ottawa (Dev Summit runs June 17–18). Registration is open.

Read the full newsletter: https://freebsdfoundation.org/news-and-events/newsletter/may-newsletter/

#FreeBSD #OpenSource #BSDCan #FreeBSDDay #Newsletter

EuroBSDCon 2026 Travel Grant Applications Now Open!

The FreeBSD Foundation is pleased to announce that travel grant applications are now open for EuroBSDCon 2026, taking place September 9–13, 2026, in Brussels, Belgium.

📅 Application deadline: July 7, 2026

Learn more about eligibility, guidelines, and how to apply:
https://freebsdfoundation.org/our-work/grants/travel-grants/

#FreeBSD #EuroBSDCon2026 #OpenSource #FreeBSDFoundation

As FreeBSD PKGBASE moves faster then its documentation - some light on these:

- *.pkgnew

- *.pkgsave

- .pkgtemp.*

#freebsd #PKGBASE

https://vermaden.wordpress.com/2026/05/10/freebsd-pkgbase-minor-upgrades/#comment-27442

This is nice:

scan: resilvered 5.99T in 3 days 08:07:36 with 0 errors on Tue Jun 2 06:17:36 2026

#ZFS #Resilver #FreeBSD

#FreeBSD #OpenBSD #NetBSD #badjoke

Latest 𝗩𝗮𝗹𝘂𝗮𝗯𝗹𝗲 𝗡𝗲𝘄𝘀 - 𝟮𝟬𝟮𝟲/𝟬𝟲/𝟬𝟭 (Valuable News - 2026/06/01) available.

https://vermaden.wordpress.com/2026/06/01/valuable-news-2026-06-01/

Past releases: https://vermaden.wordpress.com/news/

#verblog #vernews #news #bsd #freebsd #openbsd #netbsd #linux #unix #zfs #opnsense #ghostbsd #solaris #vermadenday

The #eurobsdcon 2026 Call for Papers: Submit by June 20th!

https://2026.eurobsdcon.org/cfp/

Submit by June 20th, come to Brussels September 9-13 and mingle with #BSD people!

We also offer pre-submission guidance/mentoring, see within.

Wonder what BSD and the conferences are about? See https://nxdomain.no/~peter/what_is_bsd_come_to_a_conference_to_find_out.html

@EuroBSDCon #freebsd #netbsd #openbsd #freesoftware #libresoftware #brussels #bruxelles

BSDCan https://www.bsdcan.org/2026/ Talk Friday 2026-06-19: 14:30 - 15:20 DMS 1130
What has (can) the EU Cyber Resilience Act done (do) for you?
Peter Hansteen
https://www.bsdcan.org/2026/timetable/timetable-What-has-can.html
To register https://www.bsdcan.org/2026/registration.html @bsdcan #cra #cyberresilience #freebsd #openbsd #netbsd

Fetch for x11/nvidia-drm-latest-kmod{-580|-devel} on main (aka latest) branch of #FreeBSD #ports should be fixed now.
https://cgit.freebsd.org/ports/commit/?id=536352bd7c13b49c985d0e07474d7258ba793fbe

So I've submitted PR for upgrading Production Branch of #NVIDIA #GPU #driver ports to 595.80 as Bug 295718 with opening corresponding review D57358.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295718
https://reviews.freebsd.org/D57358

595.80 may be minor bugfix release.
https://www.nvidia.com/en-us/drivers/details/271748/
https://www.nvidia.com/en-us/drivers/details/271745/

And also, submitted PR for upgrading New Feature Branch of NVIDIA GPU driver ports to 610.43.02 as Bug 295720 with opening corresponding review D57359 (-devel variants).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295720
https://reviews.freebsd.org/D57359

610.43.02 seems to have some important fixes for some monitors.
https://www.nvidia.com/en-us/drivers/details/271417/
https://www.nvidia.com/en-us/drivers/details/271414/

At 19:00 I receive a notification: the backup server has problems. I log in and check: a drive had died. No big deal; since it's a RAIDZ1, the system kept running. I had already copied the EFI partitions and set things up, so it would be able to boot from the other drives as well. I request a replacement from Hetzner, which they carry out in less than half an hour. Despite being hot-swappable, the server detects the disconnection of another drive and crashes. At that point, I ask them to look into it, and they test the machine. Reboot: it won't start. I request a KVM console. I get it: I had forgotten to update the ⁠fstab⁠ and it was trying to mount ⁠/boot/efi⁠ from ⁠ada0p1⁠, but ⁠ada0⁠ was the replaced drive, and it wouldn't go any further.
Fixed the ⁠fstab⁠, recreated the partitions, rebooted, and issued the ZFS command for resilvering.
Result: resilvering in progress and backups working again.

I can turn off the computer and start my Friday evening.

#FreeBSD #RunBSD #IT #SysAdmin

Alt...

My laptop, with its BSD Cafe sticker and my glasses on it

Coming next week: a post about the FediMeteo bot, how it works, how it has evolved, and the overall structure of jails. The following week: caching the BSD Cafe Mastodon instances on nginx.

Stay tuned on ITNotes!

#ITNotes #haproxy #nginx #FreeBSD #Mastodon #snac

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

Here is the CPU usage graph for the last 24 hours of the FediMeteo VM. A full 24 hours, during which a huge number of people are connecting, helped by the traction gained from being among the top stories on Hacker News and Lobsters, as well as the many shares across the Fediverse.

RAM usage? Active, around 450 MB. Then there is cache, ARC, and so on. But in practice, zero swap in use after days of uptime.

39 jails running, 39 snac instances, nginx serving the homepage, and HAProxy. HAProxy caching enabled. ZFS snapshots every 15 minutes, backups via zfs send and receive every hour. The same hourly schedule applies to the recalculation of cities, countries, and followers for the homepage.

All of this on a 4 euro per month FreeBSD VM.

If anyone has doubts about the quality and efficiency of FreeBSD, this is the data to show.

#FediMeteo #FreeBSD #RunBSD #IT #SysAdmin

Alt...

Time series graph showing CPU usage percentage over roughly 24 hours. The x axis represents time from about 13:00 to 12:00 the next day, and the y axis shows CPU usage from 0 to 100 percent. CPU usage fluctuates mostly between 15 and 35 percent, with periodic rises during daytime and early morning hours. Several short spikes reach around 45 to 55 percent, and one brief peak climbs to about 60 percent. Usage drops to lower levels, around 10 to 20 percent, during late evening and early morning periods. Overall, the graph shows moderate, variable CPU load with occasional sharp peaks.

This morning, as the zfs-send/receive had finished its job during the night, I performed the last sync and moved FediMeteo from the previous 4 euros/month VPS - netcup - to a 4 euros/month VPS - OVH, Milano, Italy.

Thanks to #BastilleBSD and the jail setup, it was easy peasy.

So, the weather forecasts are now broadcast from Italy and the performance has skyrocketed - while still being served by a 4 euro/month VPS.

I suspect the netcup VM had been capped by the provider - but I'll investigate.

So...Ciao, FediMeteo!

https://fedimeteo.com

#FreeBSD #RunBSD #OwnYourData #VPS #FediMeteo

In the past few days FediMeteo seemed to be having some performance trouble. I dug into it and only found minor issues, until I realised the VM itself had fallen off a cliff. After several reboots it became clear that both bandwidth and I/O latency had dropped to absurd levels. I suspect the provider slapped a cap on it.

So I took the chance to move everything to another VM and provider, still at 4 euro per month. And starting today, forecasts will be delivered straight from Italy. The performance jump feels like going from a storm to clear skies.

FediMeteo’s mission goes on. More countries are coming (stay tuned!) and we will keep aiming to serve everything from a 4 euro VM. I do have powerful hardware available, but proving that the project can run on tiny resources is still part of the mission.

#FediMeteo #FediMeteoAnnouncements #FediMeteoServices #VM #RunBSD #FreeBSD

Static Web Hosting on the Intel N150: FreeBSD, SmartOS, NetBSD, OpenBSD and Linux Compared

Update: This post has been updated to include Docker benchmarks and a comparison of container overhead versus FreeBSD Jails and illumos Zones.

https://it-notes.dragas.net/2025/11/19/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openbsd-linux/

#ITNotes #freebsd #illumos #jail #linux #netbsd #openbsd #ownyourdata #server #smartos #sysadmin #zoneshosting

https://it-notes.dragas.net/2025/11/19/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openbsd-linux/

#ITNotes #NoteHUB #freebsd #illumos #jail #linux #netbsd #openbsd #ownyourdata #server #smartos #sysadmin #zoneshosting

the list

#unix_surrealism #comic #poster #openbsd #freebsd #netbsd #dragonflybsd #9front #plan9 #glenda #cirno #girl #daemon #puffy #rabbit #mata #openblade #penguin #linux #foss

Alt...

MATACORP'S MOST WANTED HACKERS Fish Daemon Cirno OpenBlade Rabbit Frederick "the Hammer" Glenda II Sphence Purple "Penguin" Pentium-M Man Girl

This Isn't a Battle

After reading a post describing the FreeBSD community as 'toxic', I share a different perspective. This isn't a battle. It's a reflection on coexistence, the original Open Source spirit, and the quiet richness of taking a different path.

https://my-notes.dragas.net/2025/11/14/this-isnt-a-battle/

#MyNotes #IT #SysAdmin #FreeBSD #NetBSD #OpenBSD #Linux #OpenSource

#beastie #freebsd

Alt...

A cute crocheted red daemon, pretty similar to FreeBSD's mascot

FediMeteo: How a Tiny €4 FreeBSD VPS Became a Global Weather Service for Thousands

https://it-notes.dragas.net/2025/02/26/fedimeteo-how-a-tiny-freebsd-vps-became-a-global-weather-service-for-thousands/

#Fediverse #FreeBSD #RunBSD #Hosting #ITNotes #Networking #NoteHUB #Server #Snac #Snac2 #Social #Web

Some technical details for those interested:
The entire FediMeteo setup runs on a FreeBSD VM costing around 4 euros per month. It supports almost all major EU countries (plus the UK), with just a few left to complete. Currently, there are 25 separate jails, each running its own instance of snac, totaling 25 instances. The VM load typically stays around 10%, which increases to 30% when updates are published for countries with larger numbers of cities (currently Germany and Italy). The only time the load spikes is when new countries are announced; during that time, all remote instances connect to all cities to download their details.
As for RAM usage, excluding the ZFS cache, it's currently a total of 213 MB. Yes, MB.

#FreeBSD #FediMeteo #snac #Fediverse #Efficiency #RunBSD

Client: Help, emergency. I have 24 hours to move my workload to another server. What do we do?
Me, five minutes later: "Done. Your workload is now running on the new server."
Client: "How did you move over 200GB with just a minute of downtime, from one provider to another and in a different country?"
Me: "Thanks to FreeBSD, ZFS, and a little bit of proactive planning."

I have a task that replicates all the VMs from one server to another every 15 minutes using zfs-send/zfs-receive. This VM connects to a VPN with two reverse proxies.
Meaning, when I move this VM, we don’t need to change any IPs since it’s not directly exposed.
I powered it off, cloned the differences in seconds, and restarted it.

Client in disbelief.
Me, relaxed and happy.

Thank you, FreeBSD, thank you, ZFS!

#FreeBSD #ZFS #TechSupport #ServerMigration #OpenZFS #SysAdmin #RunBSD

Announcing FediMeteo – Weather in the Fediverse!

UPDATE: I have created an account for updates and other information on FediMeteo - follow the account @admin to stay updated!

UPDATE: Ireland, Poland, Portugal and Switzerland have just been added

Weather has always influenced our lives: from agriculture to outdoor activities, to extreme events that, thanks to modern technology, can now be predicted with greater reliability. Personally, weather plays a significant role in my daily decisions, which is why I decided to create a service tailored for the Fediverse.

FediMeteo uses Open-Meteo data to publish updates every 6 hours, including current weather conditions, forecasts for the next 12 hours, and predictions for the upcoming days. Each country is served by its own dedicated instance (e.g., it.fedimeteo.com for Italy), managed through snac to ensure simplicity and efficiency in publishing.

You can follow FediMeteo directly in the Fediverse (on Mastodon and compatible platforms), via RSS, or by visiting the dedicated page for your city (e.g., fr.fedimeteo.com/paris).

Currently supported countries include:
Austria, Germany, France, Ireland, Italy, Netherlands, Poland, Portugal, Spain, Switzerland and the United Kingdom, – with many more regions coming soon!

FediMeteo is hosted on a FreeBSD-based VPS, with each country isolated in its own jail to ensure security and scalability.

Visit the main site to explore the national instances and start following your local weather updates today:
https://fedimeteo.com

Happy weather monitoring to all! 🌦️

FediMeteo is dedicated to my grandfather, who every evening would give me the weather forecast based on TV, radio, and his personal experience. He would convince me that the weather would be bad, so he had an excuse to accompany me to school instead of me going alone.

#FediMeteo #Announcements #FreeBSD #FediMeteo #WeatherForecasts #Weather #Meteo #snac #Fediverse #Mastodon

Right so my personal #snac instance seems to be working ok and I have managed to import all of the accounts I follow here on bsd.cafe . I'll still be using this account but will try and see how I get on with snac. You may notice that it always shows that I have no followers and that I'm not following anyone. This is intentional by the author of #snac as they feel numbers should not matter which is quite true. Feel free to follow me over there if you haven't already and hello to any new followers.
@justine@snac.smithies.me.uk
All of this is hosted in my #HomeLab on a #FreeBSd server jail running over my home FTTP connection. I'm impressed I've gotten this far. Next I'll be doing some html and css customisation's to theme it a little.

**BSD Mail Project Update!**

Hello everyone! I wanted to share some exciting updates about the development of BSD Mail, our privacy-focused email service designed with robustness, security, and transparency in mind. Here’s a deep dive into the technical choices I've made, focusing on my use of open source solutions and open protocols:

🌍 **Servers & Location**

- We're running on two physical servers:
- One hosted by OVH in France
- Another by Hetzner in Germany
- Both servers operate on FreeBSD with NVMe drives in a ZFS mirror configuration for speed and data integrity.

🔒 **Virtualization & Security**

- We utilize jails on both servers to ensure isolated environments for different services, managed via BastilleBSD. On one server, jails are set up directly on the hardware, whereas the other server employs nested jails.
- Each server hosts a bhyve VM running OpenBSD with OpenSMTPD for handling SMTP duties securely.

🔗 **Networking**

- A Wireguard setup connects the two servers, facilitating routing capabilities so that jails and VMs can communicate seamlessly, supporting both IPv4 and IPv6.

📧 **Email Services**

- **Dovecot** is configured for maildir replication across the servers using Dovecot sync, ensuring email availability and redundancy.
- **Rspamd** instances are tied to local KeyDB jails, set up in master-master replication for consistent and reliable spam detection and greylisting.
- **ClamAV** runs in corresponding jails for virus scanning, maintaining a high level of security.
- **SOGo** provides a web interface for email management, connected to MySQL databases in master-master replication to handle sessions and authentication smoothly.

💾 **Data Management**

- Email data is stored on separate, encrypted ZFS datasets to secure emails at rest.
- MySQL databases are used for storing credentials and managing sessions for SOGo, also in a master-master replication setup. Importantly, all passwords are securely hashed using bcrypt, ensuring they are salted and safe.

🔎 **Monitoring & Reliability**

- Our DNS is managed through BunnyNet, which continuously monitors our server status. Should one server—or a specific service—become unavailable, DNS configurations are dynamically adjusted to avoid directing users to the affected IP until full service is restored.

🌐 **Commitment to Open Source and Open Protocols**

- Every component of BSD Mail is built exclusively using open source software and open protocols. This commitment is crucial for ensuring data freedom and the reliability of the solutions we use.

This setup not only emphasizes our commitment to privacy and security but also our dedication to maintaining an open and transparent platform.
We're excited to bring you a service where your privacy, data integrity, and freedom are prioritized. Stay tuned for more updates!

#BSDMail #OpenSource #Privacy #FreeBSD #OpenBSD #EmailHosting #Email