Search results

Backups gehören überall hin aber NICHT auf local. Das sind standardmäßig schlaffe 100GB, die fürs Betriebsystem vorgesehen sind. Den 100GB Standardwert sollte man in meinen Augen eher auf 50GB reduzieren. Wundert mich, dass local immer noch als Backupziel standardmäßig aktiviert wird. Das ist...

Das ist doch ein Huhn/Ei Problem. Warum postfix das nur empfiehlt steht auf einem anderen Papyrus. Nur weil alte Männer mit langen Bärten sagen libsasl2 sei teuflisches, neumodisches Zeug, würde ich dennoch in meinem Produkt das inzwischen unausweichliche libsasl2-modules automatisch...

Erledigt und besser?

Warum muss ich auf neu installierten Geräten bis heute "apt install libsasl2-modules" ausführen um postfix ans Rennen zu bekommen? Das Ding ist nun alles andere als eine Extrawurst. Es nervt einfach nur! P.S.: Vorallem wenn postfix standardmäßig installiert ist.

Es gibt natürlich einen ganzen Sack an Tools. Allen gemein ist, dass der Ausfall von DNS/DHCP sie auch plättet. Da benutze ich lieber das von mir gepostete Script, welches auf x PVE-Hosts läuft. Im Desasterfall ist mir auch egal, ob es womöglich mehrere identische Piholes parallel startet...

Kenn ich nun nicht, werde es aber mal antesten. Die neun Scriptzeilen von mir, erzeugen aber minimalsten Overhead um die allerwichtigsten Dienste am Start zu halten. Heutzutage ist das WLAN natürlich auch extrem wichtig. Da bietet aber per Mesh schon ganz elegant Failover. Raucht dein Switch ab...

Genau das habe ich in einem Netz mit zwei PVE-hosts umgesetzt. Funktioniert wunderbar: #!/bin/bash # Pihole-Failover MAILTO="info@beispiel.de" while true; do sleep 10 RUNNING=`nmap -p 67 -sU pihole | grep open | wc -l ` if [ $RUNNING -lt 1 ]; then # echo "STARTE (LXC401) (pihole)...

Ich habe die Sache mal weiter untersucht. Ist wohl mein Lapsus Ich hatte tatsächlich mal xxd hinterherinstalliert um WOL-Pakete zu analysieren. Nach Neuinstallation des hosts fällt xxd natürlich nicht von alleine vom Himmel. Ein zurückkopiertes script braucht es aber fieserweise in einer...

Na ich habe da eher Debian in Verdacht. Hier habe ich es erwähnt, da es mir bei PVE aufgefallen ist. Tut ja nicht weh und hilft vielleicht irgendwem.

Naja, SW installiert ja immer seine Abhängigkeiten automatisch. mc lief unter der v8 ja schliesslich. Erst das Upgrade Trixie bei vorhandenem mc hat dieses komische Verhalten verursacht. Falls ich nochmal darüber stolpere werde ich mal ein apt -f install ausführen und notiere die Ausgabe.

Die scripte beinhalten nichts aussergewöhnliches. Passiert aber auch beim Versuch mit midnight commander Dateien zu kopieren.

Noch eine Frage, die mir schon lange durch den Kopf geht: Wie könnte ich mich im PVE-Universum benachrichtigen lassen, dass eine VM seit x-Minuten nicht erreichbar ist? Muss ich bei parallelen fettleibigen Monitoringlösungen verbleiben?

Mut zur Lücke wird doch manchmal belohnt, ich würde zuerst die repos kontrollieren und ggfs. bereinigen. Entweder per WebGUI oder shell am besten die non-subsciption aktivieren. danach apt update && apt upgrade dann pve8to9 ausführen. alle Vorschläge des scripts ausführen reboot Daumen drücken...

Nach erfolgreichem Upgrade beglückt mich die shell z.B beim Ausführen von scripten gerne mit: stdbuf: failed to run command ‘xxd’: No such file or directory Scheint etwas zu fehlen, denn apt install xxd ist möglich und scheint das Problem zu beseitigen. Komisch ist das aber schon. Was ist da los?

Bei einer 256GB SSD sind die standardmäßig vorgeschlagenen 100GB für root natürlich blödsinnig viel. Bei 1TB für 50€ relativiert sich das aber schon erheblich. Aber selbst wenn man es beim Standardwert belässt wundert mich, dass es keine integrierte "Notbremsaktion" bei volllaufemden root gibt...

Die LVM-Verwaltung von PVE ist strikt getrennt von irgendwelchen VMs. Das muss man wie die berühmten Matroschkas betrachten. Container sind tatsächlich andere Kinder. Änderungen des Hypervisors (PVE) schlagen auch in einer CT automatisch auf. Umgekehrt schlagen allerdings Änderungen in einem...

Verstehe ich nicht. Ich will doch eher: proxmox-network-interface-floating --activate. Warum, nennt die eine Kiste die Schnittstelle enp1s0 und die andere enp2s0?

In meiner Welt gehört CEPHfs auch strikt getrennt. Das ist eine Speicherlösung, die eine Vermischung mit Virtualisierungslösungen nicht verträgt. Nennt mich oldaged.

Noch ein Nachschlag: Bei der einen Kiste heißt das iface enp1s0 und bei der anderen enp2s0. Kann also nach Austausch nicht funktionieren. Beide haben übrigens jeweils nur ein Interface. Wer eine Idee der erratischen Namensvergabe hat, trete bitte vor.

Klingt nach Hausfrauenreparaturvorschlägen.