Beiträge von whoami0501

  • Das längste Thema

    Zitat von ___

    @whoami0501 Wo ist pve-dedi-2?

    Ich wusste, dass diese Frage kommt. ^^


    Die Antwort ist, dass der jetzige pve-dedi-3 vorher pve-dedi-2 war. Die Hardware von pve-dedi-3 war ein Bastelhaufen aus primär Desktop Hardware, welcher vor kurzem ausrangiert wurde. Die Platten sind in pve-dedi-2 umgezogen und laufen mit dessen Hardware weiter. Im Grunde war es einfacher, schnell neue Klebelabels anzubringen, als überall alle Hostnames und DNS Einträge usw. zu ändern. :P

  • Das längste Thema

    Also ich habe es geschafft, das ganze ohne Smoothie Kühlung durchzuführen. :D


    Der Smoothie ist super und ist auch stilecht im netcup Glas angerichtet, aber ich muss echt noch an der Konsistenz der Sache arbeiten. Da bleibt ohne Spaß der Löffel drin stehen, zum Trinken ist diese Viskosität etwas suboptimal. ^^


    Zitat von Ecki

    bei den Strompreisen wird es sowieso zeit die 3,5 Zoll Platten zu ersetzen

    Da sind nur 2x3TB WD Red Pro drin. Und irgendeine stock 12TB WD Platte für Backups... ich glaube wenn ich die wegen Stromverbrauch o.Ä. ersetze braucht es ein dutzend Jahre, eh es sich armortisiert hat. Zudem ich hier, glücklicherweise, noch auf normalen Strompreisniveau bin. (*Schweiß von der Stirn wisch* - mal sehen wie lange noch...)

  • Das längste Thema

    Zitat von aRaphael

    Der Standort eines UFOs ist ja auch schwer festzulegen. ;)

    Noch 3 packets per second mehr und wir fliiiiegeeeen! ^^


    Spaß - "Hochgeschwindigkeitsserver" im wahrsten Sinne des Wortes gibts woanders, das ist dann auch nichts mehr für "Normalsterbliche" :P

  • Das längste Thema

    Zitat von hoedlmoser

    warum ich den rotierenden rost vom großen H so hasse? hat doch glatt mein vorbenutzer der festplatte keinen write cache aktiv gehabt.


    diskstats_latency-day.png

    Vermutlich aus dem einfachen Grund, dass er bei nem Powerloss keinen Datenverlust riskieren wollte. Gerade bei Backup oder Archivsystemen ist das durchaus legitim, wenn Integrität wichtiger als I/O ist.

  • Das längste Thema

    Zitat von mainziman

    whoami0501 kannst Du api.telegram.org bzw. core.telegram.org IPv6-pingen?

    Ja, kann ich auch. Unabhängig vom Status der Mangle Regel. Das ist ziemlich merkwürdig.


    EDIT:

    Zitat von frank_m

    Jedenfalls sind die MSS Probleme häufig auf zu strenge ICMPv6 Einschränkungen zurückzuführen. Kommt besonders gern an PPPOE Anschlüssen vor, liegt aber eher am Server.

    Telekom Business VDSL über PPPoE - richtig vermutet.

  • Bastel- und Bau-Ecke

    Zitat von [netcup] Claudia M.

    Hallo zusammen! :)

    Es gibt nun ein eigenes Subforum "Hardware" in dem ihr euren Projekten eigene Themen widmen könnt.

    Auch Fragen/Themen rund um dedizierte Hardware können dort erstellt werden.

    Bisschen verspätet - aber wäre es nicht sinnvoll, diesen Thread dort hinzuschieben? :)


    Abgesehen davon - wäre es im besagten Unterforum evtl. sinnvoll, eine Tauschbörse für Hardware anzulegen? Ich meine man hat ab und an auch mal Hardware, für die man auf gängigen Plattformen wie ebay Kleinanzeigen einfach keine Zielgruppe findet weil es einfach zu spezifisch/ zu nerdig ist. Da findet man halt in so einem Forum eher Abnehmer dafür. ^^

  • Das längste Thema

    Erinnert ihr euch an das IPv6 Problem mit dem Netcup Forum (seit dem Update), wo glaube mainziman die change MSS Lösung geliefert hatte?


    Ich habe seit heute oder evtl. auch die Tage genau das selbe Problem mit core.telegram.org und api.telegram.org - ich habe exakt die selbe Regel in meinem Router für die IPv6 des Telegram Servers gesetzt und alles geht wieder... weird. :/


    Code
    [admin@corerouter-01] /ipv6/firewall/mangle> export
# jun/18/2022 15:59:56 by RouterOS 7.3.1
# software id = xxxx-xxxx
#
# model = CCR2004-16G-2S+
# serial number = xxxxxxxxxxxxxxxxxxx
/ipv6 firewall mangle
add action=change-mss chain=forward comment="fix for problems with netcup forum" dst-address=2a03:4000:35:8e2::95/128 in-interface=all-vlan new-mss=1432 out-interface-list=WAN passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1433-1536
add action=change-mss chain=forward comment="fix for problems with telegram" dst-address=2001:67c:4e8:f004::9/128 in-interface=all-vlan new-mss=1432 out-interface-list=WAN passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1433-1536
[admin@corerouter-01] /ipv6/firewall/mangle>

  • 127.0.0.53:53

    Zitat von frank_m

    Das SCP kommuniziert mit dem KVM Backend auf dem physikalischen Server. Es hat keinen direkten Zugriff in "deine" VM.

    Um das noch etwas zu ergänzen...


    Es gibt einerseits für klassische Einschalten/Ausschalten/Neustart Aktionen ACPI Events. Der Hypervisor im Backend ist in der Lage, diese an die virtuelle Maschine zu senden - das ist gleichzusetzen mit der Power-Taste an einem normalen Computer. Der acpid Dienst auf deinem Server nimmt diese Events an und wertet sie aus. (Weiterführende Infos)


    Die Bildschirmübertragung erfolgt gelinde gesagt über eine virtuelle Grafikkarte, dessen Ausgabe der Hypervisor einfach abgreift, umsetzt und dir per VNC im SCP verfügbar macht.


    Die Informationen über die Festplatte des Servers kommen ins SCP, weil der Hypervisor die virtuelle Festplatte deines Servers anschauen kann und bspw. auslesen kann, wie viele Blöcke bei welcher Blockgröße benutzt werden (daraus resultiert die aktuelle Benutzung der Festplatte). Das ist aber oftmals ungenau und kann dementsprechend abweichen. Meist, aber nicht immer, kann man das mit einem fstrim -a auf dem Gastsystem auskorrigieren.


    Ferner gibt es (optional) noch den Dienst qemu-guest-agent.service auf deinem Server, welcher über eine virtuelle serielle Schnittstelle eine Verbindung zwischen Hypervisor und deinem virtuellen Server herstellt. Diese Verbindung kann z.B. genutzt werden, um den Server bei einem Online Snapshot kurzzeitig einzufrieren und so einen konsistenten Snapshot zu gewährleisten. (QEMU Wiki)

  • Lokal (von Python Script) generierten Traffic über mehrere (zusätzliche) IPv4-Adressen schicken

    Zitat von Mardos

    Natürlich würde es auch gehen einfach mehrere Server zu verwenden, aber dies würde mein Budget sprengen, da ich einen RS8000 G9 verwende und eine zusätzliche IP nur 1-2€/Monat anstatt ~40€/Monat (Angebot). - Speziell, wenn ich 2-4 Server benötigen würde ^^

    Warum gehst du dem API Owner nicht mal auf den Keks, dass er IPv6 deployen soll? Da hättest du 2^64 Adressen zur Verfügung. Ganz ohne Aufpreis.

  • Proxmox - rpool von RAIDZ1 auf RAID10 umstellen

    Also: Vorher ein Backup machen und vorsichtig sein ist zu empfehlen. Nur weil das bei mir geklappt hat, muss es nicht woanders klappen.


    Ausgangssituation: Proxmox Server mit 3x 240GB Intel SSD im RAIDZ1 als rpool. Auf dem rpool liegen das OS und die VMs. Der Server nutzt eine legacy BIOS Installation mit Grub. Alles andere lassen wir außen vor, das ist insoweit unwichtig. Wichtig ist lediglich, dass noch zwei 240GB Seagate SSDs da sind und wie oben bereits erwähnt, diese zusammen mit zwei der Intel SSDs ein RAID10 bilden sollen (zwei Mirror und darüber stripen).


    Ganz theoretisch könnten die VMs durchgehend laufen, aber ich habe sie der Vorsicht halber vorher heruntergefahren und den Autostart deaktiviert.


    1. Die Seagate SSDs werden parallel zu den Intel SSDs ans System angeschlossen
    2. Disk IDs herausfinden: ls -al /dev/disk/by-id/ata-*
      Wir gehen jetzt von ata-Intel_aaa, ata-Intel_bbb, ata-Intel_ccc, ata-Seagate_ddd und ata-Seagate_eee aus.
    3. Das Partitionsschema von einer der RAIDZ1 SSDs anzeigen lassen: gdisk -l /dev/disk/by-id/ata-Intel_aaa
    4. Mit gdisk auf beiden(!) Seagate SSDs das selbe Partitionsschema anlegen. Ihr werdet Probleme bei den Sektorgrößen bekommen - die Lösung ist, die automatische Sektorgröße von gdisk vor dem Anlegen der Partitionen auf 1 zu setzen:
      1. x
      2. l
      3. 1
      4. m
    5. Die neuen SSDs werden jetzt mit dem Bootloader bestückt:
      1. proxmox-boot-tool format /dev/disk/by-id/ata-Seagate_ddd-part2
      2. proxmox-boot-tool format /dev/disk/by-id/ata-Seagate_eee-part2
      3. proxmox-boot-tool init /dev/disk/by-id/ata-Seagate_ddd-part2
      4. proxmox-boot-tool init /dev/disk/by-id/ata-Seagate_eee-part2
      5. proxmox-boot-tool status
    6. Der neue zpool wird nun als einfaches RAID0 namens syspool angelegt. Wie perryflynn bereits erwähnte - passt auf, dass der ashift Wert bei euch stimmt oder passt ihn ggf. an:
      1. zpool create -o ashift=12 -O compression=off -O xattr=sa -O acltype=posixacl syspool /dev/disk/by-id/ata-Seagate_ddd-part3 /dev/disk/by-id/ata-Seagate_eee-part3
      2. zpool status
    7. In folgenden Configs muss das Wörtchen rpool gegen syspool getauscht werden:
      1. /etc/kernel/cmdline
      2. /etc/default/grub.d/zfs.cfg
    8. Den neuen syspool dem Cachefile hinzufügen:
      1. zpool set cachefile=/etc/zfs/zpool.cache syspool
    9. Das automatische mounten des Root Filesystem vom alten rpool ausschalten (sonst hat man beim Reboot race conditions, doppelte Mounts und alles was keinen Spaß macht):
      1. zfs set canmount=noauto rpool/ROOT/pve-1
    10. Nochmal das initramfs und den Bootloader neu schreiben lassen:
      1. update-initramfs -u -k all
      2. proxmox-boot-tool refresh
    11. Snapshot des alten Root Filesystem machen und an den neuen syspool senden, danach kurz nochmal schauen ob alles sauber geklappt hat, Bootloader nochmal sicherheitshalber neu schreiben lassen und rebooten
      1. zfs snapshot -r rpool/ROOT@migrate
      2. zfs send -Rwv --props rpool/ROOT@migrate | zfs recv -Fusd syspool
      3. zfs list
      4. proxmox-boot-tool refresh
      5. proxmox-boot-tool status
      6. reboot
    12. Das System sollte jetzt einmal sauber durchbooten und auf dem neuen syspool laufen. Ab jetzt ist die Redundanz erstmal temporär weg.
    13. Sicherheitshalber wird der Mountpoint des alten Root FS woanders hingebogen, um bei einem versehentlichen Mount o.g. Probleme vorzubeugen.
      1. zfs set mountpoint=/oldroot rpool/ROOT/pve-1
    14. Nun müssen die VMs alle auf den neuen syspool migriert werden. Legt euch dafür ggf. wieder eure Datasets an und pflegt diese in der /etc/pve/storage.cfg ein. Die Migration erfolgt normal über die Weboberfläche (Disk-Aktion -> Speicher verschieben) oder die Konsole.
    15. Noch einmal prüfen, ob alle Datasets vom alten rpool runter sind und diesen, wenn alles gut ist, zerstören:
      1. zfs list
      2. zpool status
      3. zpool destroy rpool
      4. zpool status
    16. Nun wird das RAID0 zum RAID10 gemacht - den beiden Seagate SSDs geben wir einen Partner zum resilvern:
      1. zpool attach syspool ata-Seagate_ddd ata-Intel_aaa
      2. zpool status syspool
      3. zpool attach syspool ata-Seagate_eee ata-Intel_bbb
      4. zpool status syspool
      5. Der Resilverprozess läuft jetzt und dauert je nach SSD und Speicherbelegung etwas an. Wenn der Resilvervorgang abgeschlossen wurde, ist die Redundanz wieder da. Nun können auch die VMs ggf. wieder gestartet und der Autostart reaktiviert werden.
    17. Nun entfernen wir die dritte, nicht mehr benötigte Intel SSD aus dem System
      1. proxmox-boot-tool status
      2. gdisk /dev/disk/by-id/ata-Intel_ccc
        1. p
        2. o
        3. Y
        4. w
        5. Y
      3. proxmox-boot-tool clean --dry-run
      4. proxmox-boot-tool clean
      5. proxmox-boot-tool status
      6. proxmox-boot-tool refresh
      7. SSD ausbauen


    Uuuund geschafft. War ganz einfach. 8)

  • Proxmox - rpool von RAIDZ1 auf RAID10 umstellen

    Danke für den Input. Ich hatte zwischenzeitlich folgende Anleitung gefunden, nach der das tatsächlich alles online zu gehen scheint.


    Theoretisch gibt es für mich dadurch folgende Schritte:

    • Alle VMs auf HDD umziehen, sodass rpool/data leer ist, den Autostart aller VMs deaktivieren
    • Beide Seagate Nytro SSDs anschließen, darauf dann das selbe Partitionslayout wie auf den Intel SSDs erstellen
    • Die zweite Partition der Seagate SSDs mit dem proxmox-boot-tool bootbar machen (format und init)
    • Auf der dritten Partition einen neuen Pool erstellen, den ich syspool nenne (damit es nicht zu Namenskollisionen kommt) -> striped, zpool create -o ashift=12 /dev/disk/by-id/XXX /dev/disk/by-id/YYY
    • Snapshot erstellen: zfs snapshot -r rpool/ROOT@migrate
    • Alles rüber kopieren: zfs send -Rwv --props rpool/ROOT@migrate | zfs recv -Fusd syspool/ROOT
    • Cache file aktualisieren: zpool set cachefile=/etc/zfs/zpool.cache syspool
    • Den Boot-Pool in /etc/kernel/cmdline anpassen
    • proxmox-boot-tool refresh ausführen, damit die Anpassung geschrieben wird
    • System rebooten, das System sollte nun den neuen Pool nutzen
    • zpool destroy rpool und so wie oben partitionieren, sowie mittels zpool attach aus dem RAID 0 ein RAID 10 machen
    • Wenn das RAID resilvered ist, die VMs zurück ziehen und den Autostart reaktivieren
    • Dritte Intel SSD ausbauen


    Grundsätzlich sollte ich das ganze vermutlich auf jeden Fall mal testen, ja, das ist richtig und wichtig. Aber in der Theorie sollte die Vorgehensweise doch klappen, oder?

  • Proxmox - rpool von RAIDZ1 auf RAID10 umstellen

    Nabend in die Runde,

    ich mache dann mal den Anfang in diesem Forenbereich.


    Ich habe einen Server hier zuhause laufen - darauf läuft ein Proxmox mit einem rpool im RAIDZ1 (ZFS pendant zu RAID5) aus drei 240GB Intel DC SSDs. Dazu gibt es noch ein Mirror (RAID1) mit zwei HDDs, das ist aber im wesentlichen nur ein Datengrab.


    Der rpool soll nun auf ein RAID10 umgestellt werden. Das RAID10 soll am Ende aus zwei der Intel SSDs und zwei Seagate Nytro SSDs selbiger Größe bestehen. Letztere beiden sind vorhanden und ggf. auch noch zwei Seagate Nytro mit 480GB, die ich als "Puffer" nutzen könnte.


    Die VMs würde ich vom rpool in den o.g. Mirror aus HDDs verschieben und abschalten, sodass ich afaik nur das OS migrieren muss. Backups lege ich dann selbstverständlich an.


    So wie ich es am sinnvollsten erachte/verstehe, hätte ich dann zwei Päärchen aus Intel und Seagate SSD, über die ich dann stripe.


    Die Frage ist - wie mache ich das am elegantesten? Ich habe ein bisschen von send und receive Magie gelesen, aber so 100% sicher bin ich mir in der Sache noch nicht.

  • Putty, Iptables vs nftables

    Zitat von Samsonetty

    So ich hoffe hab ich alles Richtig gemacht, ipv6 Ausgeklammert, da es nicht Aktiv ist, bzw. keine IP Zugewiesen ist, nur ipv4

    Wenn du 2022 IPv6 deaktivierst, hast du tendenziell eher alles falsch gemacht. Also sorry, aber für sowas habe ich absolut gar kein Verständnis.


    Zitat von Samsonetty

    iifname $MAIN_INTERFACE tcp dport { 22,62698 }ip daddr $IPv4 accept

    Hier brauchst du, wenn dein SSH Server nicht auf Port 22 lauscht, Port 22 auch nicht aufzumachen.


    Zitat von Samsonetty

    PS: muss ich die dann noch Speichern? oder reicht der ssh restart?

    /etc/init.d/ssh restart

    Die Firewall hat nichts mit dem SSH Server zu tun. Die Regeln liest du wie gesagt mit einem nft -f /etc/nftables.conf neu ein. Ein SSH Server Neustart bewirkt in dem Falle nichts.


    Abgesehen davon der Hinweis, dass init.d in aller Regel nur noch legacy Support hat und Stand der Technik heutzutage systemd ist.

  • Putty, Iptables vs nftables

    Zitat von Samsonetty

    ich hab mich zwar gestern Belesen, aber keinen Schimmer was ich da machen muss

    Ich dachte eigentlich, dass sich das logisch erschließt... du kannst die Regeln ja beliebig kopieren in der Liste und dann halt den Port und ggf. das Protokoll ersetzen. Du kannst mehrere Ports in einer Regel zusammenfassen, indem du diese in geschweiften Klammern kommasepariert aufführst.


    Hier mal ein Beispiel für den ersten ARK Server - ich denke nach dem Schema bekommst du es auch hin: