DEV Community: Daniele Michelin

Alpine Linux: which versions still get updates

Daniele Michelin — Sun, 15 Nov 2026 07:33:41 +0000

Which versions still get updates, which only security fixes — and which none. Updated daily.

Recommended: Alpine Linux 3.24 (latest 3.24.4) — the newest version with full support.

Version	Latest	Released	Supported until	Security fixes until	Status
3.24	3.24.4	9 June 2026	—	1 June 2028	supported
3.23	3.23.8	4 December 2025	—	1 November 2027	supported
3.21	3.21.10	5 December 2024	—	1 November 2026	end of life
3.20	3.20.10	22 May 2024	—	1 April 2026	end of life
3.19	3.19.9	7 December 2023	—	1 November 2025	end of life
3.18	3.18.12	9 May 2023	—	9 May 2025	end of life
3.17	3.17.10	22 November 2022	—	22 November 2024	end of life
3.16	3.16.9	23 May 2022	—	23 May 2024	end of life
3.15	3.15.11	24 November 2021	—	1 November 2023	end of life
3.14	3.14.10	15 June 2021	—	1 May 2023	end of life
3.13	3.13.12	14 January 2021	—	1 November 2022	end of life
3.12	3.12.12	29 May 2020	—	1 May 2022	end of life
3.11	3.11.13	19 December 2019	—	1 November 2021	end of life
3.10	3.10.9	19 June 2019	—	1 May 2021	end of life
3.9	3.9.6	29 January 2019	—	1 November 2020	end of life

Dates checked every day on the page: https://daniele-michelin.com/en/versions/alpine-linux/

Full table, kept up to date every day: daniele-michelin.com/en/versions/alpine-linux/

First published at daniele-michelin.com. End-of-support dates for 25 products, plus an error lexicon of 149 messages, in German, English and Italian.

Microsoft 365 was down for over twelve hours: what the outage says about our dependency

Daniele Michelin — Sun, 15 Nov 2026 07:32:40 +0000

It started unspectacularly: Outlook could not connect to the mailbox. Anyone who assumed their own network was at fault restarted Outlook, then the computer, then the router. Two hours later it was clear the router was not the problem: Microsoft had a global outage hitting Exchange Online, Teams, SharePoint Online, Copilot and a long tail of other services — and it was still not fully over on Friday morning.

What happened on 12 November 2026

Microsoft published two incidents in the admin center. EX1550543 covers Exchange Online, the mailbox behind Outlook, starting at 11:17 a.m. Eastern — 17:17 CET. MO1550821 followed at 1:26 p.m. Eastern and lists the services dragged in with it: Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR, plus Planner, To Do, Intune, Purview, parts of Power BI, Universal Print and, in some setups, Windows 365 Cloud PCs.

Important for scale: what was affected were the parts that depend on Exchange Online. In Teams, chat and running meetings kept working, but calendars and scheduling did not. Files in SharePoint still opened. It was not a total product failure, it was a failure of the shared middle — and in Microsoft 365 that middle hangs off one identity, one tenant and one mail service.

The timeline, as far as Microsoft published it

Time (CET)	What Microsoft reported
17:20	Investigating a possible problem with Exchange Online.
18:45	Connection errors in the part of Exchange Online that accepts logins and mailbox requests.
19:27	Infrastructure under heavy load in several regions; restarts and traffic shifting begin.
20:30	The load is not coming from more requests: a large number of servers dropped out of service unexpectedly. Microsoft pauses its own deployments.
20:58	The servers fail automatic health checks — the fault may sit in the part that answers those checks.
23:03	The actions so far "have not provided the anticipated relief".
01:12	The overwhelmed process is the one that sets up secure connections (TLS). Microsoft starts rolling back a recent network configuration change.
02:48	Restarts show "positive results", first regions recover.

As of Friday morning there was no confirmed root cause, only a preliminary technical explanation. Microsoft stated repeatedly that it saw no indication of malicious activity. More than 130,000 reports piled up on Downdetector alone.

What the outage teaches technically

Three things stand out, and none of them is a Microsoft problem in the narrow sense.

First: the trigger was not an attack and not data loss, but a health check that removes servers from service. That is exactly the intended behaviour — it just caught too many servers at once, at the wrong moment. Automation without a manual escape hatch scales mistakes.

Second: a single overwhelmed process for secure connections was enough to make mailboxes unreachable. If you think of mail as "just storage", you underestimate the chain: DNS, TLS, auth, mailbox, client. Any link can stop the whole thing.

Third: the 99.9 percent availability in the SLA sounds like "almost always". A 30-day month has 43,200 minutes, 0.1 percent of that is 43 minutes. An outage of this length blows the monthly target for many customers. The remedy is a credit on the monthly bill — not automatic, on request, and it does not replace a lost workday.

The real dependency is identity

What actually failed during those twelve hours was not Outlook. It was the anchor everything else hangs from: if you cannot sign in, you cannot open files, see appointments, schedule a meeting, approve something and — with Teams Phone — you cannot even make a call. A mailbox today is rarely just a mailbox. It is the login, the calendar, the chat, the archive and often the second factor for authentication.

This is not a criticism of cloud, it is a description of the architecture. Putting office communication into one tenant buys convenience, versioning and operations — and pays with a shared failure point. That is a deliberate trade-off, as long as it is made deliberately.

What Nextcloud replaces — and what it does not

After a day like this the question is inevitable: "why not self-host everything?" The honest answer is more nuanced than either camp likes.

Building block	Nextcloud	Note
Files & sync	yes, with versions and trash	The desktop client keeps selected folders available offline.
Calendar & contacts	yes (CalDAV/CardDAV)	Works in Thunderbird, Apple Calendar, Android and iOS without the web login.
Chat & video calls	yes (Talk)	A good base for internal calls; it does not replace Teams telephony.
Editing documents	via Collabora/OnlyOffice	Solid for most documents, not feature-parity with Word.
Mailbox	no	Nextcloud is not a mail server. A mailbox needs its own MX or another provider.
Phone system	no	Anyone using Teams Phone needs a separate solution.

So Nextcloud covers a large part of the office day — files, calendar, contacts, chat, documents — but it is not an Exchange replacement and not a phone system. Claiming otherwise builds the next disappointment. Separating it cleanly wins exactly what this is about: a piece of infrastructure you can see yourself.

"Everything under control" does not mean "it never breaks"

Self-hosting is not automatically more reliable. A single server is a single point of failure, a forgotten update is a security risk, and a backup with an untested restore is data loss on a delay. The difference is not the probability of failure, it is the ability to act:

Logs: you can see which process did what and when, instead of waiting for a status message.
Update timing: you decide when to update — and you can plan a rollback instead of suffering one.
Data: files and calendars live where you can back them up and restore them.
Communication: you can explain what is going on, because you can trace the cause yourself.

Control is not a guarantee, it is the ability to act when it matters. Which is exactly what most Microsoft customers could not do on Thursday: they could wait and refresh the status page.

What I would check in one hour

Whether you run Microsoft 365, Nextcloud or both, these seven points are cheap and pay off during the next outage:

A contact list outside the system: key customers, vendors, mobile numbers. Printed, or in a notes tool that does not hang off the same login.
A second communication path: a Signal group, a phone chain or a chat outside the tenant — decided in advance and circulated, not on the day of the outage.
Files available offline: keep the five documents a workday cannot run without on the device (Nextcloud client or "always keep on this device").
One person who says "it's Microsoft": check the status page instead of reinstalling Outlook. Publicly reachable: status.cloud.microsoft.
Check scheduled jobs: scan-to-mail, Universal Print, automatic invoices, forms, voicemail-to-mail. These fail quietly and surface only when a customer asks.
Test restores, don't just own backups: restore one file and one mailbox per quarter — with a stopwatch.
Check your own reachability: MX, SPF, DMARC and the externally visible endpoints. The mail DNS check and the Nextcloud check run without a login and show what the outside world sees.

And Thursday's mail?

Usually delayed, not lost. A sending mail server must retry for at least four to five days before giving up, per RFC 5321. If you are waiting for a signed contract or a bid, call instead of waiting. And if you wrote messages during the outage: check the outbox, do not blindly resend.

Then comes the unpleasant part that follows every large outage: phishing with the story "your mailbox has been restored, please sign in again". No provider asks for a fresh login via an email link during or after an outage. The scam radar collects exactly these patterns.

Bottom line

Thursday's outage was not proof that cloud does not work. It was proof of how much now hangs off a single identity — and how little any one company can do when that identity disappears. If you know the dependency, you can shape it: a clear view of what is truly critical, a second path for communication, and a remainder you control yourself.

For me that means: files, calendars and contacts in my own Nextcloud, with the versions and their end-of-support dates in sight — and something I can check from the outside. Everything under control is not a state, it is a practice.

The dates when the versions in use leave support are in the end-of-life calendar, including a subscribable calendar file. The next outage is coming; the only question is whether it catches you by surprise.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

The day after the Microsoft 365 outage: what we learned and what you can do now

Daniele Michelin — Sat, 14 Nov 2026 13:00:05 +0000

On Thursday 12 November 2026, Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot and Defender XDR failed or ran degraded worldwide. This post sorts it out: what is documented, what is still open, what we learn from it, and what you can do today without rebuilding your whole infrastructure.

The question of how dependent you want to be on a single vendor is covered in Microsoft 365 outage and dependency. This post is about the analysis and the concrete steps afterwards.

State of the information: Microsoft has not published a final post-incident review yet. Everything below rests on Microsoft's status updates as summarised by BleepingComputer and on a technical analysis by Control Plane. The analysis is an interpretation, not a confirmation by Microsoft.

What is confirmed

Start: the main incident (admin center ID MO1550821) began on 12 November at 18:26 UTC with Exchange Online problems in the Americas and spread to other regions and dependent services. A shorter Teams incident (TM1550488) ran the same day between 14:45 and 15:53 UTC; Microsoft has not said whether the two are related.
Cause according to Microsoft: first elevated load, then a number of servers becoming unexpectedly unavailable and straining the rest, later a core process on affected servers being overwhelmed. Traffic did not rise. What triggered the first failures has not been published.
No attack: Microsoft sees no sign of malicious activity.
Mitigation: deployments paused, traffic redistributed, servers restarted, the health-check method switched, a few recent configuration changes reviewed for rollback, and the mail delivery timeout window extended to 48 hours.
Recovery: on 13 November Microsoft reported improvement in North America and much of Europe, and significantly shorter mail queues by the afternoon. Reports from 14 November say services are back; an official end and root-cause report are still outstanding.

What the analysis suggests (not confirmed)

The description fits a known pattern, the cascading failure: health checks take sick servers out of rotation, their load lands on the remaining ones, and those fail the checks too. The load per server keeps rising although traffic stays flat. Servers that were returned to service are said to have failed again under load. That explains why recovery took hours and not minutes. It does not explain what caused the first failure; that is the question for the final report.

What we learn from it

One vendor, one big blast radius. Mail, chat, files, calendar and Defender XDR ran on one strand. If you detect incidents in Defender and discuss them in Teams, you were blind and mute at the same time during the first hours.
Alerts by mail through the same vendor are not alerts. When the vendor fails, the warning does not arrive either.
The status messages changed. From “elevated load” to “servers unavailable” to “core process overwhelmed”. That is normal while debugging, but it means: do not pass on first assessments as the final word.
Recovery has a long tail. Even after “it works again”, queues drain and mail arrives late.
Rumours arrive instantly. “Cyberattack” shows up in every big outage. Wait for the vendor's statement and tell your team only what is documented.

Ten steps for today

Find out what was lost. Check the mail queue and the bounce messages of your mail gateway for messages from 12 and 13 November that did not arrive. Ask important senders.
Define a communication path outside Microsoft. A phone tree, a messenger or an emergency page on different infrastructure. Write down who triggers it and who announces it.
Set up two emergency admin accounts (cloud accounts, separate from the normal ones, strongly protected and monitored). Microsoft describes this as emergency access accounts.
Route alerts over a second path. Monitoring that emails you also needs SMS, push or another mail provider.
Monitor from outside. A small test that regularly sends a mail to your mailbox and checks that it arrives shows you an outage before your colleagues do. Also subscribe to the service health feed.
Know your MX and DNS setup. What are the TTLs, who manages the zone, what happens to inbound mail when your mailbox provider is silent for 48 hours? The mail DNS checker shows MX, SPF, DKIM and DMARC of a domain in one step. Do not change MX records in a panic in the middle of an outage; plan a solution beforehand.
Map what depends on mail. Password resets, two-factor codes by mail, invoice sending, ticket system, forms. Write the list down and decide what needs a second path.
Rehearse the emergency for 15 minutes. Play it through: mail and Teams are gone, how do you reach customers and the team? Fix gaps immediately.
Document the damage and read your contract. Duration, affected processes, costs. Check whether service-level credits in your agreement apply and by when you must claim them.
Decide deliberately what should run separately. Not everything has to leave Microsoft. But for a few critical things (emergency communication, alerting, credential recovery) a second provider or a service of your own is worth it, for example a chat room on a self-hosted Nextcloud Talk. That is an addition, not a replacement, and it needs its own care.

What to avoid

Do not loosen security settings to “get back to work faster”.
Do not make bulk changes to DNS or accounts in the middle of an outage.
Do not pass guesses about the cause on to customers.

Once Microsoft publishes its final report I will update this post. Until then: the outage was a test you did not plan. Use the result.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

UnrealIRCd CVE-2026-114713: how to check your server and apply the hot-patch

Daniele Michelin — Sat, 14 Nov 2026 12:59:04 +0000

In short: if you run UnrealIRCd 6.0.0 to 6.2.7 (or version 5), your server is affected. Version 6.2.7.1, released on 7 November 2026, fixes it, and a hot-patch does the job without a restart. The vendor reports attack attempts, and the US agency CISA added CVE-2026-114713 to its catalog of exploited vulnerabilities on 13 November (deadline for federal agencies: 16 November).

What is the problem?

The implementation of the IRCv3 label tag does not escape characters properly when it echoes the tag into replies. An ordinary user can therefore inject newlines and other characters into the traffic between linked servers. The injected commands run with the authority of the server, for example KILL or GLINE. The maintainer found the flaw himself in an internal audit done with the help of AI.

The CVE description mentions networks with two or more linked servers. The vendor advisory does not say so explicitly. Do not rely on it and patch a single server as well.

Are you affected?

UnrealIRCd 6.0.0 to 6.2.7: yes.
UnrealIRCd 5: also affected, a workaround is below.
Check distribution packages: according to the Red Hat entry, EPEL 9 currently ships unrealircd-6.1.10-1.el9, which is affected.

Apply the hot-patch

On every server of the network, as the user that runs UnrealIRCd (works for 6.0.0 to 6.2.7):

./unrealircd hot-patch bundle-20261107

Success shows in the last line: “Patch installed and server rehashed correctly. All should be good now!”

Check that the patch is active

./unrealircd module-status | grep labeled-response

labeled-response 5.0-hot-patch-bundle-20261107: the hot-patch is installed.
Version 6.2.7.1: the fixed release is running.
Only 5.0 without a patch bundle: the patch is still missing.
No output: the command needs UnrealIRCd 6.0.2 or newer. As an IRCOp you can also use MODULE -all in chat (for another server MODULE -all server.name).

If the hot-patch does not work

On Linux and other Unix systems, upgrade and restart:

./unrealircd upgrade

On Windows, download 6.2.7.1 and restart.

A stopgap for now

As an IRCOp you can use a spamfilter. According to the advisory it protects against the critical issue only if all servers run UnrealIRCd 6.0.4 or newer:

SPAMFILTER add -regex T block - Invalid_label ^label=(?![^\r\n;\x20]*\z)

On UnrealIRCd 5, add blacklist-module "labeled-response"; to the configuration of all servers and restart (a rehash is not enough).

Afterwards

Write down which server runs which version and patch level, and since when.
Check the logs: unexpected KILL or GLINE entries can point to abuse (this is my recommendation, not part of the advisory).
The patch fixes nine issues, including IP leaks and several crashes, so the update is worthwhile even without an attack.

This post summarises the advisory by the UnrealIRCd maintainers and the Red Hat entry; I did not reproduce the flaw myself. Other entries CISA added the same day are in the overview of exploited vulnerabilities, for example CVE-2026-123039 (Check Point Gaia).

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

SMTP 421 4.7.0: rate limited – causes & fix

Daniele Michelin — Sat, 14 Nov 2026 07:34:13 +0000

The receiving server temporarily refuses more mail from your IP because volume, reputation or authentication look suspicious – messages stay in the queue and are retried later.

Common causes

A sudden spike in volume, e.g. a newsletter from a new IP without reputation.
Missing or mismatched PTR (reverse DNS) record; Gmail is especially strict for IPv6.
Spam complaints, or a compromised mailbox sending spam.
Missing SPF/DKIM authentication makes the rating worse.

How to check it

Check the queue size

mailq | tail -n 1

Find the senders with the most mails in the queue

mailq | awk '/^[0-9A-F]/ {print $7}' | sort | uniq -c | sort -rn | head

Check the PTR of the outgoing IP

dig -x 203.0.113.10 +short

What actually helps

Let Postfix handle retries – do not run postqueue -f over and over, it makes throttling worse.
Set a PTR that matches the HELO name and make that name resolve back to the IP (forward-confirmed rDNS).
Lock compromised accounts, reset passwords and remove spam with postsuper -d.

FAQ

Are messages lost on a 421?

No. 4xx is a temporary error. Postfix keeps the mails in the queue and retries until maximal_queue_lifetime (5 days by default).

Why does it only happen over IPv6?

Gmail requires a valid PTR and authentication for IPv6 senders. Without a PTR, either add one or make Postfix prefer IPv4 with smtp_address_preference = ipv4.

Full page with every command and the German/Italian version: daniele-michelin.com/en/errors/smtp-421-4-7-0/

First published at daniele-michelin.com. The error lexicon covers HTTP, DNS, TLS, mail, database, PHP, nginx, systemd and Nextcloud, in German, English and Italian.

Incident note: DNS SERVFAIL: find the cause (DNSSEC & more)

Daniele Michelin — Sat, 14 Nov 2026 07:33:13 +0000

Read the signal

Start with the exact wording of the error and its timestamp in the log. Then narrow down the cause before changing anything.

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41234

Narrow down possible causes

The DS record at the registry no longer matches the zone's DNSKEY after a provider change.
Expired RRSIG signatures because automatic re-signing stopped.
Lame delegation: listed nameservers are not authoritative for the zone or unreachable.
Nameservers answer incorrectly or block TCP/EDNS (large responses).

Check before changing anything

Query with DNSSEC data

dig example.com A +dnssec

Same query with checking disabled – if it works, DNSSEC is the problem

dig example.com A +cd

Query the DS record at the parent zone

dig +short DS example.com @a.gtld-servers.net

Query DNSKEY directly at the authoritative server

dig +short DNSKEY example.com @ns1.example-dns.com

Fix and test again

Delete the wrong DS record at the registrar or replace it with the matching one; mind the DS TTL.
When moving a DNSSEC-signed domain, remove the DS first, wait out the TTL, then move and re-sign.
Check and fix automatic re-signing at the DNS provider or in BIND/PowerDNS.
Align NS records at the registry and in the zone.

Then repeat the original action and compare the result with the initial error.

Keep a note for the next ticket

Record the exact error, the check result, the change and the retest. That gives the team a useful starting point next time.

Why does it work for some users but not others?

Only validating resolvers (e.g. 1.1.1.1, 8.8.8.8, many ISPs) return SERVFAIL. Non-validating resolvers still hand out the answer.

Full error guide: DNS SERVFAIL: find the cause and fix it

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

While you were gone: n8n writes the holiday handover and draws a comic about it

Daniele Michelin — Fri, 13 Nov 2026 21:02:52 +0000

Try it first: While you were gone. Pick a person, the length and a comic style, and a few seconds later the handover sits in Nextcloud and the comic on the page.

What you get

A handover note: as Markdown in the Outbox folder of a demo Nextcloud: who covers what, which deadlines fall into the absence window, what to do if which risk strikes.
A Deck card: with the summary, so it shows up on the board the team looks at anyway.
A Talk message: short, with the essentials.
An out-of-office reply: with the cover and the return date, ready to copy.
A five-panel comic: leaving, the mail piles up, something catches fire, the cover saves the day, coming back. Four styles, from detective noir to picture book.

The workflow

Webhook: takes the person, the length (3, 7 or 14 days) and the style from three lists. That is all the page sends.
Fix the demo space: a Code node decides where the workflow may read and write: one calendar, one Deck board, one folder, one Talk room. Every URL is checked against it and the run stops otherwise.
Six reads in parallel: CalDAV REPORT with expand for the events in the absence window, the Deck API for the cards, WebDAV GET for the inbox summary and three project notes, PROPFIND for the Outbox folder and the Talk API for the chat.
Analyse the absence: a Code node does the maths deterministically: what falls into the window, what is overdue, who covers it, which risks exist. In the sample run that was 5 meetings, 10 open mails and 6 handovers.
AI: gpt-oss-120b at IONOS only phrases things: the summary, the out-of-office reply and the five comic panels, in the visitor's language and the chosen style. If a field is missing or the model does not answer, the workflow fills in a template built from the same facts.
Write: WebDAV PUT for the note, the Deck API for the card, the Talk API for the message. Then the workflow cleans up its own older entries.

Why the AI does not do the maths

Who covers whom is not up to a language model. The Code node works it out from calendar, cards and mail, traceably and without hallucinations. The AI only gets the result and may tell it nicely.

The comic and the technique

The comic is drawn in the browser: one description made of simple shapes that is output once as SVG and once straight onto a canvas. That is why the same comic can be downloaded as SVG and as PNG, and the share preview is made from the same drawing. The fonts (Bangers and Comic Neue, both SIL OFL) are hosted on my server.

Honest limits

Everything runs on demo data of the invented Brightside Studio. A file stands in for the IMAP node here so nobody sees real mail.
The cover rules are simple: one fixed buddy per person, finance topics go to Sam. The workflow knows nothing about leave planning, shift models or time zones.
The AI writes the comic in the language of the page. It can be wrong, which is why all facts are shown separately next to it.
The out-of-office reply is only displayed. In real use you would set it with occ dav:absence:set or in the settings; the workflow deliberately does not.

Privacy

Nothing from you is sent to Nextcloud. The result stays on the server for 14 days so that the link works, and the page is set to noindex. For the hourly limit there is a salted hash of your IP address for one hour at most.

Build it yourself

The workflow is available as JSON, as a template only: you have to enter your Nextcloud address, an app password, your Deck board, calendar and Talk room, and swap the inbox file for your IMAP node. More workflows to click are on the n8n overview, for example the office morning.

Now it is your turn: which cover rule is missing in your team? Tell us in the comments.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

The Inbox Beast: an n8n workflow sorts the inbox and feeds a beast

Daniele Michelin — Fri, 13 Nov 2026 21:01:52 +0000

Try it first: the Inbox Beast. One click, a few seconds, and the beast is there.

What you get

A beast in five stages: from egg to kraken, depending on its hunger. It has a mood and comments on the inbox.
Three columns: Do (you must answer yourself), Delegate (someone on the team, by name) and Ignore (newsletters, sales pitches, anything already answered).
A report: three sentences about the state of the mail and one concrete tip.
Real entries in Nextcloud: up to five cards on the demo Deck board, a message in the Talk room and a Markdown file in the Outbox folder.
Two dials: “Answer the most important mails first” and “How long since you looked at the inbox?”. They simulate what would happen without changing anything.

The workflow

Webhook: receives a colour and two numbers. The page sends nothing else.
Fix the demo space: a Code node defines which file, which Deck board, which Talk room and which folder may be used. Every URL of the following nodes is checked against it.
Three requests in parallel: WebDAV fetches Inbox/inbox.json, the Deck API the board, a PROPFIND lists Outbox/.
Rules first: fixed rules sort every mail and give it a priority. The workflow therefore still works when the AI is down.
AI: gpt-oss-120b at IONOS corrects the sorting and writes the report, the quote and the tip. Every answer is validated: unknown categories, invented people and answers about mails that are already answered are dropped.
Compute hunger: a Code node, see below.
Clean up, then write: first the workflow deletes its own earlier cards (they carry a marker in the description) and the oldest reports, then it creates the new ones.
Result: posted to a PHP script with the real HTTP status codes of the writes. The page only says “created” when Nextcloud really answered 2xx.

How the hunger is calculated

Every unanswered mail counts with a weight: 8 for do, 5 for delegate, 1 for ignore. The weight grows with age by up to a factor of 4 (after seven days), so each mail counts weight × (1 + age in h / 48). The sum S is turned into a value between 0 and 100 percent: hunger = 100 × (1 − e^(−S/150)). The stages start at 10, 28, 48 and 70 percent.

The demo inbox holds 14 unanswered mails and the oldest client mail is 120 hours old. That gives 69 percent, a “Big beast”. Answer the three most important mails and hunger drops to 56 percent; with six mails it is 38 percent (stage Beast). Leave everything for three more days and it is 84 percent: kraken.

Safety

The workflow runs in a demo space of a real Nextcloud account: its own folder, its own Deck board, its own Talk room, invented data of the fictional Brightside Studio. It reads a single file and writes only to Outbox/, to one Deck stack and to one Talk room. The page limits the runs (20 seconds between runs, three per hour and visitor, 100 per day), and the workflow only deletes what it created itself. One limitation: the Talk room keeps its messages, the workflow does not delete them.

For your own inbox

Replace the node “Read: inbox.json” with IMAP or Gmail and map the fields id, from_name, from_email, subject, body, age_hours, answered. The Code node “Read the inbox” needs only those. The rules are keywords for an invented studio: for real mail you have to adapt them, and the AI sorting is a suggestion, not a verdict.

Build it yourself

The workflow as JSON contains only placeholders for address, user, Talk room and credentials. You need a Nextcloud with Deck and Talk, an app password as a Basic-Auth credential in n8n and an OpenAI-compatible credential for the AI (the workflow also runs without). Enter board id, stack id and room token in the first Code node. You cannot import the file as it is.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

AlmaLinux: which versions still get updates

Daniele Michelin — Fri, 13 Nov 2026 07:36:20 +0000

Which versions still get updates, which only security fixes — and which none. Updated daily.

Recommended: AlmaLinux 10 (latest 10.2) — the newest version with full support.

Version	Latest	Released	Supported until	Security fixes until	Status
10	10.2	27 May 2025	31 May 2030	31 May 2035	supported
9	9.8	26 May 2022	31 May 2027	31 May 2032	supported
8	8.10	30 March 2021	31 May 2024	31 May 2029	security only

Dates checked every day on the page: https://daniele-michelin.com/en/versions/almalinux/

Full table, kept up to date every day: daniele-michelin.com/en/versions/almalinux/

First published at daniele-michelin.com. End-of-support dates for 25 products, plus an error lexicon of 149 messages, in German, English and Italian.

AI in support: what it does well – and where a human still decides

Daniele Michelin — Fri, 13 Nov 2026 07:36:19 +0000

"Can't the AI just do that?" I hear this question regularly now. My answer: a large part of the groundwork – yes. The decision at the end – no.

Where AI really helps in support

I have worked in 2nd/3rd-level support for years and build my own AI tools on the side. In daily work, three tasks have turned out to be especially useful:

Summarising long logs. A ticket arrives with several thousand lines of log. A language model can say within seconds which errors appear first and when, which repeat and which components are involved. It doesn't replace reading the log, but it shows where to look first.

Finding similar past cases. Many issues have happened before, just described in different words. A semantic search across knowledge articles and resolved tickets – for example with RAG, a search that retrieves matching documents and gives them to the model as its basis – finds them even when the terms don't match.

Preparing a first draft of the reply. Structure, polite wording, the steps in a sensible order. I check the content, but I don't start from a blank page.

Each of these tasks saves only a few minutes. With many tickets per week, that adds up.

Where AI reaches its limits

Language models sound convincing even when they are wrong. A command with an option that doesn't exist, a configuration key from another version, a plausible but invented cause – all of this happens.

More importantly: AI doesn't take responsibility. Whether a workaround is enough or the cause lies deeper, whether a change to a production system is acceptable right now, whether it's better to call a customer than to write – that is still decided by a human who knows the system and the situation.

A model only sees what you give it. It doesn't know the context outside the ticket – last week's maintenance, a known quirk of a setup, a customer's mood after the third contact.

My rules for AI in support

Sources, not claims. Answers from a knowledge base should state what they are based on. Then you can check within seconds whether they are right.
Commands are reviewed before they run. No model suggestion goes onto a customer system unread.
Data stays where it belongs. Logs and tickets often contain personal data. What an external service may see is a question of data protection and company policy, not convenience. Locally hosted models are one option here.
A human closes the ticket. The AI prepares; a human is responsible for the decision and the reply to the customer.

A fast colleague for the groundwork

For me, AI in support is a very fast colleague who reads logs, gathers notes and puts a draft on the table. Tireless and often surprisingly good. But not the one who closes the ticket.

Root cause analysis shows this clearly: a model can spot anomalies and suggest hypotheses. Whether a hypothesis is right only becomes clear when someone tests it on the system.

How to get started

Pick one recurring piece of groundwork, for example log summaries.
Clarify which data may be processed, and where.
Deliberately double-check the results for a while.
Only then hand over further tasks.

That way trust in the tool grows where it is justified – along with a clear picture of where it isn't.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

Power planner: n8n finds cheaper and greener hours

Daniele Michelin — Thu, 12 Nov 2026 16:18:35 +0000

Open the live power planner →

When should the washer, EV or heat pump run? This workflow turns day-ahead prices, carbon intensity and the German power mix into a visual daily plan.

What the page shows

An accessibly labelled 24-hour power clock.
Price curve for today and tomorrow, negative hours and a live marker.
Power mix and carbon, a 7×24 heatmap and best consecutive windows.
Example calculations for five devices with an adjustable surcharge.

How the workflow works

Start: The Schedule Trigger runs hourly at minute 10. A webhook also provides an immediate manual test run.
Fetch: Four HTTP nodes request aWATTar prices, renewable signal, carbon intensity and the public Energy-Charts power mix in parallel.
Merge: The Merge node waits for all four responses and passes them together to the Code node.
Normalise: The code aggregates quarter-hours into hours, assigns every point to Europe/Berlin and handles daylight-saving changes.
Plan: It finds the cheapest and lowest-carbon consecutive windows from one to four hours, builds the 7×24 heatmap and calculates five appliance examples.
Publish: The last HTTP node sends validated JSON to strom-ingest.php with a secret X-Strom-Token.
Store safely: PHP validates the token, ranges and array sizes, atomically replaces the live file and creates the social poster. The page then reads only that static JSON file.

Use the workflow yourself

Download the JSON, import it into n8n and replace the example URL and YOUR-SECRET-TOKEN in “Publish planner”. The target server needs strom-ingest.php and the same server-side token. Test once through the webhook before activating the hourly schedule.

Wholesale price is not your bill

The value is the net DE-LU day-ahead wholesale price. Taxes, grid fees, levies, VAT and supplier margin are excluded. The slider adds 17 ct/kWh as an example only. No savings are guaranteed and this is not advice to switch supplier.

Data: aWATTar; Energy-Charts.info / Fraunhofer ISE; Bundesnetzagentur | SMARD.de (CC BY 4.0). The site is not affiliated with these providers.

Download the n8n workflow as JSON or see more experiments in the n8n collection.

When does your washer run – and when should it run?

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

The sky of the night you were born: an n8n workflow recalculates the stars

Daniele Michelin — Thu, 12 Nov 2026 14:57:49 +0000

Try it first: the sky of your birth night. Enter the date, the time is optional, and the city. A few seconds later the poster is there.

What you get

The sky poster: the stars above your city that night, with the 88 constellations, drawn in a canvas.
Moon phase and planets: how the moon looked and which planets were in the sky.
Numbers: the weekday and how many days have passed since.
Weather: on the day you were born and on your last birthday.
Three events “on this day”: from Wikipedia.
A short portrait: written by an AI from exactly these data.
A preview image: for sharing, with the sky as its motif.

The workflow

Webhook: receives the date, the optional time and the city.
Geocoding: Open-Meteo turns the city into coordinates and a time zone.
Three requests in parallel: the weather (archive for the birthday, forecast for the last one), “On this day” from Wikipedia and the star catalogue.
Code node with the astronomy: sidereal time, azimuthal projection for the poster, planet positions from the JPL Keplerian elements and the moon from a reduced Meeus formula.
AI for the portrait: gpt-oss-120b at IONOS gets only the computed values.
Saving: a PHP script receives the result. The page draws the poster in a canvas, the server renders the preview image with GD.

How accurate is the maths?

I tested the Code node against the astronomy-engine library. The largest error is 0.15 degrees, invisible on a poster. The star catalogue comes from Yale/Hipparcos via d3-celestial (BSD-3): 2061 stars down to magnitude 5.2 and the 88 constellations.

Honest limits:

The planets are approximations from orbital elements, not precision ephemerides.
There is no refraction, so no correction for the bending of light in the atmosphere near the horizon.
Historical time zones and daylight saving depend on the ICU database. For old dates the local time can be off by an hour.
Valid for the years 1900 to 2026.
Without a time the workflow uses a fixed moment in the night. The sky turns 15 degrees in an hour, so the poster is then an approximation.

Privacy

The result is stored for 30 days and can be deleted earlier. No IP address is stored, and the result pages are set to noindex.

Build it yourself

The workflow is ready as JSON to import. Open-Meteo and Wikipedia need no key. For the AI any OpenAI-compatible API will do, and for saving you need a small endpoint of your own. More workflows to click and download are on the n8n overview, for example the Website DNA scan.

Now it is your turn: what was the moon phase on the night you were born? Tell us in the comments.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.