Beiträge von terence

    Ich fände es gut, wenn man mit http://login.eoscloud.io/ direkt die Login-Seite aufrufen könnte. Aktuell kommt da "Hier entsteht eine neue Webseite".
    Man kann sich zwar den Link zur Login-Seite als Favorit abspeichern, aber eine dedizierte Subdomain fände ich besser, weil ein Pfad erfahrungsgemäß eher mal geändert wird als eine Subdomain.

    Oder man ermöglicht es, sich auf console.eoscloud.io direkt einzuloggen.

    Bei der zweiten oder dritten VM geht das Menü auch mal nach oben auf, so daß dann nur die unteren Einträge verwendet werden können. :D

    Daher verwende ich bisher immer nur das Menü auf der VM-Detailseite.

    Aber das werden die Entwickler schon hinkriegen, so daß es auch auf kleineren Bildschirmen bedienbar sein wird. Ein Scrollbar und/oder Navigierbarkeit per Pfeiltasten könnte dabei ggf. auch helfen.

    Es wäre toll, wenn man in der Web-UI die Möglichkeit hätte, Terraform-Dateien zu erstellen um die zuvor manuell erstellten Ressourcen fortan mit Terraform verwalten zu können. Ich habe festgestellt, daß das wesentlich einfacher ist. :D

    Aber das steht vermutlich sowieso schon auf der Liste, oder?

    Ich habe das Terraform-Beispiel in der Doku ausgeführt.
    Nun versuche ich, die Source-Adressen der ACL "allow_ssh" zu entfernen.

    Wenn ich sources = [] setze, erhalte ich folgende Ausgabe:


    Wenn ich sources = [null] setze, erhalte ich folgende Ausgabe:


    Mit sources = [""] und sources = ["any"] kommt der Fehler "'Invalid IP format".

    Ich mache meine ersten Gehversuche mit Terraform/OpenTofu und habe es mit einem Dual-Stack-Debian12-VPS auch hinbekommen, das Beispiel aus der Dokumentation auszuführen. :)

    Dabei habe ich client_id und client_secret direkt in main.tf eingetragen, weil ich es noch nicht geschafft habe, die Werte per Umgebungsvariable zu übergeben.
    Wie ist die genaue Syntax dafür?

    Die folgenden Varianten haben nicht funktioniert:

    Code
    provider "eoscloud" {
      client_id     = "<EOS_CLIENT_ID>"
      client_secret = "<EOS_CLIENT_SECRET>"
    }
    Code
    provider "eoscloud" {
      client_id     = "EOS_CLIENT_ID"
      client_secret = "EOS_CLIENT_SECRET"
    }
    Code
    provider "eoscloud" {
      client_id     = EOS_CLIENT_ID
      client_secret = EOS_CLIENT_SECRET
    }


    In der Doku steht es so, weshalb ich annehmen würde, daß obige Variante 2 die richtige sein sollte.

    Code
    provider "eoscloud" {
      client_id     = "<CLIENT-ID>"     # or EOS_CLIENT_ID
      client_secret = "<CLIENT-SECRET>" # or EOS_CLIENT_SECRET
    }

    Die Umgebungsvariablen habe ich mit export EOS_CLIENT_*=XXX gesetzt und bekomme die Werte auch mit echo angezeigt.
    Für die ersten beiden Varianten erhalte ich die Fehlermeldung resolving realm from token: oauth2: "invalid_client" "Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method)." Für die dritte Variante kommt ein anderer Fehler.

    Was mache ich falsch?

    Ich habe in der Doku nicht gefunden, auf welchen Bestriebssystemen der Terraform-Provider läuft.
    Könntet Ihr das noch ergänzen und hier vorab schon einmal schreiben?

    Ich würde mir Unterstützung für OpenBSD wünschen. Da habe ich gerade eine Fehlermeldung bekommen.

    Ist geplant, den Source-Code zu veröffentlichen, so daß man sich den Provider ggf. selber kompilieren könnte?

    Wäre es möglich, die ACLs um die Richtung zu erweitern, so daß man auch ausgehende Verbindungen beschränken kann, wie es bei der SCP-Firewall der Fall ist?
    Ich würde gerne verhindern, daß eine kompromittierte VM nach Hause telefonieren, Spam verschicken oder andere Rechner angreifen kann.

    Macht es evtl. Sinn, die VM-Images mit einer Versionsnummer oder einer sonstigen eindeutigen Kennung zu versehen (z. B. Zeitstempel)?
    So könnte man im nachhinein besser nachvollziehen, mit welchem Stand eine VM erzeugt wurden und könnte z. B. erkennen, daß zwei VMs mit demselben OS durch unterschiedliche Images erzeugt wurden.
    Ich habe gerade zwei Alpine-VMs, die sich unterschiedlich verhalten. Da weiß ich, daß ich die zweite mit dem neuen Image erstellt habe, aber später wird das ja nicht mehr so sein - es sei denn, es wird ein Change-Log für die Images veröffentlicht, was natürlich auch gut wäre (zusätzlich).