Latest Posts

Good thing the music of our youth was played loud. Now that age is making me hard of hearing, that makes life a lot easier.

Led Zeppelin, The Who, Deep Purple, Black Sabbath: they never needed a volume knob turned up. Back then my parents said it would ruin my ears. They were right, but it was worth it. And Jimi still comes through loud and clear.

New for logged-in users: server graphs under /mrtg

iBoard runs on a small server of its own: beat, a virtual machine with two CPUs and 4 GB of RAM at Infomaniak in Switzerland (how it got there). From today on, everyone who is logged in can see how it is doing: iboard.cc/mrtg.

What you see

Seven graphs, updated every five minutes:

• Load average and CPU usage – how busy the two CPUs are
• Memory – used and page cache
• Disk space – used and free on the 60 GB disk
• Network – traffic in and out
• TCP connections – open connections to the server
• Response time – how long the front page of this blog takes, measured from the server itself

The overview shows the last 24 hours. A click on a graph opens the week, the month and the year, with average and maximum for each. The pages follow the theme you chose here on the blog, light or dark.

The history starts on 18 October 2026, so the curves are still short. They grow every five minutes.

Why

In half a year of iBoard I wrote about who reads here (mostly machines). The server graphs are the other half of that story: what all those requests cost the server. Transparency should not stop at the visitors.

How it works

The graphs come from MRTG, Tobi Oetiker’s tool from 1995. It still does exactly one thing well: draw a value over time. MRTG runs in a small container next to the blog and reads its numbers straight from the Linux kernel (/proc), every five minutes.

The pages are static files. Before the web server delivers one, it asks the blog whether you are logged in. If you are not, you land on the login page and come back to the graph afterwards. No second password, no extra account.

Don’t have an account yet? Register here.

Die KPÖ Oberösterreich hat am 21. September eine Anfrage an den Linzer Bürgermeister veröffentlicht, die mich positiv überrascht hat. Gemeinderat Michael Roth-Schmida will von Dietmar Prammer wissen, wie es um die IT-Sicherheit und den Datenschutz im Magistrat Linz bestellt ist — konkret bei jenen Daten, die über Microsoft 365 verarbeitet werden.

Gefragt wird nach den Dingen, die man fragen muss:

• welche technischen und organisatorischen Schutzmaßnahmen es gibt (Verschlüsselung, Authentifizierung, Zugriffsüberwachung),
• wo die Daten tatsächlich liegen und ob sie die EU verlassen,
• wie das neue Netz- und Informationssystemsicherheitsgesetz (NISG 2026) umgesetzt wird,
• wie Sicherheitsvorfälle erkannt und gemeldet werden,
• und ob Open-Source-Alternativen wie openDesk oder Nextcloud überhaupt geprüft wurden.

Besonders der letzte Punkt freut mich. Die Diskussion um digitale Souveränität wird in Österreich meist geführt, als wäre sie ein Luxusthema für Nerds. Dabei geht es um etwas sehr Bodenständiges: Eine Stadtverwaltung verarbeitet die Daten ihrer Bürgerinnen und Bürger. Wenn diese Daten auf Infrastruktur liegen, deren Betreiber einer fremden Rechtsordnung unterliegt, dann ist das keine technische Detailfrage, sondern eine politische.

Andere haben das längst vorgemacht — Schleswig-Holstein steigt konsequent auf offene Software um, und auch in mehreren deutschen Kommunen läuft openDesk im Echtbetrieb. Es geht also. Es kostet Arbeit, und es kostet in der Übergangsphase Nerven, aber es ist keine theoretische Übung.

Ob die Anfrage eine brauchbare Antwort bekommt, steht auf einem anderen Blatt. Anfragen dieser Art werden gerne mit Verweisen auf bestehende Verträge und Zertifizierungen beantwortet. Trotzdem: Dass die Frage in einem Gemeinderat überhaupt gestellt wird, ist ein Fortschritt. Man muss die Fragen stellen, bevor man Antworten bekommt.

Ich bin gespannt, was aus der Sitzung am 24. September herauskommt.

Version 1.0.0 is out. It collects a single day of work around one idea: this blog should be writable from the place where articles are actually written — a text editor and a terminal.

What is new

A JSON API. Six endpoints, authenticated with a bearer token, cover the whole life of an article: create it, upload its attachments, publish it, read it back, revise it. A key belongs to exactly one user and acts as that user, so nothing about visibility or ownership changes just because the request came from a script.

A client. post-article takes a Markdown file with a short front matter block and does the rest: create the draft, upload the images, publish on request, notify the followers only when asked. Drafts are the default, because the only step that cannot be undone is the e-mail.

Key management in the browser. Admins mint and revoke keys under API Keys, with a guide on the page itself: where to store the key, which commands to run, what each endpoint does, and where the limits are. A new key is shown exactly once — only its hash is kept.

An audit trail. Every API call is recorded with method, path, status, IP address and the name of the key that made it. Rejected calls are recorded too. Whatever a script did, the audit log knows which key did it.

Downloads. The client and the agent skill can be fetched straight from the documentation, so a new machine needs nothing but a browser.

Smaller repairs along the way

Reading the first API-written article back from the site turned up three things worth fixing:

• The client split articles at the language separator even when that line sat inside a code example, cutting the text in half.
• The language switch on an article drew a border around the language you were not reading, which looked like the button to press.
• Relative timestamps only knew how to phrase the past, so a key valid for another year politely reported that it expired “just now”.

Try it

mix w_app_core.api_token create you@example.com --label laptop
post-article --check
post-article --publish article.md

This post was written in an editor and sent from a terminal.

This blog now accepts articles over a JSON API. Write the text in your editor of choice, run one command, and the post lands here — as a draft first, so nothing goes out before you have read it in its final shape.

Why bother

The editor in the browser is fine for a quick note. It is less fine when the text already exists as a file, when the screenshots sit in a folder next to it, or when the article is the last step of a script that has just finished a release. For those cases the blog got an API.

The shape of it

Six endpoints, all authenticated with a bearer token:

GET   /api/me                        the user behind the token
POST  /api/posts                     create a post (draft by default)
GET   /api/posts/:id                 read one of your own posts
PATCH /api/posts/:id                 revise a post, field by field
POST  /api/posts/:id/attachments     upload a file
POST  /api/posts/:id/publish         publish, optionally notify followers

A key belongs to exactly one user and acts as that user, so the same visibility and ownership rules apply as in the browser. Keys are stored hashed, expire after a year, and are minted and revoked by an admin under API Keys.

One command

The interesting part is the client. An article is a Markdown file with a small front matter block:

---
subject: The English headline
subject_de: Die deutsche Überschrift
tags: elixir phoenix
visibility: public
attachments:
  - diagram.png
---
The English body. Embed the image with {diagram.png}.

--- de ---

Der deutsche Text, wieder mit {diagram.png}.

Then:

post-article --publish article.md

The script creates the draft, uploads the attachments, publishes, and prints the URL. Leave off --publish and you get a draft to review. Add --notify and the followers get the usual e-mail — with the images already in place, which is exactly why uploading happens before publishing.

What it does not do

It does not unpublish, it does not delete, and it will not let you touch someone else’s post. Those stay in the browser, where a mis-click is visible and reversible. Revising works, though: a PATCH changes exactly the fields it is given — this very paragraph arrived that way. Every API call is written to the audit log with method, path, status, IP and the name of the key that made it, so it is always clear which script did what.

This article was posted with the command above.