VibeOps

ich hab bisher alle #hermes_agent mit telegram angesprochen

1. problem web app telegram zeigt manchmal kein nachrichten an: This message is currently not supported on Telegram Web. Try getdesktop.telegram.org -> mobbing das ich die app installieren soll 🖕

2. problem: app hängt immer ma wieder in android - vllt zu große chats? trotzdem kacke

3. problem: datenschutz - warum sollen die daten über diesen dubiosen kanal laufen

4. problem: die chatbots können nicht einfach miteinander reden

Lösung: #Matrix #Synapse #Element auf meinem #linux vServer

Kurz und knapp =)

Telegram wird langsam unbequem — App läuft schlechter, Datenschutz ist mir wichtiger geworden. Also: weg von fremden Plattformen, hin zu self-hosted. Setze Matrix (Synapse) auf eigenem VServer auf, wechsle auf Element als Client. Künftig schreibe ich direkt mit meinen KI-Agenten — und die Agenten stimmen sich untereinander in geteilten Räumen ab. Volle Kontrolle über meine Daten, E2E-Verschlüsselung, eigene Infrastruktur. Less cloud, more sovereignty. 🖥️"

#gemma4 working hard

#hermesagent Experiment auf meinem #macstudio (unfreiwillig aber zurecht) beendet. Ich wollte den Agenten mit lokalen LLM (qwen3.6-35b-a3b) auf einer Ubuntu-VM aussetzen und mal schauen was passiert. Dank meinem Mac mit 128GB hab ich dafür die beste Spielwiese. Mit UTM VM erstellt - LM Studio für das LLM. Pro: Sehr schnell - unkompliziert Installation - Hermes macht guten Eindruck Probleme: Das LLM hat sich immer wieder in Loops verrannt - an dem Parameter rumspielen hat auch nix geändert - immer wieder wilde Arbeitsweisen - denke das lag aber an dem begrenzt Horizont des LLM Aber warum ich es beendet habe: In UTM hab ich nur eine VM gehabt - die hat sich irgendwann verdoppelt in dem Menü - und ich dachte wenn ich die eine lösche bei laufender Maschine kann ja nix schief gehen... Erste VM erfolgreich gelöscht - VM 2 runterfahren... Wollte den RAM anpassen - kam Fehlermeldung Datei nicht vorhanden 🤦 Nach kurzer analyse - ich hab die falsche VM gelöscht - dumm gelaufen #linux #llm #apple #gevibeopt

mal wieder ein use case par excellence für #hermes_agent unter linux: unter #windows wurden keine ordner angezeigt trotz gesetzter acls LÖSUNG FUSE default_permissions bricht POSIX ACLs — und niemand merkt's Setup: Ubuntu Fileserver, Samba/Winbind in AD-Domäne, Storage-Pool via mergerfs (FUSE). POSIX ACLs korrekt gesetzt — group:bs_alle:r-x auf /srv/storage/Mitarbeiter. User ist in bs_alle. Ext4 direkt: Zugriff klappt. Über mergerfs: Permission denied. Symptom: test -r sagt OK, ls sagt denied. Windows-ACLs korrekt, Samba-ACLs korrekt, ext4-ACLs korrekt. Nichts zu finden. Root cause: FUSE default_permissions wird vom Kernel-Modul geprüft — und der kennt nur owner/group/other, keine named POSIX ACLs. group:bs_alle:r-x wird ignoriert. group::--- (base group) greift → DENY. mergerfs setzt default_permissions implizit bei allow_other, ohne dass's in der fstab steht. Fix: mergerfs ≥ 2.41.0 hat default_permissions=false als Option (PR #1448). Damit macht mergerfs selbst ACL-aware Permission-Checks im Userspace (posix_acl=true). mergerfs 2.42.0 installiert, fstab angepasst, remount — 15 Sekunden Downtime. ACLs greifen, Security intakt. Lektion: FUSE default_permissions und POSIX ACLs sind inkompatibel. Wenn ihr FUSE-Mounts mit ACL-basierten Permissions habt — checkt das. #linux #sysadmin #fuse #posixacl #mergerfs #sambaFUSE

Bin über #cachet #uptimekuma #kener gestolpert Mit #hermesagent überflüssig, auch für große Setups durch extra Hermes Instanz machbar KI Agent: Haben gerade einen Uptime-Watchdog für unseren Server gebaut. Stupid simple, kein extra Container, keine Web-GUI, kein LLM. Ein Shell-Skript mit curl und nc checkt alle 5 Minuten 9 HTTPS-Endpoints und 2 TCP-Ports. Alles ok? Skript output ist leer = still, man merkt nichts. Service down? Alert landet direkt im Element-Chat. Läuft als Hermes cronjob mit no_agent=true. Heißt: keine Tokens, kein LLM, kein overhead. Pure Shell die nur bei Problemen laut wird. Das Pattern: leere stdout = still, nicht-leere stdout = wird zugestellt, non-zero exit = Fehler-Alert. Genau so sollte Monitoring sein. Warum nicht Uptime Kuma? Weil es für einen Single-Admin mit 11 Services overkill ist. Zweite App die man updaten muss, zweite Instanz die selbst down gehen kann. Ein 50-Zeilen Shell-Skript erfüllt denselben Zweck. #vibeops #vserver #linux #sysadmin

@tux@burningboard.net Daumen sind gedrückt