Beiträge von gunnarh

Zitat von mainziman

hat jemand eine Idee, wie man diesen File

https://www.fidelityinternational.com/FILPS/Document…U1048684796.pdf

mit curl, mit wget od. irgendwie gescriptet downloaden kann?

Das ist hinter einer AKAMAI Scraping Protection.

Du musst Header mitschicken die vorgeben ein typischer Browser zu sein. Damit klappt es z.B.:

wget --header='sec-ch-ua-platform: "Windows"' --header='sec-ch-ua-mobile: ?0' --header='sec-ch-ua: "Not=A?Brand";v="99", "Microsoft Edge";v="151", "Chromium";v="151"' --header='Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7' --header='Accept-Encoding: gzip, deflate, br, zstd' --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 Edg/151.0.0.0" https://www.fidelityinternational.com/FILPS/Documents/de/current/mf.de.xx.LU1048684796.pdf

Da die EOS Cloud aktuell kein Container-Hosting unterstützt wird man sich seine Container wohl (zumindest vorläufig) auf eigenen VMs hosten (müssen).

Und ich denke es gibt Szenarien, die man - selbst wenn man es mit Containern löst - lieber selber hostet, als das auf eine fremd-gemanagte K3S zu deployen.

Was den Einwand von [netcup eos] Stephan P. betrifft, dass der SDN Stack dann den Next-Hop für das Routing kennen müsste betrifft: Da kann ich jetzt nicht ganz folgen.

Was macht es in Bezug auf die Routing Thematik für einen Unterschied, ob ich ein /56 oder ein /64 habe?
Das SDN muss in beiden Fällen den Next-Hop kennen, ob sich dahinter dann ein /56 oder ein /64 verbirgt macht ja keinen Unterschied?

Wenn ich als Kunde ein z.b. /56 hätte und mir das auf meiner VM dann selbst weiter in Subnetze aufteile, dann liegt diese "Routing Tabelle" welches Netz dann in welchem (Docker-/LXC)-Container genutzt wird und wie diese Subnetze untereinander kommunizieren ja vollständig in meiner Hand, auf meiner VM. Das SDN der EOS-Cloud kennt freilich nur das komplette /56 oder /64 und meine VM muss dafür Sorge tragen, dass IPv4 ARP-Requests bzw. IPv6 Neighbor Discoveries für meine Container innerhalb der virtuellen Layer2 Broadcast Domain auflösbar sind.

Es muss nicht zwingend eine KVM-Konsole sein, serielle Konsole nehme ich für Linux auch. Oder wenn es möglich ist ein bei mir lokal erstelltes qcow File selbst hochzuladen. Aber der universellste Weg ist nun mal das Einlegen eines ISO-Image zu ermöglichen und eine KVM Konsole anzubieten, dann sind auch "Bare-Metal-Restore-Lösungen" wie Boot von Veeam-Recover-ISO-Image problemlos möglich und alle Szenarien stehen offen.

Wie gesagt, wenn es eine KVM-Konsole gibt und man ein ISO-Image einlegen kann (wie bei den Netcup-Servern üblich) ist das ohnehin vollständig in der Hand des Kunden und bräuchte euch nicht zu kümmern.

Danke [netcup eos] Stefan L. für die Verbesserungen, mit KeePassXC funktioniert es nun.

Bitte auch noch PassKeys fixen, sodass man nicht um "Security Key" wählen zu können zuerst die E-Mail-Adresse eingeben muss. Und wie gesagt, TOTP einem Security Key nachzuschalten ist etwas overkill, bitte entfernen. TOTP nur für Passwort-Authentifizierung.

Kann ich auch bestätigen, testweise ein fd03::0/56 sowie ein fddd::0/48 angelegt ... VM erhält in beiden Fällen nur die fd80-Link-Local-IPv6-Adresse.

Ein fd04::0/64 hingegen funktioniert. Mir fällt jetzt kein UseCase ein, wo man nicht mit einem /64 auskäme, aber vielleicht gibts Leute die hier ein Subnetting für Container etc... gerne durchführen würden - also ganz abwegig ist die Idee was größeres als /64 zu nutzen vermutlich nicht.

Wird es zu eurem S3-kompatiblen Object-Storage noch ein Tiering (Hot/Cold) mit angepasstem Pricing geben?

Mir fehlt auch noch die Möglichkeit eines Backups hierzu, darum müsste man sich aktuell wohl gänzlich selbst kümmern?

Skulduggery eine Kapazitätsplanung kann immer nur den aktuellen Kenntnisstand berücksichtigen. Niemand kann hellsehen und zukünftiges Anwender-Nutzungs-Verhalten lässt sich nicht zwingend aus der Historie ableiten. Daher strebt man - wenn es denn sinnvoll machbar ist - nach höchstmöglicher Flexibilität, also jederzeit Kapazitäten ergänzen zu können, und diese ohne riskante Aktionen und Wartungsfenster (downtime) auch nutzen zu können.

Und die Cloud-Plattform bietet hierfür grundsätzlich beste Voraussetzungen.

Du kannst ein Filesystem nur vergrößern wenn das Volume oder Logical Volume auf dem es residiert freien Spreicher aufweist. LVM schafft diese Möglichkeit jederzeit Speicher hinzuzufügen, ganz ohne Downtime, Shutdown, reboot.

Gerne nehme ich zur Kenntnis, dass Du der Meinung bist LVM wäre "komplex". Meinem Empfinden nach ist das Gegenteil der Fall, es vereinfacht meine UseCases enorm.

Danke [netcup eos] Thorsten L. für die Rückfrage.

Ich installiere alle Systeme immer grundsätzlich unter Verwendung von LVM (Logical Volume Manager) mit Logical Volumes (LV), und zwar aus folgenden Gründen:

• Bei der Installation muss ich mir (noch) keine Gedanken über das Kapazitätsmanagement machen. Ich lege einfach alle benötigten LVs (z.b. root, var, var-log, home, ...) mit einer Best-Guess Initial-Größe (eher klein / sparsam) an, und kann diesen LVs später wenn sich diese füllen unkompliziert und im laufenden Betrieb ohne etwas herunterfahren oder aushängen zu müssen zusätzlichen Speicher zuweisen.
• Ich bin ein Freund davon Userdaten, Logs, System voneinander zu trennen, damit z.b. ein User der das System anfüllt nicht das System oder die Logfile-Haltung in Gefahr bringt. Das fällt mit LVs bei denen ich dann z.b. die User-Volumes dynamisch jederzeit vergrößern kann deutlich einfacher.
• Das Hinzufügen von weiterem Speicherplatz durch Ergänzen eines weiteren Storage-Device welches einfach als Physical Volumes zum LVM ergänzt werden ist ebenfalls ohne vorherige Kapazitätsplanung möglich. Ebenfalls ist ein Shrinking möglich.

Nun könntest du (vermutlich) meinen Argumenten entgegenhalten:

• Lege doch einfach zusätzliche Volumes über die EOS-Cloud an und füge diese der VM hinzu statt LVs zu verwenden => Das kann ich aktuell aber erst NACH der Installation durchführen und ist doch ziemlich aufwändig wenn ich /var oder /home dann auf anderen Volumes haben möchte. Jede Änderung bedeutet VM herunterfahren, EOS Storage Volume vergrößern, VM wieder hochfahren, Filesystem Resizen etc... - jeweils mit Downtime und "Gefahr" verbunden. Bei Nutzung von LVM wäre ein ein Befehlsaufruf im laufenden Betrieb und die Sache ist erledigt, keinerlei Gefahr, keine Downtime.
• Die EOS-Cloud erlaubt das Vergrößern von Storage Volumes ... ja, aber zumindest derzeit nur bis 100GB, und nur offline. Wenn ich z.B. 2TB Speicher haben möchte was mache ich dann? Mit LVM wäre mir das egal, ich lege einfach mehrere neue Storage Volumes an, füge diese der VM hinzu und binde diese ins LVM ein. Wie ich diese dann auf meine LVs verteile bleibt ganz mir überlassen und bedarf keiner Unterstützung durch die EOS-cloud mehr.

Danke [netcup eos] Thorsten L. ... fast perfekt.

Ein Reload dürfte da beim Edit noch fehlen, aktuell muss man nach dem [1] edit noch manuell [2] reloaden, damit die Description sichtbar wird bzw. sich ändert:

image.png

Gibt es bereits einen Ausblick wo ihr eos hosten werdet? Zu Beginn offenbar in Klagenfurt? Wie steht's mit Wien?

Danke. Bitte auch die aktuell unzweckmäßige PassKey Implementierung beheben (hatte ich hier in diesem Post) schon mit-erwähnt, dürfte glaube ich aber bisher nicht wahrgenommen worden sein.

Wenn man sich mit Passkey anmelden möchte muss man derzeit völlig unnötig am Login-Screen zuvor dennoch seine Email-Adresse angeben und wird nach erfolgter PassKey-Authentifizierung dennoch zur TOTP-Eingabe weitergeleitet. So macht Passkey-Nutzung aktuell keinen Sinn. Der "Login with Securitykey" Button gehört direkt auf den Login-Screen, und braucht keine E-Mail-Adress-Eingabe. Und da Passkeys phishing-resistent sind braucht es auch keine TOTP-MFA.

Ich möchte mich hier mit zwei weiteren Problemen der Login-Seite anschließen:

Nutzung mittels KeePassXC-Browser Extension zur Übergabe Username + Kennwort scheitert.

Grund: Zweiteiliges Login, zuerst muss man Username eingeben, dann auf der nächsten Seite erst das Kennwort. Und die Felder sind nicht geeignet getagged, sodass das KeepassXC-Browser-PlugIn diese als Username/Kennwort-Felder erkennen würde.

Adressen nicht "anpingen" zu können (ICMP zu filtern) ist kein über Security-by-obscurity hinausgehender Security-Gewinn, zerstört aber die Path-MTU-Ermittlung. Bitte daher keine ICMP-Filterung.

Und genau genommen werden die IP-Adressen auch nicht dem Interface der VM zugewiesen, sondern offenkundig ein NAT+DNAT auf die unverändert private IPv4+IPv6 Adresse der VM realisiert. Finde ich schade, denn das war bisher schon sehr fein bei den Netcup Maschinen, dass diese direkt die zugewiesen IP-Adressen auf den VM-Ethernet Interfaces nutzen konnten. Dieses NAT+DNAT einer Infrastruktur, die man nicht kennt und nicht unter Kontrolle hat, macht Fehlersuche nicht einfacher. Leider realisieren das mittlerweile alle Cloud Anbieter die ich bislang genutzt habe auch nur noch so.

Ich betreibe meine Maschinen immer mit LVM (Logical Volume Manager), weil dies das Hinzufügen von Storage sehr vereinfacht.

Ad-hoc sehe ich in EOS keine Möglicheit LVM zu nutzen. Zumindest das Ubuntu-Image ist ohne LVM vorbereitet, und in Ermangelung einer KVM-Konsole und in Ermangelung irgend ein ISO-Image zum Booten einzulegen sehe ich keine Möglichkeit die VM auf LVM zu migrieren.

Ideal wäre freilich wenn die Wünsche KVM-Konsole und Einlegen von ISO-Images für das Booten unterstützt wären, dann könnte sich jeder sein System so installieren wie es beliebt, und auch LVM wäre dann möglich. So handhabe ich es bei den Netcup-VMs derzeit.

Solange diese Features nicht zur Verfügung stehen wäre es aber eventuell ein Quick-Win ein Ubuntu 26.04 Minimal-Image das auf LVM basiert als Image zur Installation anzubieten.

Die EOS VMs scheinen ja KVM virtualisiert zu sein.

Die im WebUI von EOS angebotene "Console" ist aber offenkundig keine KVM Konsole. In eurer Doku finde ich die Erklärung, dass das eine "secure root shell connection" wäre. Nun gut, es scheint offenkundig eine mittels incus-agent umgesetzte Konsole zu sein.

Die läuft aber freilich erst und nur dann, wenn dieser "incus-agent" den ihr in die Images reinlegt auch läuft. Also keine Möglichkeit damit z.B. zu Rebooten und im Bootloader mal einen alternativen Kernel zu wählen, oder die VM zu reparieren wenn diese nicht mehr bootet etc...

Ich wünsche mir eine vollwertige KVM-Konsole wie sie die Netcup VMs bieten.

Ich habe das Szenario (Root-Volume von 10 auf 20 GB vergrößern) jetzt bei meiner neu angelegten myVM2 abermals versucht.

Problem tritt erneut auf, scheint also nachvollziehbar zu sein.

Betroffene VM: 019fdbad-95bc-76d6-9d23-089c9fcff4c8

Danke für die Antwort. Das hatte ich eurer Doku aber freilich bereits entnommen.

Aber wie ich schon sagte: Mir ist euer Konzept warum ihr das unbedingt genau so macht nicht klar. Es gibt genügend UseCases, wo diese Public-IP nicht nur unnötig ist und vermutlich auch unnötig Geld kostet, sondern wo man schlicht gar nicht möchte, dass so ein Netz einen gerouteten/genatteten Public-Internet-Übergang aufweist.

Und zudem ist eine Public-IPv4 eine knappe Ressource, warum man diese verschwenden will, obwohl der Kunde sie in vielen Szenarien weder braucht noch möchte erschließt sich mir nicht.

Ich rege daher an, die Public-IPs der Netze optional zu machen ... ist dann vermutlich also ein Feature-Request.

Das (nachträgliche) Hinzufügen eines PassKeys im EOS Cloud Account unter https://console.eoscloud.io/auth/settings/webauthn funktioniert nur, wenn man das als optional gekennzeichnete Feld "Security key name(optional)" befüllt. Wenn man dieses nicht befüllt erhält man lediglich ein weißes / Leeres Formular.

Außerdem scheint mit der Name etwas unüblich gewählt, unter WebAuthN findet man "security key" ... da denke ich intuitiv eher an einen Fido-Key oder ähnliches. Denke beides mit PassKey zu beschriften wäre intuitiver.

Weiter geht es dann mit der Login-Maske unter https://console.eoscloud.io/ ... warum muss ich dort meine E-Mail-Adresse eingeben bevor ich dann mittels PassKey authentifizieren kann? Das wäre ja gerade der Vorteil an PassKeys, dass ich da nicht wieder etwas eintippen muss sondern einfach mit dem PassKey bestätige.

Und wenn man dann schließlich sich mittels PassKey angemeldet hat kommt schließlich die TOTP Abfrage. Wofür? Die macht ja nur Sinn, wenn ich mich mit Username+Kennwort anmelde, aber einer Phishing-Resistenten PassKey-Abfrage nochmals TOTP hinten drann zu setzen ... bitte nein.