sysadmin
Follow from the Fediverse
Follow #sysadmin from Mastodon or any other Fediverse app and its public posts arrive in your timeline. No vutuv account needed.
@sysadmin@tags.vutuv.de
Also known as
Sys Admin
The most endorsed users with this tag
-
Kai Schmidt Information Technology
-
Fabian Wagner CEO @ Fabian Wagner IT Service
-
Paul Poljakovic Application Support
Posts with this tag
11 posts
Filters
I got a call from someone I don’t know.
“Hi. We have a FreeBSD server. It’s been working perfectly for years, but it hasn’t been updated since then. We asked AI to update it, but now it won’t boot anymore. It didn’t even make a backup before starting. The AI keeps trying things, everything is down, and we’ve already spent over €500 in tokens. Can you help us?”
“Sure. €500, plus the time it’ll take me to try to fix it. Assuming it can still be fixed and nothing important has been deleted.”
“That much?”
Some silence.
“Well, I hope AI takes your job away!” And he hung up.
Believing that autopilot automatically makes you an invulnerable professional pilot will ruin far more people than job losses will.
I don’t know if AI will take my job away, but it’s already cost them €500 and, probably, their server.
The AI agents escaped the sandbox again.
Meanwhile, their owners: 👇
Hostwarden 1.0.0 is out.
It lets an AI coding agent (Claude Code, Codex, OpenCode, Cursor) look after your Linux, FreeBSD and macOS machines over SSH. In Claude Code, a hook blocks disk wipes, partition table writes and sshd config changes, however convinced the agent is that it needs one.
Hostwarden started as a fork of Heinzel by @wintermeyer and branched off at 2.22.0.
ADMIN Update Feature Article: Andrea Ciarrocchi takes a deep dive into two powerful tools for tracing network paths and troubleshooting connectivity issues: Test-NetConnection and mtr
Are you the Systems Administrator we need? Apply for the post of Software Infrastructure and Continuous Delivery Engineer at KDE:
Check out the requirements here:
–
Keep KDE funded💲! Become a Supporter! Adopt an App! All at once!:
Ein Kollege hat eben eine Challenge in den Firmen-Chat gepostet die zu gut ist um sie nicht zu teilen:
Kommentiere was dein Job ist, aber lass es illegal/bedrohlich klingen.
Ich beschaffe Menschen, weise ihnen eine ID zu und deaktiviere sie wenn sie nicht mehr gebraucht werden. Danach lagere ich deren Reste, sofern etwas von ihnen übrig ist, im Keller. Aus Datenschutzgründen spricht darüber niemand.
Ich bin #sysadmin mit Personalverantwortung und unser #storage steht im Keller 😂
Replying to @doris@friendica-deutschland.de
Es geht dabei nicht nur um Friendica, sondern um eine grundsätzlichere Frage:
Wie muss föderierte Software aufgebaut sein, damit die Schwäche einer fremden
Instanz nicht unnötig die eigene Instanz belastet?
Man darf sich nicht darauf verlassen, das die anderen Mitspieler alles richtig machen. Das funktioniert weder im Straßenverkehr noch bei der Software-Entwicklung. Lieber aufs beste hoffen und trotzdem auf den Worst-Case vorbereitet sein.
From other networks 3
3 likes
@doris@friendica-deutschland.de liked this @hamiller_friendica@anonsys.net liked this @steffen@friendica-deutschland.de liked this
Already counted in the numbers above.
Föderierte Netzwerke funktionieren nur dann gut, wenn eine einzelne Instanz nicht nur
selbst stabil läuft, sondern auch mit schwächeren oder zeitweise gestörten Gegenstellen
umgehen kann.
Genau dieses Problem haben wir in den letzten Tagen auf unserer Friendica-Instanz sehr
intensiv untersucht. Dabei zeigte sich, dass langsame externe Verbindungen lokale PHP-
FPM-Prozesse über längere Zeit binden können, obwohl der eigene Server selbst gar
nicht überlastet ist.
@steffen@friendica-deutschland.de hat die Ergebnisse jetzt in einem Fachartikel zusammengefasst.
Es geht dabei nicht nur um Friendica, sondern um eine grundsätzlichere Frage:
Wie muss föderierte Software aufgebaut sein, damit die Schwäche einer fremden
Instanz nicht unnötig die eigene Instanz belastet?
Den Artikel findet ihr hier:
Föderation braucht Fehlertoleranz an den Instanzgrenzen
der-admin.de/admin-blog/…
In den vergangenen Tagen habe ich auf unserer Friendica-Instanz ein Lastproblem
genauer untersucht, das sich zunächst nur schwer greifen ließ.
Am Ende zeigte sich sehr deutlich: Nicht CPU, Datenbank oder Redis waren das eigentliche Problem, sondern vor allem synchrone externe HTTP-Aufrufe zu anderen
Instanzen. Langsame Gegenstellen konnten PHP-FPM-Prozesse über viele Sekunden
binden. Mit Slowlog, ss und strace ließ sich dieser Ablauf schließlich direkt nachweisen.
Aus dieser Untersuchung ist für mich eine grundsätzliche Frage entstanden:
Wie robust muss eine föderierte Instanz gegenüber langsamen, fehlerhaften oder
zeitweise unerreichbaren Gegenstellen sein?
Ich habe dazu einen ausführlichen Fachartikel auf der-admin.de geschrieben. Darin geht
es bewusst nicht um eine fertige Konfiguration zum Nachbauen, sondern um die zugrunde liegenden Zusammenhänge und die Frage, wie Föderation technisch belastbarer werden kann.
Föderation braucht Fehlertoleranz an den Instanzgrenzen
Der #froscon Vortrag zu #curl von Christoph Stoettner ist sehr interessant! Ich wusste nicht, dass das Ding sooo viel kann. (Ich bin eine von denen, die bisher telnet nachinstalliert haben. 😄)