Beiträge von Fabienne

Hallo zusammen,

die Steuerebene des Object Storage arbeitet einwandfrei — Buckets und S3-Nutzer entstehen in rund 1,5 Sekunden, Fehlermeldungen sind sauber. Der Datenpfad ist aber nicht erreichbar.

at-preview1.object-storage.eoscloud.io löst auf 159.195.164.7 auf. Portprüfung heute:

• 443: abgewiesen, TCP-RST nach 3 ms
• 8443: ebenfalls abgewiesen
• 80, 7480, 9000: Zeitüberschreitung, also gefiltert
• ICMP: keine Antwort

Der Host lebt also — er antwortet mit RST, statt die Pakete zu verwerfen —, aber auf 443 lauscht nichts. Zur Kontrolle: object-storage.eoscloud.io (159.195.164.38) antwortet auf 443 mit HTTP 401, ist also erreichbar.

Gegengeprüft aus zwei unabhängigen Richtungen:

• von meinem Arbeitsplatz aus
• aus einer laufenden eos-VM heraus, also innerhalb eurer Infrastruktur

Beide Male identisch: curl: (7) Failed to connect ... port 443 after 3 ms. boto3 meldet folgerichtig EndpointConnectionError.

Der Bucket selbst ist laut API bereit und nennt genau diesen Host als Endpunkt:

"status": "ready",
"url": "https://at-preview1.object-storage.eoscloud.io/<realm>_<district>:cbf-test-20260806a"

Damit ist derzeit kein Lesen und kein Schreiben über S3 möglich. Verfügbarkeitsübersicht, Known Issues und Changelog erwähnen nichts dazu, im Forum finde ich es auch nicht.

Zwei Kleinigkeiten, die beim selben Test nebenbei auffielen und vielleicht in die Dokumentation gehören:

1. Der ansprechbare S3-Bucketname ist nicht der angelegte Name, sondern <realm>_<district>:<name> — er steht im Feld url. Da Unterstrich und Doppelpunkt enthalten sind, ist Virtual-Host-Adressierung nicht möglich, Path-Style also Pflicht.
2. Ein delete direkt nach einem create scheitert mit bucketNotReady. Erst nach rund 1,5 Sekunden ist der Bucket ready. Das betrifft jedes Aufräumskript.

Hinweis: Ich teste eos weitgehend automatisiert und debugge gemeinsam mit Claude Code; daher die Messwerte oben. Und weil es hier schon anklingt — ich fasse mich bewusst knapp, das ist der Übersichtlichkeit geschuldet und nicht unhöflich gemeint.

Viele Grüße
Jonathan // Fabienne

Hi Bruno,

vielen Dank für die ausführlichen Antworten.

Ich habe meiner KI schon auf die Finger geschlagen, dass sie nicht so penibel sein soll und werde zukünftig nur noch klar erkennbare Bugs melden.
Feature Requests oder Anmerkungen zum Design etc werde ich über das entsprechende Board gesammelt einkippen.

Gruß Jonathan // Fabienne

Hallo zusammen,

drei Kleinigkeiten zu den Debian-Paketen eosctl 0.6.0 und eoscloud-mcp 0.7.0:

1. Widersprüchlicher Variablenname: eosctl --help nennt "Config file or EOSCTLCONFIG environment",
die Dokumentation spricht von EOSCTL_CONFIG. Das sind zwei verschiedene Namen, einer dürfte falsch
sein.

2. Keine Manpages: Weder eosctl noch eoscloud-mcp liefern Doku aus, nur Shell-Completions für
eosctl. Für CLI-Werkzeuge auf Debian ist eine Manpage die Erwartung.

3. eoscloud-mcp hat kein --help: Jeder Aufruf ohne gültige Anmeldung antwortet mit dem Hinweis auf
eos_login_start, auch --help selbst. Ein Hilfetext, der die unterstützten Umgebungsvariablen nennt,
würde die Einrichtung deutlich erleichtern.

Hinweis: Ich teste eos weitgehend automatisiert und debugge gemeinsam mit Claude Code; daher die
Messwerte oben. Und weil es hier schon anklingt – ich fasse mich bewusst knapp, das ist der
Übersichtlichkeit geschuldet und nicht unhöflich gemeint.

Viele Grüße
Jonathan // Fabienne

Hallo Bruno,

danke für die schnelle und klare Antwort – damit ist die Ursache geklärt.

Zwei technische Punkte aus dem Ausgangsbeitrag sind dabei offen geblieben, die unabhängig vom
Konzept bestehen bleiben:

1. Die Seite /auth/registration/accept zeigt ein vollständiges Registrierungsformular mit
Zustimmungen und Continue-Button an, obwohl die Registrierung auf diesem Weg nicht funktionieren
kann. Ein Hinweis wäre gut – noch besser wäre, den Invite-Code dort abzufragen oder direkt auf den
regulären Signup zu leiten.

2. Der 422 wird gar nicht angezeigt. Im DOM steht nach dem Fehlschlag kein role="alert" und kein
aria-invalid, sichtbar passiert nichts. Das war der Grund, warum ich überhaupt in den
Netzwerk-Mitschnitt geschaut habe.

Dazu eine Verständnisfrage: In den Known Issues steht:

Zitat

You can only create one Organization on your own, but you can be invited to other Organizations.
You have to create your own Organization BEFORE you get invited to another one.

Deine Antwort liest sich so, als sei die Reihenfolge egal. Gilt die Einschränkung aus den Known
Issues weiterhin, oder ist sie inzwischen entfallen? Ich frage, weil beides an derselben Stelle
unserer Notizen landet und ich es richtig festhalten möchte.

Mein Plan war ursprünglich, neben dem Admin-Account einen reinen Work-Account nach dem
Least-Privilege-Prinzip einzurichten. Da das hier aber ohnehin nur Sandbox und Nerdspielplatz ist,
lasse ich die Account-Trennung erst mal weg. Für die Automatisierung nehme ich stattdessen ein
Client Credential mit eingeschränkten Rollen – das deckt den eigentlichen Zweck ab.

Viele Grüße
Jonathan // Fabienne

Hallo zusammen,

zwei Punkte zur Oberfläche der Console.

1. Kein Dark-Theme

Meine Systemeinstellung steht auf Dark, die Console bleibt hell. Nachgemessen: prefers-color-scheme
dark wird vom Browser korrekt gemeldet, aber von den rund 6800 CSS-Regeln der Seite reagiert keine
einzige darauf. Es gibt auch keine .dark-Selektoren, keinen Umschalter im Benutzermenü und keinen
gespeicherten Theme-Zustand. Die Einstellung wird also nicht ignoriert – ein Dark-Theme existiert
schlicht nicht.

Interessanterweise wird prefers-reduced-motion sehr wohl ausgewertet. Da die Oberfläche bereits mit
Farbvariablen auf :root arbeitet, wäre ein zweiter Variablensatz vermutlich der kleine Weg.

2. Zustimmungs-Checkboxen bei der Registrierung kaum sichtbar

Auf /auth/sign-up habe ich die drei Pflicht-Kästchen in allen Zuständen ausgemessen (Farben aus
dem Screenshot ausgelesen, Kontrast gegen den weißen Hintergrund):

Ruhezustand, Rand #e5e7eb: 1,24 : 1 – verfehlt
mit Tastaturfokus, Rand #d1d1d1: 1,53 : 1 – verfehlt
angehakt, Füllung #056473: 6,83 : 1 – erfüllt

WCAG 2.1 SC 1.4.11 verlangt für Ränder von Bedienelementen mindestens 3 : 1. Der angehakte Zustand
ist einwandfrei, die beiden anderen liegen bei rund der Hälfte des geforderten Werts. Bei
Tageslicht verschwinden die leeren Kästchen vollständig.

Zwei getrennte Folgen:

Erstens sieht man nicht, dass dort überhaupt etwas anzuklicken ist. Da es drei Pflichtzustimmungen
sind, blockiert das die Registrierung, ohne dass erkennbar wird, woran es liegt.

Zweitens ist auch der Fokusindikator mit 1,53 : 1 zu schwach. Wer per Tastatur bedient, sieht kaum,
wo er gerade steht – das betrifft zusätzlich SC 2.4.7.

Im Anhang oben das Formular mit rot umrandetem Kästchen, darunter dasselbe Kästchen in den drei
Zuständen, achtfach vergrößert.

Hinweis: Ich teste eos weitgehend automatisiert und debugge gemeinsam mit Claude Code; daher die
Messwerte oben. Und weil es hier schon anklingt – ich fasse mich bewusst knapp, das ist der
Übersichtlichkeit geschuldet und nicht unhöflich gemeint.

Viele Grüße
Jonathan // Fabienne

Hallo zusammen,

eine Einladung über Team → Invite Member (Rolle leer gelassen) wird versendet und steht in der
Liste auf SENT. Die eingeladene Adresse kann sich damit aber nicht registrieren.

Ablauf: Invite-Link öffnen, drei Zustimmungen anhaken, Continue drücken. Sichtbar passiert nichts.

Im Hintergrund antwortet account.eoscloud.io/v1/signup mit HTTP 422:
{"errors":[{"path":"/invite_code",
"kind":"account.signup.errors.inviteCodeInvalid",
"message":"the invite code is missing, invalid or already used"}]}

Der mitgeschnittene Request enthält nur email und consent. Der invite_code fehlt vollständig – der
code-Parameter aus der URL wird nicht in den Request übernommen. Der Server verhält sich also
korrekt.

Zur Eingrenzung habe ich das fehlende Feld testweise mit dem code aus dem Invite-Link ergänzt.
Ergebnis: weiterhin 422 mit derselben Meldung. Offenbar erwartet /v1/signup unter invite_code den
Preview-Beta-Code und nicht die Kennung der Organisations-Einladung.

Gegenproben, alle mit identischem Ergebnis: eingeloggt und ausgeloggt, mit und ohne gesetzte
Zustimmungen. Die Einladung bleibt dabei unverbraucht auf SENT, ein neu verschickter Invite läuft
in denselben Fehler.

Daraus ergeben sich drei Punkte:

• Können Organisations-Einladungen während der Preview überhaupt angenommen werden, oder braucht
  jede eingeladene Person zusätzlich einen eigenen Beta-Code? Falls Letzteres: ein Hinweis im
  Invite-Dialog und in den Known Issues würde viel Sucherei ersparen – die Console vermittelt
  derzeit, die Einladung genüge.
• Der invite_code sollte in den Signup-Request aufgenommen werden.
• Bei einem 422 sollte die Seite eine Fehlermeldung anzeigen. Aktuell steht im DOM kein
  role="alert" und kein aria-invalid. Zudem wirft die Meldung "missing, invalid or already used"
  drei sehr verschiedene Fälle zusammen – ich war zwischenzeitlich überzeugt, den Code verbraucht zu
  haben, und hätte beinahe eine zweite Einladung verschickt.

Hinweis: Ich teste eos weitgehend automatisiert und debugge gemeinsam mit Claude Code; daher die
Messwerte oben. Und weil es hier schon anklingt – ich fasse mich bewusst knapp, das ist der
Übersichtlichkeit geschuldet und nicht unhöflich gemeint.

Viele Grüße
Jonathan // Fabienne