Vielen Dank für das Feedback und die Hinweise.
Da sich die Funktion aktuell noch in der Preview-Phase befindet, können und werden sich sowohl die verwendeten Bezeichnungen als auch die Gestaltung und das Design voraussichtlich noch verändern.
Das Feedback haben wir entsprechend aufgenommen und werden es bei der weiteren Entwicklung berücksichtigen.
Viele Grüße,
Thorsten
Vielen Dank für den Hinweis.
Wir werden die Dokumentation entsprechend anpassen.
Viele Grüße,
Thorsten
Hallo!
Vielen Dank für das Feedback und den konkreten Vorschlag.
Wir haben den Wunsch aufgenommen und werden prüfen, ob eine solche Möglichkeit in einer zukünftigen Version berücksichtigt werden kann. Insbesondere die Zuordnung von ACLs und Volumes auch von der jeweiligen Ressourcen-Seite aus sowie optional direkt im Erstellungsdialog ist ein nachvollziehbarer Ansatz.
Eine konkrete Umsetzung bzw. einen Zeitplan können wir zum aktuellen Zeitpunkt allerdings noch nicht zusagen.
Vielen Dank für die Anregung und viele Grüße,
Thorsten
Hallo terence!
Der Thread-Ersteller sollte die Themen als erledigt markieren.
Viele Grüße,
Thorsten
Hallo ihr beiden!
Ich sehe das Abschalten von ICMP Echo Requests nicht unbedingt als notwendige Absicherung. Ein Ping zeigt lediglich, dass die IP erreichbar ist, sagt aber nichts darüber aus, welche Dienste oder Ports tatsächlich erreichbar sind.
Für die eigentliche Absicherung gibt es ACLs bzw. Firewall-Regeln, über die sich eingehender Traffic gezielt erlauben oder blockieren lässt. ICMP Echo zu deaktivieren erhöht daher primär die "Unsichtbarkeit", ersetzt aber keine Zugriffskontrolle.
Gerade im Betrieb kann eine standardmäßig "pingbare IP" auch für Monitoring und Fehlersuche hilfreich sein.
Viele Grüße,
Thorsten
Hallo!
Vielen Dank für die Rückmeldung und entschuldige bitte meine späte Antwort.
Die Tatsache, dass die Adressen fortlaufend vergeben werden, sehe ich ebenfalls nicht automatisch als Sicherheitsproblem. IPv6-Adressen sollten ohnehin nicht als Sicherheitsmechanismus betrachtet werden – ob eine Adresse ...::1234 oder ...:8f31:42ab lautet, darf für die Erreichbarkeit keine Rolle spielen. Dafür sind Firewalls und ACLs zuständig.
Auch der Füllgrad des IP-Pools relativiert das Argument der besseren Auffindbarkeit: Ist ein IP-Pool stark gefüllt, ist potentiell ein großer Teil der Adressen erreichbar – unabhängig davon, in welcher Reihenfolge sie vergeben wurden. Und bei einer sequentiellen Vergabe entstehen durch zurückgegebene IPs über die Zeit ohnehin Lücken.
Was den Fall betrifft, dass ein komplettes Präfix geblockt wird: Das ist sicherlich ein Punkt, den man berücksichtigen muss. Im Vollausbau wird es voraussichtlich mehrere Präfixe geben, wodurch sich die Verteilung weiter entzerren lässt. Bei einer solchen Blockierung wird man sich im konkreten Fall ohnehin darum kümmern müssen, die Ursache zu klären und eine Entblockung zu erreichen.
Viele Grüße,
Thorsten
Hallo terence,
danke für die ausführliche Erläuterung. Ich verstehe jetzt besser, worauf dein Use-Case abzielt.
Die von dir gewünschte Trennung zwischen VM-Name im SCP und Hostname innerhalb des Gastbetriebssystems ist nachvollziehbar. Wir haben uns bei den eos-VMs allerdings bewusst für einen etwas anderen Ansatz entschieden.
Unser Ziel ist es, die VM möglichst als kurzlebige, über Automatisierung vollständig reproduzierbare Ressource zu betrachten. Die eigentliche Identität und Konfiguration des Systems soll dabei über die entsprechenden Werkzeuge wie Terraform und Cloud-init bzw. das darauf aufbauende Configuration Management (z.B Ansible) definiert werden.
Daher möchten wir aktuell die bisherige Logik nicht einfach um eine zusätzliche, unabhängig veränderbare Bezeichnung ergänzen. Das würde aus unserer Sicht wieder stärker in Richtung des klassischen VPS-Modells gehen, von dem wir uns mit den eos-VMs gerade bewusst unterscheiden möchten.
Das bedeutet natürlich nicht, dass dein Anwendungsfall nicht sinnvoll ist. Er passt nur nicht zu dem Infrastrukturmodell, das wir mit eos verfolgen.
Vielen Dank trotzdem für das Feedback – genau solche Rückmeldungen helfen uns dabei, besser zu verstehen, wo die unterschiedlichen Erwartungen an das neue Modell liegen.
Viele Grüße,
Thorsten
Hallo!
Doku und UI werden noch entsprechend angepasst.
Viele Grüße,
Thorsten
Hallo!
Es ist nun möglich im Compute-UI auch VM-Namen (@vmname) als target bei Port-forwards anzugeben:
image.png
Viele Grüße,
Thorsten
Hallo!
Die Auswahl ist nun behoben und nimmt bereits vergebene public IPs aus dem Dropdown aus.
Viele Grüße,
Thorsten
Hallo und vielen Dank für eure Geduld!
Wir haben uns dein Issue noch einmal genauer angesehen. Leider konnten wir das beschriebene Verhalten weder reproduzieren noch andere Auffälligkeiten feststellen.
Da du die Umstellung von IPv4 auf IPv6 vornimmst, sollte zudem sichergestellt werden, dass dein Service entsprechend auch auf IPv6-Verbindungen lauscht.
Auf einem Linux-System kannst du dies beispielsweise mit folgendem Befehl überprüfen:
ss -lntp6Damit werden die TCP-Listener angezeigt, die auf IPv6-Verbindungen lauschen. Alternativ kannst du mit
ss -lntp | grep ':::'gezielt nach Services suchen, die auf IPv6-Adressen bzw. allen IPv6-Interfaces lauschen.
Wichtig ist dabei, dass dein Service nicht ausschließlich an eine IPv4-Adresse (z. B. 0.0.0.0) gebunden ist, sondern auch auf einer IPv6-Adresse bzw. auf :: lauscht.
Bitte um kurze Rückmeldung ob das Problem auf Service-Level war.
Viele Grüße
Thorsten
Hallo!
Wir haben die Open API Spezifikation angepasst. Nochmals vielen Dank fürs einmelden.
Viele Grüße,
Thorsten
Hallo,
vielen Dank für deine Rückmeldung und den wertvollen Vorschlag.
Wir werden deinen Hinweis bei der Weiterentwicklung und Verbesserung unseres Produkts berücksichtigen.
Viele Grüße
Thorsten
Hallo terence,
entschuldige bitte die mögliche Verwirrung durch das Changelog. Bei uns sind Service/API und UI getrennt voneinander zu betrachten.
Aktuell ist dieses Feature ausschließlich in Compute (API) verfügbar. In der Compute UI sowie in anderen Produkten wie eosctl, eoscloud-mcp und terraform-provider-eoscloud ist es derzeit noch nicht verfügbar.
Sobald das Feature auch dort verfügbar ist, wird es entsprechend in einem Changelog-Eintrag kommuniziert.
Viele Grüße
Thorsten
Hallo terence !
Der VM-Name ist aktuell bewusst fest mit dem Hostnamen gekoppelt. Hintergrund ist, dass wir dadurch gleichzeitig eine konsistente Namensauflösung innerhalb desselben Netzwerks ermöglichen können.
Den Hinweis bezüglich des neuen Arch-Images schauen wir uns ebenfalls an. Insbesondere prüfen wir, warum der VM-Name dort aktuell nicht wie erwartet als Hostname übernommen wird.
Die Rückmeldung zur Möglichkeit, VM-Name und Hostname künftig getrennt voneinander zu verwalten, nehmen wir aber gerne mit und prüfen, ob sich hier eine sinnvollere Lösung anbieten lässt.
Viele Grüße,
Thorsten
Hallo terence !
Vielen Dank für die Rückmeldung.
Leider können wir dein Verhalten mit den von uns bereitgestellten Images nicht nachvollziehen:
Wir haben jeweils eine Ubuntu 26.04 und Debian 13 und eine Alpine Edge VM mit abgeschaltetem incus-agent erfolgreich in der console via ACPI neu starten können. Alle VMs wurden korrekt rebooted.
Ich kann mir nur vorstellen, dass unter deinem OpenBSD-System die ACPI Events anders verarbeitet werden.
Viele Grüße,
Thorsten
Hallo hra42!
vielen Dank für deine Rückmeldung und das positive Feedback!
Unser Ziel war es, eine Plattform zu schaffen, mit der sich IT-Infrastrukturen schnell und möglichst automatisiert bereitstellen lassen. Deine Rückmeldung zeigt uns, dass wir damit auf dem richtigen Weg sind. Es freut uns sehr, dass du Spaß an unserer Plattform hast und deinen Use Case erfolgreich automatisieren konntest.
Natürlich arbeiten wir kontinuierlich an weiteren Features und Verbesserungen, um unsere neue Plattform noch attraktiver und für eine größere Anzahl an Nutzern interessant zu machen.
Viele Grüße
Thorsten
PS: Wir würden uns freuen, wenn du deinen Use-Case im Subforum "Dein Projekt mit netcup eos" genauer vorstellen würdest.
Hallo Ralf157 !
Vielen Dank für dein Feedback zur UX.
Wir nehmen deine Rückmeldung gerne auf und werden natürlich daran arbeiten, die User Experience auch zukünftig kontinuierlich zu verbessern.
Viele Grüße
Thorsten
Hallo zusammen,
vielen Dank für eure Rückmeldungen.
Wir werden uns das genauer ansehen und uns anschließend wieder bei euch melden.
Viele Grüße
Thorsten
Hallo zusammen!
Die Volume-Dokumentation (https://docs.eoscloud.io/products/volumes/userguide/) wurde entsprechend angepasst.
Viele Grüße,
Thorsten