Ein weiters Pseudonym von puff-daddy?
Genau so. Nein, Spaß. Das ist die hochkreative Abkürzung für Proxmox Virtualization Environment on dedicated Hardware Nr. X
Ein weiters Pseudonym von puff-daddy?
Genau so. Nein, Spaß. Das ist die hochkreative Abkürzung für Proxmox Virtualization Environment on dedicated Hardware Nr. X
@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.
Also ich habe es geschafft, das ganze ohne Smoothie Kühlung durchzuführen.
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.
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...)
Danke nochmal für den Smoothie Maker, Netcup
Hoffentlich ist er dann heute Abend aufgeladen, dann werde ich ihn direkt mal ausprobieren.
Aber logisch!
Aus dem grün-gelben Leiter kommt der klimaneutrale Strom.
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"
warum ich den rotierenden rost vom großen H so hasse? hat doch glatt mein vorbenutzer der festplatte keinen write cache aktiv gehabt.
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.
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:
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.
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.
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.
[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>
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)
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.
Dank dem neuen UEFI-boot von netcup
Habe ich was verpasst?
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.
Uuuund geschafft. War ganz einfach.
Ich habe es geschafft, mit ein bisschen Testerei in einer VM vorher hat es dann problemlos geklappt und das RAID10 läuft wie ein Traum.
Ich schreibe dann später noch etwas zum "Wie"
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:
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?
Wie viel hast Du denn am Host an PVE vorbei geändert? Wäre es eventuell eine Option für Dich, Proxmox einfach neu zu installieren und danach ein Backup der Konfiguration einzuspielen?
Das ist schon ein bisschen was - eigentlich wollte ich genau das vermeiden.
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.
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.
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.
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.
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:
#!/usr/sbin/nft -f
# drop all rules
flush ruleset
# config
MAIN_INTERFACE = "ens3"
IPv4 = "1.2.3.4"
IPv6 = "2000:beef:beef:beef::1"
# define new rules
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# accept any localhost traffic
iifname lo accept
# accept traffic originated from us
ct state established,related accept
# drop invalid packets
ct state invalid drop
# http and https
iifname $MAIN_INTERFACE tcp dport { 80, 443 } ip daddr $IPv4 accept
iifname $MAIN_INTERFACE tcp dport { 80, 443 } ip6 daddr $IPv6 accept
# ssh
iifname $MAIN_INTERFACE tcp dport 22 ip daddr $IPv4 accept
iifname $MAIN_INTERFACE tcp dport 22 ip6 daddr $IPv6 accept
# Server ARK Cluster 1 ark1
iifname $MAIN_INTERFACE tcp dport { 27016, 7778, 32330 } ip daddr $IPv4 accept
iifname $MAIN_INTERFACE tcp dport { 27016, 7778, 32330 } ip6 daddr $IPv6 accept
iifname $MAIN_INTERFACE udp dport { 27016, 7778 } ip daddr $IPv4 accept
iifname $MAIN_INTERFACE udp dport { 27016, 7778 } ip6 daddr $IPv6 accept
# Allow ICMPv4: Ping requests | Error messages | Router selection messages
ip protocol icmp icmp type { echo-request, echo-reply, destination-unreachable, time-exceeded, parameter-problem, router-solicitation, router-advertisement } limit rate 4/second accept
# Allow ICMPv6 traffic (https://tools.ietf.org/html/rfc4890#page-18)
ip6 nexthdr icmpv6 icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, echo-request, parameter-problem, echo-reply, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert } limit rate 4/second accept
# Allow IGMP
ip protocol igmp limit rate 4/second accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
# drop invalid packets
ct state invalid drop
# reject outgoing SSH/SMTP/SMB/RDP connections
oifname $MAIN_INTERFACE tcp dport { 22, 25, 445, 3389 } reject
}
}
Alles anzeigen