Ein Providerwechsel ist oft schnell gemacht – aber wie zieht man alle bestehenden E-Mails und Ordner sauber um? Genau hier kommt imapcopy ins Spiel: ein schlankes Tool, das IMAP-Konten von einem Server zum anderen kopiert.
Das Problem: imapcopy spricht selbst kein SSL/TLS. Da die meisten Mail-Provider ausschließlich verschlüsselte Ports anbieten, braucht man ein Werkzeug, das zwischen TLS und unverschlüsseltem IMAP vermittelt. Hier kommt stunnel ins Spiel.
Mit dieser Kombination lässt sich ein komplettes Postfach migrieren, ohne dass man alle Mails manuell sichern und neu importieren muss.
sudo apt update
sudo apt install imapcopy stunnel4 -yDamit stehen beide Tools direkt bereit.
Die Beispielkonfiguration von imapcopy befindet sich unter:
cp /usr/share/doc/imapcopy/examples/ImapCopy.cfg .Nun wird sie editiert. Wichtig sind die Anpassungen für Source- und Destination-Server, da diese über stunnel laufen werden:
SourceServer localhost
SourcePort 1143
DestServer localhost
DestPort 1144
DenyFlags "\Recent"
# SourceUser SourcePassword DestinationUser DestinationPassword
Copy "foo" "foosrcpw" "foo" "foodestpw"Erläuterung:
Damit imapcopy mit verschlüsselten Providern sprechen kann, braucht es eine stunnel-Konfiguration. Beispiel:
client = yes
foreground = yes
[imapcopy_src]
accept = 127.0.0.1:1143
connect = alter.email.imap.server:993
[imapcopy_dst]
accept = 127.0.0.1:1144
connect = neuer.email.imap.server:993Hier wird definiert:
stunnel starten:
stunnel stunnel.confMigration starten:
imapcopy ImapCopy.cfgDas Tool kopiert nun alle Mails und Ordnerstruktur von Quelle zu Ziel.
Es muss nicht immer Opsgenie sein – gerade im OpenSource-Umfeld gibt es spannende Projekte, die Status Pages, Incident Management und Monitoring vereinen. Für Teams, die Transparenz lieben und Kosten sparen wollen, sind diese Tools eine hervorragende Wahl.
Cabot gehört zu den älteren, aber bewährten Monitoring-Lösungen. Mit integrierten Checks (HTTP, ICMP, Graphite, Jenkins) und Benachrichtigungen über E-Mail, SMS und Chat bleibt es ein solider Klassiker.
Keep ist ein modernes Incident Response Tool, das stark auf Automatisierung setzt. Alarme können priorisiert, kanalisiert und mit Workflows verbunden werden – perfekt für Teams, die mehr Übersicht im Alarm-Dschungel brauchen.
OpenStatus zielt auf Transparenz für Nutzer. Eine schlanke Statuspage-Lösung, die einfach deployt werden kann und sich ideal eignet, um Services nach außen sichtbar zu machen.
Kener ist minimalistisch und API-fokussiert. Wer eine kleine, aber feine Statusanzeige sucht und nicht gleich ein komplettes Monitoring-Framework benötigt, ist hier richtig.
OneUptime ist der Allrounder unter den OpenSource-Lösungen. Monitoring, Statuspage, Incident Management, On-Call Scheduling – alles in einem. Für Teams, die eine komplette Opsgenie-Alternative wollen, ein spannender Ansatz.
Statusnook punktet mit Einfachheit und fokussiert sich auf Status Pages. Ideal, wenn nur der aktuelle Service-Status öffentlich sichtbar gemacht werden soll.
Uptime Kuma hat sich in kürzester Zeit zum Liebling der OpenSource-Community entwickelt. Es kombiniert einfaches Uptime-Monitoring mit einer hübschen Weboberfläche und ist unglaublich leicht aufzusetzen.
Alle genannten Projekte bieten echte Alternativen für Teams, die keine Lust mehr auf Opsgenie haben. Von minimalistischen Status Pages bis zu umfassenden Incident-Management-Plattformen ist für jeden Anwendungsfall etwas dabei.
Auch wenn es selten aktiv bedacht wird: Jeder Webservice sollte eine Vorstellung davon haben, wie viele Requests er aushalten soll. Rate Limiting verhindert, dass unnötige Last – ob versehentlich oder absichtlich – die Verfügbarkeit gefährdet. Gerade in Kubernetes-Clustern mit einem NGINX-Ingress ist das Mittel der Wahl bereits integriert und muss nur richtig konfiguriert werden.
In der ConfigMap des NGINX-Ingress-Controllers lässt sich ein Limit konfigurieren. Beispiel:
apiVersion: v1
kind: ConfigMap
metadata:
name: ingress-nginx-controller
data:
http-snippet: |
limit_req_zone $request_uri zone=megatoll:10m rate=1r/m;Mit diesem Eintrag wird eine Zone namens megatoll angelegt, die maximal eine Anfrage pro Minute pro Schlüssel ($request_uri) zulässt.
Deployment per Patch:
kubectl patch configmap ingress-nginx-controller -n infrastructure --type merge -p '{"data":{"http-snippet":"limit_req_zone $request_uri zone=one:10m rate=1r/m;"}}'Alternativ lässt sich die Konfiguration auch per Patch-File einspielen:
kubectl patch configmap ingress-nginx-controller -n infrastructure --type merge --patch-file ./manifests/additional_ingress_config.yamlSobald die Zone definiert ist, kann das Rate Limit über die Ingress-Ressource aktiviert werden:
annotations:
nginx.ingress.kubernetes.io/configuration-snippet: |
limit_req zone=megatoll nodelay;