@03simon10 : Ich hatte mal einen Fall betreut, wo die Cloud erst eine Woche gestört war und dann alle Fotos der letzten Wochen weg waren. Die Antwort war: Danke für ihr Geld. Laut AGB dient die Cloud nicht als Backup.
Das perfide war, auf dem iPhone wurde ein Update gemacht und dort waren dann alle Ordner weg. Tipp hier war: Reset auf Werkseinstellungen.
Gibts schon Neuigkeiten bezüglich Boot per UEFI?
Speaking of Data Loss:
Gerade die falsche Platte mit dd angefasst. LVM geht wieder - aber das Root ext4 muss neu gemacht werden.
Hänge gerade in debootstrap.
Mal gucken...
Sorry kann dir also leider nicht weiterhelfen.
Naja, ist ja eigentlich eher positiv, wenn du sowas noch nicht hattest
die Moral von der Geschicht
Jaja... Die Sache mit der Bequemlichkeit, ne? Ich packe mir gerade n großes Archiv und verfrachte das auf meine HDD, zumindest hab ich dann mal den aktuellen Stand abgebildet. Was ich auf kurz oder lang daraus lerne, weiß ich allerdings...
Übrigens sind die Dateien nicht "einfach so" verschwunden, sondern durch ein Missgeschick gepaart mit unerwartetem Verhalten seitens der iCloud. Gestern - kurz bevor ich was gemerkt habe - habe ich den iCloud Ordner von der SSD auf die HDD geschoben, d.h. ne Verknüpfung erstellt. Jedenfalls hab ich in diesem Zuge einmal den gesamten iCloud Ordner, mitsamt aller Dateien, die bis dahin geladen waren (daher fehlt nicht alles), gelöscht. Alle Prozesse die irgendwas mit Apple oder der iCloud zutun haben, habe ich natürlich vorher gestoppt, daher hab ich mir da gar keine Gedanken drum gemacht... Tja, dann ist's irgendwie passiert.
Jedenfalls war ich froh, als ich im Papierkorb n großen Ordner "iCloudDrive" gefunden habe, soweit vermisse ich aktuell nichts mehr. Sicherheitshalber stellt Apple kommende Woche aber auch nochmal alle gelöschten Dateien wieder her, vielleicht ist ja irgendetwas hinten runtergefallen.
Gibts schon Neuigkeiten bezüglich Boot per UEFI?
Ich erhöhe um Neuigkeiten bzgl. Cloud-init-Unterstützung!
Ich erhöhe um Neuigkeiten bzgl. Cloud-init-Unterstützung!
Bevor jemand fragt - ich erhöhe auf gespoofte IP Pakete, die scheppern hier nach wie vor 24/7 rein. 
Gepriesen sei iptables. 
Sep 3 16:52:01 myserver kernel: [1110764.547621] Spoofed source IPIN=ens3 OUT=vmbr0 MAC=XX:XX:XX:XX:XX:XX:10:0e:7e:26:f1:c0:08:00 SRC=100.70.42.2 DST=172.21.1.101 LEN=52 TOS=0x00 PREC=0x00 TTL=109 ID=30754 DF PROTO=TCP SPT=64143 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=
der Eintrag ist seltsam ..., handelt es sich bei 172.21.1.101 um eine IP-Adresse welche tatsächlich zu einer der VMs gehört, die hinter dem Bridge-Interface vmbr0 laufen?
Ich erhöhe um Neuigkeiten bzgl. Cloud-init-Unterstützung!
Was ist eigentlich aus NAT-only und/oder IPv6-only RS/VMs geworden?
Was ist eigentlich aus NAT-only und/oder IPv6-only RS/VMs geworden?
ich denk die wären momentan unverkäuflich;
der Eintrag ist seltsam ..., handelt es sich bei 172.21.1.101 um eine IP-Adresse welche tatsächlich zu einer der VMs gehört, die hinter dem Bridge-Interface vmbr0 laufen?
Korrekt erkannt, das ist ein Proxmox Host mit Portforwarding an LXC Container - daher hier die interne IP des Reverse Proxy. (dport ist
Aber auch hier kann und darf die Quell IP nicht aus der CGNAT Range 100.64.0.0/10 stammen, wenn das Paket von außen rein kommt.
Die haben nur "Klaut"(im Sinne von Diebstahl) falsch geschrieben. Und die Moral von der Geschicht?
Hab ich immer schon gesagt: Die Cloud, die meine Daten klaut!
... CGNAT Range 100.64.0.0/10 ...
es gibt ja viele Krankheiten, aber des is Malaria, Cholera und Pest gleichzeitig ...
es gibt ja viele Krankheiten, aber des is Malaria, Cholera und Pest gleichzeitig ...
Mein ISP macht das auch. Schön alles nochmal durchs NAT und IPv6 wird sowieso überbewertet.
Vor allem,
welchen Sinn hat es dafür ein eigenen IP-Range zu reservieren?
vor allem steht des im Widerspruch zu einer regelmäßig Gebetsmühlenartig gepredigten Knappheit ...
wieso net einfach 10.0.0.0/8, weil den Kunden zeigst mir der dahinter nochmal ein 10.0.0.0/8 aufspannt 
wenn ich traceroute direkt auf meinem Router mach, dann ist interessanterweise das da das Ergebnis ...
traceroute to www.netcup.de (46.38.224.30), 30 hops max, 60 byte packets
1 192.168.X.X (192.168.X.X) 1.083 ms 1.129 ms 1.068 ms
2 172.18.224.1 (172.18.224.1) 10.405 ms 17.048 ms 16.945 ms
3 212.33.34.37 (212.33.34.37) 16.418 ms 16.385 ms 16.302 ms
4 ...Hop 2 ist wohlgemerkt außerhalb meines Einflußbereichs, sprich beim ISP
und Hop 1 hat WANseitig eine normale IPv4 Adresse
weil den Kunden zeigst mir der dahinter nochmal ein 10.0.0.0/8 aufspannt
Das ist nicht untypisch und hab ich selber schon im Betrieb gehabt. Also ein ganzes 10er /8 Firmenweit, damals war CGNAT noch kein Thema und sowas doppelt umzusetzen ist nicht toll.
Deshalb ist es sinnvoll einen eigenen Addressbereich dafür zu reservieren, genau so wie es für Dokumentation einen reservierten Bereicht gibt.
ich denk die wären momentan unverkäuflich;
Für Verbindungen zur Außenwelt vielleicht, aber übers interne Netz und über einen Jumphost oder VPN kommt man auch von außen drauf.
IPv6-only wär kein Problem für einen Datenbank- oder Backupserver für deine anderen VPS.
Vor allem,
welchen Sinn hat es dafür ein eigenen IP-Range zu reservieren?
vor allem steht des im Widerspruch zu einer regelmäßig Gebetsmühlenartig gepredigten Knappheit ...
wieso net einfach 10.0.0.0/8, weil den Kunden zeigst mir der dahinter nochmal ein 10.0.0.0/8 aufspannt
Die DSL-Router der Telekom Austria/A1 betreiben ihr LAN hinter dem Router schon ewig standardmäßig im 10.0.0.0/8-Bereich.
Das hättest grad du als Österreicher wissen müssen
Speaking of Data Loss:
Gerade die falsche Platte mit dd angefasst. LVM geht wieder - aber das Root ext4 muss neu gemacht werden.
Hänge gerade in debootstrap.
Mal gucken...
Läuft alles wieder. debootstrap und vorheriges /var auf einem anderen LV war nicht so eine geile Idee. Ein kompletter Reinstall aller Pakete über dpkg lief auch nicht wie geplant. Die frische Neuinstallation schuf Abhilfe.
Die DSL-Router der Telekom Austria/A1 betreiben ihr LAN hinter dem Router schon ewig standardmäßig im 10.0.0.0/8-Bereich.
Du sprichst hier einen Pfusch¹ an, den es schon mehr als ein Jahrzehnt nicht mehr gibt;
der Pfusch äußerte sich dahingehend, dass man lokal auf der Netzwerkkarte irgendwas bei 10.0.0.138 als IP Adresse hatte,
und des Teufelswerk irgendwas bei 10.0.0.140;
beim Einwählen hatte man wie bei einem VPN a eigenes Interface, über des dann tatsächlich kommuniziert wurde ...
dieser Pfusch ist Geschichte; 
Das hättest grad du als Österreicher wissen müssen
den Pfusch vergisst ma besser wieder;
Deshalb ist es sinnvoll einen eigenen Addressbereich dafür zu reservieren, genau so wie es für Dokumentation einen reservierten Bereicht gibt.
so lange man nicht im selben Atemzug von IPv4-Adressknappheit spricht ist das auch in Ordnung so;
Für Verbindungen zur Außenwelt vielleicht, ...
klar, das 'unverkäuflich' bezog sich auf eine (un)mögliche Preisgestaltung;
