Recent content by bluesite

was sagt den mailq in der Konsole? vielleicht hängen ja noch alte Email in der queue?

ich musste am Router nichts einstellen bei mir. gib mal in die Konsole "tailscale status" ein siehst du da dann sowas wie hier? C:\Users\tail>tailscale status 100.64.0.2 dev5 tail windows - 100.64.0.1 vps tail linux idle; offers exit node 100.64.0.3...

hm also eigentlich sollte es zu finden sein root@pve ~# apt-cache search proxmox-default proxmox-default-headers - Default Proxmox Kernel Headers proxmox-default-kernel - Default Proxmox Kernel Image pve-headers - Default Proxmox Kernel Headers (transitional package) mach mal ein apt-get...

hm ich hab es auch in nem lxc Laufen aber ich nutze headscale als Control Server und da musste ich noch headscale routes enable -r 1 machen damit das Routing auch erlaubt ist, vielleicht muss er das noch bei Tailscale direkt machen da er ja deren Control Server nutzt. Ich hab den offiziellen...

als kleine Übersicht kann man ja sowas wie dozzle nehmen das ist schlank und recht übersichtlich

oder einfach in eine 2. VM rücksichern dann hast du die andere noch funktionsfähig

hm könnte natürlich auch sein also nen physischer Server, ich würde dann das Backup zurückspielen dann aber auf dem Proxmox nen Snapshot erstellen bevor die VM das erste mal gebootet wird nach dem zurückspielen so macht man nichts kaputt und kann testen bis man es hinbekommen hat.

wenn am anderen Standort auch ein PVE ist dann würde ich einfach ein Backup per vzdump machen und dieses am zweiten Standort wieder einspielen dann ist da ja alles drin inkl HDDs und Konfig

okay erstelle dir mal unter /etc/sysctl.d folgende Datei "99-tailscale.conf" falls die nicht schon vorhanden ist mit dem Inhalt: net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 und dann "sysctl -p" ausführen und schauen ob es dann geht Du hattest zwar geschrieben: " Das ip4...

du könntest dann in /etc/udev/rules.d eine Datei erstellen sonoff.rules mit folgendem Inhalt # Sonoff1 KERNEL=="hiddev*", ATTRS{manufacturer}=="manufacturer", ATTRS{serial}=="iSeriel ", OWNER="root", SYMLINK+="usb/sonoff1" # Sonoff2 KERNEL=="hiddev*", ATTRS{manufacturer}=="manufacturer"...

was sagt den lsusb -vvv zu deinem Device, haben die vielleicht unterschiedliche iSerial, ich hab z.B. drei USV die ich damit eindeutig zuweise bzw per udev bekomme die dann neue Name das ich weiß welche USV welches Gerät ist zum besser auslesen

containerd.io/trixie,now 1.7.29-1~debian.13~trixie amd64 [installiert] <- das hier hatte ich gestern installiert containerd.io/trixie 1.7.28-2~debian.13~trixie amd64 <- das hier war fehlerhaft und kam am 5.11. raus containerd.io/trixie 1.7.28-1~debian.13~trixie amd64 ich habe allerdings...

es gab doch schon ein Update des Pakets danach lief bei mir wieder alles ohne Probleme, ich brauch es im lxc da ich sonst meine Grafikkarte nicht nutzen kann im Kontainer und keine Slots frei habe um eine zweite Karte einbauen zu können. containerd.io/trixie,now 1.7.29-1~debian.13~trixie amd64...

ich hab 4 lxc mit docker am Laufen und zwei VM, bis her sogut wie keine Probleme gehabt damit, das mal ein Paket nen Problem verursacht kann ja immer mal passieren aber da kann man ja einfach nen rollback machen und auf nen fix warten, das seh ich nicht so kritisch, kommt halt immer drauf an auf...

das Problem lag am containerd.io es gab heute schon ein Update das den Fehler behoben hat siehe Thread