michaeleifel und ich konnten nun endlich unsere Server tauschen, und da wir das Thema erst vor kurzem hatten: Dank ihm habe ich nun tatsächlich einen Vincent van Bot in Nürnberg mit einer XX.XX.XX.XX IPv4-Adresse. Mein innerer Monk geht nun glücklich und zufrieden schlafen...
Und das hat dich nur eine Radeon 7800XT gekostet? 
Fairerweise würde ich hier aber zwischen dem SCP und dem CCP unterscheiden. Das CCP ist ja in erster Linie für Verwaltungs- und Vertragsthemen zuständig, das SCP für die technische Administration (mal von DNS abgesehen). Gerade Vertragsthemen möchte man ja schon in der Sprache lesen, die man am besten versteht, weil es da viele heikle Punkte geben kann, die man u.U. missverstehen kann.
Will noch wer?
Super, dass es jetzt geht!
Logge ich mich dagegen zuerst auf a.domain.de ein, und gehe dann auf speed.domain.de ist kein login mehr erforderlich. Ist das das korrekte Verhalten?
Ja. Genau das ist ja die Idee hinter einem SSO. Falls du ein anderes Verhalten möchtest, müsstest du für jede App andere User bzw. Gruppen nutzen und dann die User nur für die bestimmte App zulassen (Stichwort Subject: https://www.authelia.com/configuration/…access-control/).
Die Fehlermeldung sagt ja im Grunde nur, dass der Zugriff ohne Login blockiert wird (<anonymous>). Bist du denn in Authelia angemeldet? Du kommt vermutlich gar nicht zum Login Screen, wenn du die Seite aufrufst? Hast du denn für diese Seite (speed.domain.de) eine entsprechende nginx configuration vorgenommen?
Das was Paul sagt, nur kannst du für weitere Postfächer auch den 1€ Tarif nutzen.
Habe auf diese Weise zwei Postfächer bei denen im Team Betrieb.
Gut zu wissen. Danke. Ich dachte immer, dass alle Postfächer innerhalb eines Teams den gleichen Tarif haben müssten, weil sie die Preise "pro Nutzer / Monat" angeben.
Bei meinen eigenen Containern, die ich selbst gebaut habe, war das meist so . Vielleicht hat sich das mittlerweile auch etwas gebessert. Aber gerade früher war das latest Tag immer das letzte Image, das in die Registry gepusht wurde. Durch die CI Pipelines war das dann oft eben die Development Version oder wenn man Glück hatte eine alpha oder beta Version der Applikation.
Das Problem ist dann auch eher, das man später nicht mehr sieht, welche Version gerade läuft, wenn man nicht gerade den Hash Wert des Images überprüft. Wenn man heute ein Deployment mit latest macht, in 2 Wochen dann nochmal, hat man in der Regel eine komplett andere Version. Hat man z.B. einen postgres Container, den man vor kurzem mit dem latest Tag deployed hat, der dann in Version 16.x initialisiert wurde und macht jetzt einfach sein normales Updates, dann würde der jetzt in Version 17.x gestartet werden. Bei postgres schlägt das aber fehl, wenn man da keine manuelle Datenmigration macht. Obwohl sich im docker-compose File nichts geändert hat, steht man auf einmal vor einem kaputten Deployment, weil der DB Container nicht mehr startet. Daher sollte man immer nur Tags verwenden, die klar zeigen, welche Version damit gemeint ist.
Jetzt fehlen nur noch die Fehlermeldungen, die du erhältst. Das würde uns noch weiterhelfen.
Generell solltest du im immer das "latest" Tag vermeiden. Das ist in der Regel die Development Version, die meist fehlerbehaftet und nicht für produktive Umgebungen gedacht ist. Auch nicht für einen PoC oder eine Testumgbung. Sonst weißt du nie, welche Version du gerade im Einsatz hast. Dieser Hinweis gilt im Allgemeinen für sämtliche Container - auch wenn man das sehr häufig in Howtos und Dokumentationen liest.
Ersetze daher unabhängig der Konfiguration mal das authelia/authelia:latest durch ein authelia/authelia:4.38.16 (Das ist die aktuell stabile Version).
Ich kann zwar Aliase anlegen, aber das landet alles im selben Konto. Mehrere unterschiedliche, getrennte Postfächer zu der domain geht nicht, so wie ich das sehe, oder?
Ja, das ist korrekt. Jedes Postfach kostet extra. Es gibt zwar die Familien/Teams Tarife, bei denen man eine Domain für mehrere Postfächer administrieren kann, aber jedes Postfach kostet dann diesen Betrag (z.B. x * 3 €).
Hast du dich mal aus- und wieder eingeloggt bzw. wenn du mehrere Server hast einen anderen ausgewählt? Ich hatte auch schon den Fall gehabt, dass diese Meldung nicht direkt verschwunden ist nach dem Update, sondern erst bemi nächsten Login.
Im CCP lässt sich aber ein TOTP Device registrieren. So kann man zumindest den Weg über die E-Mail vermeiden. Möchte man es sich besonders einfach machen, dann kann man das TOTP Secret auch in einem entsprechenden Passwort Manager hinterlegen und sich dann zusammen mit dem hinterlegten Passwort anmelden. Bei einem 45-stelligen Passwort wird vermutlich sowieso ein Passwort Manager zum Einsatz kommen. Die gängigen Passwort Manager bietet das eigentlich alle an.
Ich selbst habe aktuell kein Authelia im Einsatz. Ist auch schon etwas her, dass ich das mal als PoC getestet habe. Daher kann ich gerade nicht mit einem praktischen Beispiel dienen. Im Authelia Github Repo selbst sind aber ein paar Beispiel Konfigurationen. Vielleicht helfen die dir auch schon weiter: https://github.com/authelia/authe…nfiguration.yml
Was hast du denn bisher gemacht? Generell lohnt es sich ja mit einer minimalen Konfig zu starten und dann nach und nach die Punkte hinzuzufügen, die man haben möchte.
Ein IDM bzw. SSO ist generell keine so einfache Geschichte. Damit muss man sich sowieso etwas auseinandersetzen. Da ist so eine Debugging Session in der Config durchaus hilfreich. Den Lerneffekt kann man da ruhig mitnehmen. Daher versuche es ruhig mal. Viel Erfolg.
Woran genau scheitert es denn? Wir können ja zur Not Punkt für Punkt durchgehen. Zumindest der access_control Teil mit den verschiedenen Bedingungen für one_factor bzw. two_factor sollte so immer noch gültig sein. Siehe hier: https://www.authelia.com/configuration/…/#configuration
Ja, du kannst für jede Domain anpassen. Eine gute Anleitung findest du z.B. hier: https://thehomelab.wiki/books/dns-reve…x-proxy-manager
In der authelia Konfiguration sieht das dann z.B. so aus:
access_control:
default_policy: deny
rules:
- domain: # Proxies only requiring username and password
- "homer.yourdomain.com"
policy: one_factor
- domain: # Proxies needing 2 factor below
- "proxmox.yourdomain.com"
policy: two_factorIch würde mir auch überlegen, ob es nicht sinnvoll wäre, wenn man das auf mehrere (evtl.) kleinere Server aufteilt. Dann könnte man auch verschiedene Server Typen einsetzen. Während ein Gameserver vor allem auf RS Servern gut läuft (da meist sehr CPU lastig), ist ein Webhosting Server da weniger anspruchsvoll und läuft sicherlich problemlos auf einem günstigeren ARM VPS. Generell würde ich Gameserver immer von anderen Services trennen, da diese doch sehr gerne und primär angegriffen werden. Hat man sehr viele Services zentral auf einem Server, hat man auch einen recht großen Kollateralschaden, falls einer dieser Services angegriffen wird bzw. eine Sicherheitslücke aufweist. Das sollte man definitiv in der Überlegung berücksichtigen.
Ansonsten würde ich empfehlen, zu Beginn einen Server mit kurzer Laufzeit zu nehmen und es einfach mal zu testen. Dann kannst du bei Bedarf auch wieder wechseln oder aber die Zufriedenheitsgarantie in Anspruch nehmen. Die eigene Erfahrung ist meist immer die beste .
Wie tab schon angedeutet hat. Schau wirklich erst einmal, ob der Server überhaupt Mails versenden kann. Denn deine Anleitung ist etwas ungenau bzw. unvollständig. Das mailutils Paket alleine reicht nämlich nicht um Mails versendet zu können. Das sind nur Tools um mit einem Mailserver zu kommunizieren um über diesen Mails zu verschicken. Aber einen laufenden Mailserver braucht es dafür trotzdem. Es könnte gut sein, dass bei deinen alten Ubuntu Installationen dieser automatisch installiert und gestartet wurde und dieser jetzt in Ubuntu 24.04 (zumindest in der Standard-Installation) fehlt.
Da du mit keinem Wort erwähnst, dass du einen solchen Mailserver installiert oder konfiguriert hast, war es vermutlich sowieso eher Glück, dass das in der Vergangenheit funktioniert hat. Denn einen Mailserver (auch wenn er nur Mails verschicken soll), muss man dennoch entsprechend einrichten (mit allem was dazu gehört: DNS, DKIM, ...). Ohne eine entsprechende Konfiguration würde es früher oder später sowieso zu Problemen kommen. Es kommt natürlich auch etwas darauf an, wo man die Empfänger E-Mail Adresse hat, aber um grundlegende Mailserver Kenntnisse kommt man da nicht drum herum.
Noch mal meine Frage: Wie installiert man das auf einem Betriebssystem, auf dem es kein Docker gibt?
Es läuft auch auf Kubernetes! Installierbar über ein bereitgestelltes Helm Chart. 
Naja, eine WAF ist kein festes Regelwerk, das für alle Applikation immer gleich sein muss. Das muss individuell angepasst werden. Einfach nur blind alle Regel zu aktivieren wird meist nicht zum Ziel führen. Eine vorkonfigurierte Regel in der WAF zu deaktivieren, damit die Applikation läuft, ist eigentlich völlig in Ordnung. Daher kann das durchaus eine Dauerlösung sein. Mit anderen Security Tool (z.B. ist es ähnlich). Auch da dauert es gerade zu Beginn einige Zeit, bis man die Fehler identifiziert und Ausnahmen konfiguriert hat.
Wenn man jedes Mal wenn man systemd verwendet Sekt trinken muss, gefällt dies langfristig nicht der Leber.
Allerdings freut sich die kaiserliche Marine
