 Okay, leg mal los. Ich stelle heute AE Host D vor. Das ist ein spezieller NSS-Pen-Service für AIDIER. Mein Name ist Michael, ich mache sowas beruflich. AIDIER, ich halte nicht nochmal ein AIDIER-Vortrag. Keine Sorge, davon habe ich jetzt schon einige gehalten, auch vor drei Jahren wieder hier auf der GPN. Kann man sich im Detail anschauen. Jetzt kommen einfach nur zwei Folien, kurz mal zur Erinnerung, was AIDIER eigentlich ist. AIDIER ist ein Open-Elder-basiertes User-Management. Letzten Endes greifen halt zum Beispiel irgendwelche Linux-Systeme oder auch irgendwelche Web-Anwendungen über LDAP auf ein LDAP Server zu, um dort sich eben Benutzendaten, Benutzergruppen zu ziehen und auch zum Beispiel ein Password-Check durchzuführen. Und so sieht ungefähr so die Architektur aus und heute möchte ich reden über diese Komponente da unten links, die quasi auf einem Unix-Suite-System läuft, also meistens eben auf einem Linux. Und diese Komponente wird dazu benutzt, wenn ein Admin sich zum Beispiel über SSH anmeldet auf einem Linux, dann wird die Komponente dazu benutzt, eben über den Name-Service-Switch eben die Benutzergruppendaten dem Betriebssystem zur Verfügung zu stellen und zweitens eben auch eine Passwortprüfung durchzuführen. Auch nochmal zur Erinnerung, weil das hinterher wichtig ist, warum habe ich das überhaupt gemacht? Also warum überhaupt noch mal so einen eigenen Dienst schreiben? Bei AIDIA ist es so, dass quasi alle angeschlossenen Komponenten müssen sich individuell authentifizieren, also zum Beispiel mit einem Host-Password. Und dann werden sie im Prinzip über so eine ganze Referenz-Kette autorisiert überhaupt Benutzer und deren Gruppen zu sehen. Also das Hauptparadigma, also das Ziel ist eigentlich, Systemen wirklich nur die Benutzerdaten und Gruppen zur Verfügung zu stellen, die sie auch wirklich benötigen. Also das ist im Gegensatz zum Beispiel zu einem Active Directory. Da melden sich zwar auch alle Arbeitsstationen an und so, aber die sehen im Prinzip immer den kompletten Datenbestand, also auch meint wegen auch die Gruppe der Superduper-Admins und deren Handynummern, wenn sie im AD stehen. Und das ist eben genau das Design-Ziel von AIDIA, irgendwie praktisch dieses Need-to-Know-Prinzip durchzusetzen, wirklich nur Dinge bereitzustellen, die die Systeme auch brauchen. Das zweite Prinzip ist, dass das rein über die Konfiguration, also praktisch rein über Datenpflege geschehen soll. Also das heißt, insbesondere hier unten, letzten Endes auf den Zielsystem, die so einige sein können, auch mal ein paar tausend, möchte ich gar nichts lokal konfigurieren. Also ich könnte jetzt zum Beispiel hier sagen, naja gut, ich beziehe jetzt über irgendwelche speziellen LDAP-Filter, nur die Benutzer und Gruppen, die das System sehen soll, das machen andere Implementierungen so. Aber bei AIDIA ist es wirklich so, dass sie mit dem System integrierten Komponenten eben mit Absicht dumm sind. Und dieses mit Absicht dumm bedeutet, dass die eigentlich, also in SQL-Sprech würde man sagen, dass die einfach so from-table-select-stern machen. Also gibt mir auch immer, was ich sehen darf. Und das bedeutet, dass praktisch der OpenLDAP-Server mit Hilfe von Z-basierten ACLs, die ständig diese Referenzen verfolgt und quasi Fuse on the fly erzeugt. Und das verbraucht ziemlich viel CPU-Zyklen. Und deswegen war letztes Jahr eben mein Ziel, das Problem mal so zu adressieren und damit eigentlich auch einen Beitrag zum Umweltschutz zu leisten. So, kurz mal, was ist NSS und was ist PAM? NSS ist einmal der Name-Service-Switch-Unterlinux-System. Im Prinzip, wenn irgendein AP-Call zur GLPC kommt, ich brauche zum Beispiel den Benutzerdatensatz, dann wird intern immer der sogenannte Name-Service-Switch gefragt. Und dieser Name-Service-Switch, der wird konfiguriert über eine sehr einfache Konfig-Datei in etcns-switch.com. Da gibt es im Prinzip einfach immer nur so ein Map-Name und ein Modul oder eine Liste von Modulen, die eben benutzt werden sollen, um bestimmte Namen zu beschaffen. Also zum Beispiel die Pass-WD-Map. Wir können uns das auch mal kurz angucken auf einem System. So, hier sieht man zum Beispiel für die Pass-WD-Map, da werden die lokalen Files sollen eben ausgewertet werden, eben die etc-Pass-WD. Und dann soll hier zum Beispiel noch ein anderes Modul angezogen werden. So, und diese Module, das sind letzten Endes einfach Shared-Libraries. Das heißt, gebe ich hier im Prinzip irgendein Modul-Namen an, hinter dem Map oder mehrere, dann guckt das System, um die LPC einfach, ob sie dynamisch eben den passenden Namen quasi einlinken kann. Also das heißt, hier habe ich zum Beispiel einen Modul-Namen AEDIA, und dementsprechend gibt es eben auf dem System hier auch eine dementsprechende Shared-Library, die dann eben dynamisch gelingt wird. Wichtig ist dabei auch, jedes dieser Module wird tatsächlich, also wenn man solche NSS-Module angibt, dann werden diese Module tatsächlich in jeden Prozess gelingt. Das muss einem klar sein. Das heißt, diese Module sollten auch möglichst schlank sein. Die Funktionsweise von diesem Name-Service-Switch kann man ganz gut testen, einfach mit dem Get-End-Befil. Also man kann hier meinetwegen jetzt Get-End-Pass-WD-Fu machen. Den Benutzer gibt es nicht, dabei gibt es da einfach auch keinen Ergebnis. Wir können jetzt mal was listen. Zum Beispiel gibt es den Standard-User-WWW-Run, dann bekomme ich praktisch den Get-End-Pass-WD-Eintrag zurück. Also kurz zusammengefasst, der Name-Service-Switch ist dazu da, aus verschiedenen Datenquellen, auch potenziell remote Datenquellen eben sich die Get-End-Pass-WD, Get-End-Gruppdaten zu beschaffen, aber zum Beispiel auch Get-End-Hos, zum Beispiel über DNS sich zu beschaffen. Da gibt es dann immer auch zwei Varianten. Also speziell, wenn so Daten eben von Remote beschafft werden, dann kommt es darauf an, wie groß sind diese Datenbanken. Und dann muss man sich auch immer entscheiden, ob man da sogenanntes Enumeration macht. Also ob man zum Beispiel erlaubt, dass quasi bei einem, zum Beispiel bei einem Get-Pass-WD, ohne Angabe von einem Namen, ob praktisch die Datenbestände, die Remote beschafft werden, ob die zum Beispiel auch komplett gelistet werden, ja oder nein. Ich sage da nachher was im Detail dazu. Genau. So, und dann gibt es eben PEM, Plugable Authentication Modules. Das ist im Prinzip ein ganzer Stack konfiguriert, wird das typischerweise in einem Unterverzeichnis EDC PEM.de. In diesen Unterverzeichnissen sind im Prinzip immer pro PEM-fähigem Service, eine eigene Datei drin. Und diese Dateien, die referenzieren eben zum Beispiel wieder Shared Libraries. Heutzutage ist es meistens so, dass im Prinzip der für die, also eigentlich alle Services auch wieder so gemeinsame Include-Dateien haben. Das sieht dann zum Beispiel so aus. Hier sieht man zum Beispiel, es gibt so verschiedene auch PEM-Dienste, oder praktisch verschiedene PEM-Requests, zum Beispiel hier für die Authentifizierung. Und da sieht man zum Beispiel, dass hier eine zentrale Datei eingebunden wird, irgendwie in der dann zum Beispiel auch wieder bestimmte verschiedene Module hintereinander eben referenziert werden. Man sagt hier halt auch immer zum Beispiel, okay, hier required bedeutet, er muss hier durch diesen Schritt wirklich erfolgreich durch. Das nächste wäre, wenn das hier erfolgreich ist, dann kann er auch schon als erfolgreich abbrechen. Aber auf jeden Fall, wenn er hier noch auf das letzte Modul aufschlägt, dann muss er im Prinzip wirklich, muss dieses Modul wirklich ein Return Code okay zurückliefern. Und das ist hier so ein ganz typischer Vorgehensweise. Also man initialisiert hier ein Environment und dann sagt er hier, ja okay, die Passwortauthentifizierung hier ist praktisch optional. Wenn die erfolgreich war, gehe hier schon raus. Wenn nicht, muss auf jeden Fall die Passwortauthentifizierung gegen ETC Shadow erfolgreich sein. Das bedeutet diese Datei. An PEM-Dateien rumfummeln, ich werde selber immer sehr nervös, obwohl ich das schon ein paar Mal gemacht habe. Also das Beste ist natürlich, die sich einfach mal so Experimenten, Routschelz offen zu haben. Und dann muss man aber natürlich auch sehr darauf achten, dass man sich nicht auch Dinge aufmacht. Also man kann sich beliebige Dinge hintereinander stapeln. Und man muss sehr darauf achten, dass man sich nicht auf einmal irgendwie ein Routlock in ohne Passwort oder sowas aufmacht. Und da gibt es auch sehr prominente Fälle von Linux-Distributionen, denen das passiert ist. Und am besten ist natürlich, dass man das dann auch, naja, mit einem Config Management ausrollt, wenn man irgendwie mehr als zwei Maschinen hat. So, dann wichtig auch in dem Zusammenhang ist eben Sudo, also für die, um eben zum Beispiel mit höheren Privilegien eben Programm ausführen zu können. Typischerweise wird Sudo eben aufgerufen. Man gibt eventuell nochmal das Passwort ein, wie es konfiguriert ist. Konfiguriert ist das in einer Datei, die im Prinzip auf dem meisten Linux-Distributionen noch wieder Dateien aus einem Unterverzeichnis einbinden kann, mehrere. Die Dateien müssen auch eine bestimmte Ownership und Permissions haben. Also praktisch, die müssen quasi Rout gehören und dürfen zum Beispiel nicht World Readable sein oder so was. Das Ganze gibt es auch in der LDAP-Variante. Also der Autor von Sudo hat auch ein LDAP-Schema entworfen, irgendwie. Das Schema verwende ich quasi auch in dem Aedir. Das verwenden auch viele andere. Und man kann dann entweder mit dem sogenannten Sudo-LDAP quasi immer bei jedem Sudo-Aufruf, praktisch das Sudo- und LDAP-Server fragen lassen, um die Regeln zu beziehen. Oder man kann das Ganze zum Beispiel über so ein Cache machen mit der SSSD-Komponente. Und da wird dann Sudo quasi gegen so eine Shared-Library gelingt aus dem SSSD-Projekt. Gut. Ja, zur Motivation habe ich schon ein bisschen was gesagt. Also einmal halt dieser enorme Ressourcenverbrauch, was so CPU und IOU angeht für dieses ständige Prüfen der Berechtigung. Einfach, weil die Kleins halt doof sind und keine bestimmten selektierten Suchen machen. Das heißt, das Ziel war quasi, wirklich einen Klein zu entwickeln, der die Daten schon kennt und deswegen viel effizienter suchen kann. Dann ist es so, wenn man das Sudo-LDAP direkt benutzt, kann es halt passieren, dass die Leute lassen irgendwelche Grundschops laufen, also auch relativ synchron. Und dann kommen halt im Prinzip Synchroen, jede Menge TLS-Verbindungen auf diese LDAP-Server halt auch gleichzeitig, was natürlich zu solchen Peaks führt und natürlich auch immer wieder man jedes Mal neu durch den kompletten TLS-Handshake durchgehen muss. Ist auch sehr ineffizient. Wie gesagt, das kann man so ein bisschen mildern, indem man halt im Prinzip SSD benutzt, mit dem Sudo-Scaching. Das hat ein bisschen andere Nachteile. Also speziell, was einem so ein bisschen bei ist, wenn man viele Clients hat, dass zum Beispiel auch die Last von solchen Verbindungen, wenn man zum Beispiel mehrere der verfügbaren Repliken einträgt, dass die Last im Prinzip eventuell auf einige wenige Repliken praktisch abgefeuert wird. Das heißt, es war auch so ein bisschen das Ziel, ein vorherrsagbares Verhalten zu haben beim Verbindungsaufbau. Und insbesondere, dass Dinge auch nicht Synchroen kommen. Das Nächste ist, dass jeder Client sich im Prinzip auch individuell anmelden muss. Das heißt, man muss irgendwie auf diesen Client einen Host-Passwort draufbringen. Das ist ähnlich wie bei Active Directory Domains. Da macht man auch einen lokalen Administrator-Lock-On, dann triggert man da den Domainshoin an. Meistens gibt man da noch ein Administrator-Passwort ein. Das ist halt auch etwas, was halt ein bisschen schwer zu automatisieren ist. So, und dann gibt es noch ein bisschen was Spezielles. Ich wollte auch ein spezielles Verhalten haben mit dem MediaServer selbst, weil die sind mit sich selbst integriert. Und ich wollte einfach die Präferenzen des Verbindungsaufbaus, also welche LDAP URLs verwendet werden, die wollte ich vorherrsagbares haben. Und zu guter Letzt gibt es ein paar Feature-Request, die ich zum Beispiel an die SSD-Leute hatte. Und das Einzige, was die jetzt seit 2014 machen, in diesem Ticket ist, im Prinzip immer den Milestone nach oben zu setzen. Von daher war ich auch irgendwie so ein bisschen müde, Feature-Request bei anderen anzufragen. Ja, genau. Also bessere Performance, das meiste habe ich schon gesagt, besseres Kleinzeit, Load-Ballingsing, irgendwie so ein bisschen randomisierte Zugriffe, ein Enrollment, mit einem Pseudo-SS-H-Login erkläre ich gleich. Und das Ding sollte halt auch einfacher sein. Also wirklich weniger Dependencies, also keine Dependencies auf Debuss, keine Dependencies auf irgendwelche komischen Datenbank-Libraries oder sonst irgendwas. Wer hat schon mal versucht, SSD selber zu kompilieren? Also womöglich noch unter einem Nicht-Linux-System oder so? Ja, also ist es ein bisschen schwierig. Ja, wie sieht das Ganze so aus, von der Architektur? Eigentlich sieht es genauso aus wie alle anderen Komponenten auch. Ja, also auch NSS-Pem-L-D- oder SSD- haben im Prinzip immer diese Frontend-Module, die dynamisch in jeden Prozess reingelingt werden. Also ein NSS-Modul und ein PEM-Modul. Und das greift im Prinzip über ein Unix-Domain-Socket eben auf den AE HostD zu, der hier also bisher nur einfach nur ein In-Memory-Cache hat, quasi, von den Daten, die er eben im Prinzip aus dem AEDI bezieht. Des Weiteren ist es so, dass der AE HostD außerdem auch zum Beispiel die Authorized Keys synchronisiert, ganz simpel in lokales Verzeichnis, ganz einfache Key-Dateien und außerdem synchronisiert er auch Sudoers-Files. Also er beschafft die Sudoers-Regeln und legt die auch wieder ganz einfach als eine Sudoers-Config-Datei ab. Um das machen zu können mit den richtigen Ownership and Permissions, gibt es praktisch zwei Teile. Einmal im Prinzip ein AE HostD, der nicht privilegiert läuft, also quasi unter einem Benutzer, der halt nur in dem eigenen Barlib-Verzeichnis schreiben darf. Und dann gibt es eben nochmal so ein Privileged Helper, der sieht, ah, okay, da gibt es jetzt eine neue Sudoers-Config-Datei, dann schiebe ich die an die richtigen Ställe und setze Ownership and Permissions korrekt. Ja, das Ganze ist ein Preisen implementiert, tatsächlich. Und die Frontend-Module, also diese beiden Module, da benutze ich im Prinzip die, einfach die Frontend-Module von einem NSS-Perm-L-D, die sprechen ein sehr einfaches Protokoll. Ja, irgendwie reichen da eben die Anfragen rein und kriegen die Results zurück mit einem sehr einfachen Protokoll. Und freundlicherweise hat der Autor von dem NSS-Perm-L-D auch schon eine Möglichkeit geschaffen, dass man diese NSS- und Perm-Module von ihm, diese Frontend-Module auch mit einem separaten Namen kompilieren kann. So, dass es zum Beispiel eben auch keinen Clash gibt mit irgendwelchen anderen Namen oder Modulen, die es bereits aus irgendwelchen Betriebssystempaketen gibt. Ja, den Rest habe ich schon so beschrieben. Nach langem hin und her, also ich habe, das hatte so mehrere Iterationen wieder das Projekt. Am Anfang habe ich mich auch sehr stark daran orientiert, alles irgendwie Ergebnisse, also Requests und Responses, immer nur so zu streamen und bloß keinen Enumeration zu machen. Und irgendwann habe ich beschlossen, nee, ich mache einfach nur Full Map Enumeration. Das heißt insbesondere, dass quasi Passwd- und Grobdaten immer komplett da sind einfach, auch in sich konsistent. Weil teilweise gibt es Software, die braucht im Prinzip die vollständigen Map-Daten, die kann zum Beispiel nicht damit zurechtkommen, dass sie immer Passwd- und Grobdaten immer explizit anfragen muss. Also manche Software macht einfach ein Enumeration und erwartet einfach, dass das vollständig ist, die Map. Ja, und bei diesem Sudo-Support, also wie gesagt, das ist ein ganz einfacher File-Export quasi, und da braucht man eine Sudo-Version ab 1823, weil da gibt es so ein spezielles Command-Line-Tool namens CVT-Sudo-S, womit man halt bestimmte Formate ineinander konvertieren kann. Es gibt noch ein paar nette Features, und zwar, ich muss jetzt mal nochmal ganz kurz zurück, so hier diese Referenzen zwischen sogenannten Service-Grobes und Benutzer-Gruppen. Die haben eine bestimmte Bedeutung. Also einmal, die Menge aller sichtbaren Benutzer ist einfach die Vereinigungsmenge aller Gruppenmitglieder, die mit AI Visible-Grobes referenziert werden. Oder es gibt hier zum Beispiel so etwas wie AI Setup-Grobes, das bedeutet, das sind eigentlich die Leute, die quasi zum Beispiel eine Host-Gruppe erweitern können, die auch insbesondere auch das Host-Passwort zum Beispiel setzen können. Und das sind halt im Prinzip auch wieder alle Setup-Admins quasi. Ist die Mitglieder, die Vereinigungsmenge der Mitglieder alle hier über AI Setup-Grobes referenzierten Gruppen. So, und hier gibt es unter anderem auch eine Gruppe, also so eine Referenz AI Lock-Store-Grobes. Das sind zum Beispiel alle Leute, die auf dem System zum Beispiel Lock-Files sehen sollen. Weil es ist auch so ein übliches Problem, dass man zum Beispiel sagt, ich habe mehrere Benutzergruppen und die sollen eigentlich auch Valock-Lesen zugreifen können. Und das kann man einmal mit Dateisystem-ACLs machen, aber manche Leute mögen das nicht, weil Dateisystem-ACLs haben da auch immer wieder so ein bisschen ihre Misslichkeiten. Und ja, und von daher wäre es natürlich praktisch, man hat genau eine Gruppe, die im Prinzip alle diese, also die ganze Vereinigungsmenge der Benutzer mit Lock-Store-Recht enthält. Und zu diesem Weg gibt es eben so genannte Virtual-Grobes, also die im Prinzip diese Rollengruppen, also diese Referenzgruppen, also, ja, also, mehr wie soll ich es nennen, also diese speziellen Permissionsgruppen nochmal abbilden quasi in lokale, in lokale Unix-Gruppen. Auch ganz nett ist so ein Feature, so ein, das sogenannte LDAP Session Tracking Control, das ist eben einer der Feature-Requests gewesen, die ich an den SSSD hatte. Da kann im Prinzip jeder LDAP Klein, kann zum Beispiel mit einer LDAP-Operation mitschicken, auch weitere Daten, also zum Beispiel, wenn er so eine Art Proxy ist, wie ist zum Beispiel die IP-Adresse von dem Klein? Ja, und das ist so ein ganz nettes Feature, weil dann kann man auch hinterher zum Beispiel SSH, also praktisch IP-Adressen von SSH-Kleins finden, wenn praktisch der SSH-Server das Passwort von den Benutzer geprüft hat. Dann klebt da quasi die IP-Adresse an diesem Bind, an diesem Bind Lock-Eintrag. Im Gegensatz zum SSSD unterstütze ich hier auch die Host-Map, das kann manchmal ganz praktisch sein, wenn einem das DNS mal wegfliegt. Ja, und eben das spezielle Feature ist eben auch, dass praktisch das Enrollment, also das Setzen des Host-Passwords, eigentlich ganz simpel über so ein Pseudo SSH-Lock-In geht. Das heißt, ich mache quasi hier eine Verbindung auf, ich setze das Host-Passwort und ich mache hier so ein Lock-In auf so einen generischen User, und wenn genau dieser User eben kommt, dann sagt eben der PamDemon, ah ja, okay, jetzt prüfe ich das doch mal gegen mein Host-Passwort und wenn das stimmt, dann schreibe ich mir das in die Konfiguration. Das heißt, ich kann eine Maschine im Prinzip initialisieren, ohne quasi so einen lokalen Lock-In zu haben. Also ich habe das hier nochmal versucht zu illustrieren. Das heißt, der Admin, der möchte eigentlich die Maschine neu initialisieren, die kommt irgendwie aus dem Dipläumen raus, der AehostD läuft da drauf auch, aber er kann eigentlich im Prinzip noch nicht zugreifen, weil erst muss der Admin quasi das Host-Passwort setzen in dem Directory, dann macht er praktisch diesen Pseudo SSH-Lock-In mit diesem Aehost-Init-User, das geht dann eben über dieses Pam-Front-End-Modul zu dem AehostD und der checkt das eben gegen sein eigenes Host-Passwort und im Erfolgsfall schreibt er das einfach lokal in die Konfig. Genau, noch ein bisschen was zur Konfiguration. Minimal ist die Konfiguration, also einfach nach einem frischen Dipläumen von der Maschine, einfach wo findet er die LDAP-Server, welche CA-Zertifikate muss er benutzen, um die TLS-Verbindung korrekt validiert aufzumachen und im Prinzip der eigene BIND-DN. Und wie gesagt, das Passwort wird dann rein initialisiert. Es gibt zwei verschiedene Parameter, URI-List und URI-Pool. URI-List ist tatsächlich eine Liste von LDAP-Replicken, die einfach stur im Prinzip durchprobiert werden, also genau in der Reihenfolge. Und URI-Pool ist im Prinzip eine Liste von Servern, die sortiert werden und dann mit einem Hash quasi rotiert werden, mit einem systemspezifischen Hash rotiert werden, um praktisch so ein kleinseitiges Loadbalancing zu implementieren. Und auf den AID Servern selbst sieht das dann einfach so aus, man kann das eben kombinieren, also das heißt, es gibt eine feste URI-List, fragt mich einfach selbst und dann gibt es praktisch ein URI-Pool der anderen Replicken, die man fragen kann. Ja, diese ganze Konfiguration, da gibt es natürlich auch eine fertige Enzybelrolle zu, um das zu konfigurieren. Genau, wir machen jetzt zwar mal zwischendrin mal kurz ein Demo. Also ich bin hier Ruth auf einer Maschine, so eine Testmaschine, die kennt im Moment gar nichts von AIDIER, außer eben praktisch so einen fest eingeprogrammierten generischen Log an. So, hier ist auch das passende verzeichnet, da ist im Moment gerade nichts Spannendes drin, einfach zwei leere Verzeichnisse. Das heißt, die Maschine muss erst noch initialisiert werden. So, ich mache das jetzt mal manuell. Normalerweise würde man sich da natürlich irgendwie ein Skript schreiben für solche Sachen, aber das illustriert das einfach viel besser. Na, okay. So, ich suche mir jetzt hier das Host-Objekt. So, und auf die Details will ich jetzt hier gar nicht eingehen. Im Prinzip, das ist wirklich sozusagen das Host-Objekt. Welches auch hier in einer Kurzform hier auch verwendet wird. Also das ist im Prinzip eine Kurzform von dem Bein-DN, den der I-host-D verwenden soll, um sich an den Open-Elder-Server zu verwenden. Und hier steht einfach nur, ja, das Passwort findest du in dieser Datei. Und die Datei gibt es halt gerade nicht. So, jetzt setze ich einfach mal das Host-Passwort neu. Das ist genau das hier. So, und jetzt mache ich genau das. Ich mache einfach mit diesem Pseudo-User, mit diesem generischen Pseudo-User, mache ich eben einen Log-On. Und wir gucken uns da mal kurz die Log-Meldung auch an. Hier sieht man zum Beispiel schon, aha, okay, der kann im Moment gar keine Replicken erreichen und so weiter, er kann die Passwort-Datei nicht lesen. Ja, jetzt gucken wir mal, wie das weitergeht hier. So, und jetzt mache ich hier ein Passwort-Log-On. Ich kann natürlich nicht wirklich, ich bekomme nicht wirklich eine Session. Ja, das heißt, der macht im Prinzip einfach nur die PEM-Authentifizierung, diesen Authentifizierung-Step, ja. Ja, und hier ist jetzt schon alles durch. Also, so, jetzt sieht man halt hier. So, hier sieht man, dass er halt im Prinzip sagt, da kommen jetzt ein paar Sachen zwischen drei, ja, hier sagt er zum Beispiel, dass er die Passwort-Datei neu geschrieben hat. Eigentlich müsste er noch irgendwo locken, aber ich sehe gerade den Wald voller Bäumen nicht, er müsste noch irgendwo locken, dass er das gegen den eigenen Host-Passwort geprüft hat. Also, hier steht auch sowas wie Host-Passwort, check okay. Das ist im Prinzip die PEM-Response, die der SSHD zurückbekommt. Aber es wird eben nicht autorisiert. Also, es wird nicht der Log-On autorisiert, sondern einfach nur gesagt, ja, ich mache diese Pseudo-Authentifizierung gegen das Host-Passwort. Wenn das okay ist, schreibe ich es mir lokal rein. Ja, und später sieht man hier schon, dass sich dann praktisch auch verbindet und sich die ganzen Daten holt. So, und jetzt sieht das hier ein bisschen anders aus. Jetzt sieht man halt hier diese ganzen, praktisch diese ganzen Pass-WD-Daten. Und dementsprechend eben auch die Group-Map, ja. Und hier sieht man zum Beispiel jetzt auch, ja, das sind quasi alle AED-User, die sind in dieser generischen Gruppe. Dann gibt es eben auch virtuelle Gruppen für jede separate primäre GID eines Benutzereintrags. Ja, das sind alle diese Sachen, die mit eben AEV-Grupp anfangen. Und hier gibt es eben genau diese Gruppe zum Beispiel, die eben die Gruppe der Setup-Admins ist. Die ist jetzt hier sehr klein. Okay, also, ich habe das auch mal so ein bisschen... Ach so, ich habe jetzt keine Folie gemacht für so Messergebnisse, also ich habe mal so ein bisschen durchgemessen. Das Ganze ist ja in Peißen geschrieben, also könnte man sagen, oh, das ist vielleicht nicht so performant oder so, ja. Aber schon auf dieser kleinen VM macht er irgendwie so NSS-Map-Request, ungefähr 3, 3.500 pro Sekunde oder sowas, ja. Da habe ich dann erstmal gesagt, wir müssen weiter optimieren, ja. Wenn jemand halt irgendwie solche Fileserver betreibt, ja, die mehr Requests machen, dann hat er nochmal andere spannende Performance-Probleme, ja. Ich habe auch eine Weile rumgemacht, zum Beispiel den Ressourcenverbrauch, also zum Beispiel den Speicherverbrauch, nochmal ein bisschen runter zu drücken, ja. Und das ist mir eigentlich auch gelungen, also es ist relativ wenig Speicherverbrauch, obwohl ich quasi die kompletten Maps quasi in einem Cash halte, ja. Ich habe das jetzt so ein Jahr lang bei mir laufen, ja. Es scheint irgendwie ganz stabil zu sein, ja. Also mir ist da irgendwie noch nichts Böses jetzt passiert. Wie gesagt, bei PEM immer so ein bisschen aufpassen. Also ich habe bei der Implementierung von dem Deemen habe ich wieder sehr viel auch über PEM gelernt, ja. Also nochmal mehr, ja. Und dann nämlich auf einmal wirklich sieht, welche Applikationen, welche Komponente, mit welchen Parametern eigentlich irgendwas von PEM will, ja. Das ist sehr lehrreich, ja. Und wann welche Komponente Parameter setzt oder nicht, ja. Manchmal finde ich es aber auch ein bisschen merkwürdig, ja. Also ein bisschen, ja. Es ist schön, dass man natürlich auch eigene Features implementieren kann. Ich war dann so gleich ganz heiß darauf, musste mich aber auch selber zurückhalten, wie an Feature RIT ist zu erkranken, ja. Also das heißt, ich habe jetzt erstmal mich selber diszipliniert, wirklich nur erstmal das Notwendigste zu implementieren. Und das aber eben auch sicher, ja. Genau, jetzt gibt es noch so ein paar weitere To-dos, ja. Irgendwie zum Beispiel in Salt State für eine bestimmte Umgebung zu bauen. Das dürfte nicht so schwer sein. Also es gibt auch jemanden, der hat schon einen gebaut, für A, E, H, C. Dann größeres Summer of Code Projekt dieses Jahr ist Python 3 Migration und halt vielleicht noch ein Puppet-Modul zu machen, als Beispiel für Leute, die Puppet einsetzen. Genau, das war es so weit. Irgendwelche Fragen. Also die Frage war, wie validiere ich den Cash, ja, irgendwie. Eigentlich ist es ein ganz stumpfes Refresh. Also und zwar ein ganz stumpfes Full Refresh. Man kann sich da einstellen, in welchem Zeitraum. Und dann, damit die sozusagen nicht alle auch Synchronen kommen, gibt es dann auch immer noch so einen kleinen Random Jitter da dran. Aber im Prinzip ist das einfach nur ein Thread, der praktisch ein Full Refresh macht von den Maps und dann sich praktisch wieder schlafen legt. Also wirklich total low-tech. Also sowas von super Simpel gehalten. Und auch da kann man natürlich Dinge falsch machen. Das habe ich auch vor ein paar Wochen, habe ich gerade wieder noch mal im Back gefunden, wo ich in einer bestimmten Situation keinen Full Refresh ausgelöst habe. Also es ist auch so, dass im Prinzip die Gruppen-Map, die Gruppen-Map wird praktisch immer voll enumeriert. Und bei den Benutzer-Daten, da macht er im Prinzip ein Full Refresh nur nach einer anderen Zeit und macht nur Delta-Abfragen. Also gibt mir die, die sich irgendwie geändert haben oder so. Genau. Sonst noch irgendeine Frage? Ja. Genau, das ist einfach so ein vorkonfigurierter User, den aber auch der Aehostee schon selber beantwortet. Also den muss man jetzt nicht zum Beispiel in die ETC-Passwd in die Datei von Hand eintragen oder so. Ja, aber nur für diesen User. Also ich habe hier praktisch eine Weiche drin. Also die Frage war, ja, muss für jeden Benutzer im Prinzip die Passwort-Audentifizierung erlaubt werden? Nee, man kann das in der SSHD-Konfiguration eben so einstellen. Ja, das ist nur diesen Benutzer betrifft. Das ist ein bestimmter Satz für SSSD? Ja. Wie viel fehlt? Also es implementiert komplett die Passwd und die Gruppen-Map und zusätzlich noch die Host-Map. Die anderen Sachen, die eigentlich auch von den Frontendmodulen von dem NSS-Pam LWD wie Ether-Smap und so, das habe ich jetzt erstmal weggelassen, obwohl das auch tatsächlich möglich ist, also auch mit den AeD-Daten möglich ist. Ja, also der SSSD, ich will da jetzt auch kein Bashing betreiben, aber es ist halt im Prinzip, das Ding kann sehr viel, macht aber auch sehr viel zum Beispiel über so Debussmittel und so weiter und so fort. Also die machen halt auch sehr viel wie so zum Beispiel Lock-in mit Smart-Cards, mit X5009-Certifikaten und dann irgendwie im Name-Mappings wieder auf Linux-Benutzer. Ja, und ich habe für mich beschlossen, dass ich das nicht mache, sondern es gibt ein anderes Projekt. Ich glaube, das habe ich letztes Jahr vorgestellt hier. Also praktisch mit temporären Open-SSR-Certifikaten zu arbeiten, wo man viel weniger bewegliche Teile hat, also viel weniger Dinge, die ihn backhaben können. Und das ist so ein bisschen bei, wie gesagt, ich möchte kein Bashing betreiben, die haben halt im Prinzip, SSSD hat halt irgendwie so den Anspruch, alle möglichen Features zu implementieren. Also die haben auch eine wirklich beeindruckende Menge von Features. Aber das bedeutet halt auch, sie haben halt auch dementsprechend viele Fehlerquellen. Und ja, es ist auch so, ich habe mal nachgemessen, wie viele Daten eigentlich übertragen werden. Da habe ich ja auch keine Folie dazu gemacht. Und zwar, ich kann hier halt, weil ich die Daten kenne, kann ich einmal viel gezielter suchen, aber ich kann auch die Daten auf eine andere Art und Weise anfragen. Und wenn man das mal hochrechnet auf 15.000 Maschinen, die alle fünf Minuten in Refresh machen, spare ich praktisch pro Tag über 200 Gigabyte Larn-Traffic und über 11 Gigabyte Log-Traffic in den Open-Eld-Ups-Servern bei dem normalen Log-Level. Und das, ja, also deswegen war das so mein Beitrag zum Umweltschutz. Also einmal halt CPU Verbrauch sehr stark reduziert und eben halt auch Larn- und Log-Traffic sehr stark reduziert. Das kommt jetzt immer darauf an, was du unter Einloggen verstehst. Wenn du halt im Prinzip irgendwas mit Authorized Keys machst oder Open-SSR-Zertifikaten, die halt validiert werden können, dann kannst du dich noch anmelden, weil wenn der Server weg ist, dann sind trotzdem praktisch die Map-Daten noch in dem Cache. Ich meine, der Cache im Moment, ich habe mir das im Moment noch gespart, den Cache wirklich auf Platte zu persistieren. Also im Moment mache ich das noch nicht, irgendwie, weil mir wurde auch gesagt von Admins, die sowas benutzen, dass praktisch, wenn das Netzwerk weg ist, machen sie sowieso nichts Sinnvolles auf den System, sondern warten einfach nur bis Netzwerker das repariert haben. Es gibt so ein paar Sonderfälle, wenn man irgendwie auf die Konsole muss, aber auf der Konsole müsste man sich zum Beispiel mit dem Passwort authentifizieren und dann wird es schwierig, weil, naja, der SSD macht Passwortcaching, aber das nutzt dir nichts, weil wenn zum Beispiel Maschinen öfters die Bleut werden von verschiedenen Teammitgliedern, ist dein Passwort noch nicht im Cache. Also hast du auch verloren. Also es gab ja in einem Projekt sehr lange Diskussionen darüber, was passiert eigentlich, wenn die Elder Observer weg sind, irgendwie, und in Wirklichkeit kannst du nicht viel Sinnvolles machen, selbst wenn du alles Mögliche cachesst, weil es muss auch in den Cache reinkommen. Also gerade das Passwortcaching, deswegen habe ich sie auch nicht bewusst nicht implementiert, weil man kann es in der Praxis quasi nicht benutzen. Wir können das gerne diskutieren. Also ich nehme gerne auch andere Meinungen entgegen. Aber man muss sich halt einmal mit Passwort persönlich authentifiziert haben an einem System, damit überhaupt ein Passwortcaching wirksam ist. Ja, aber aus Sicherheitsgründen will ich auf keinen Fall Passwort, zum Beispiel Passwort hashes oder sowas irgendwie lesbar machen. Also das heißt, bei dieser Schnittstelle hier, in der älter Schnittstelle, da kommt keine Passwort hashes raus. Ja, die einzige Entität, die eine Aedie Passwort hashes lesen darf, aus Sicherheitsgründen, sind im Prinzip die Replicken. Weil repliziert werden muss es natürlich, aber das ist die einzige Rolle in einer Aedie, die Passwort hashes lesen darf. Und das ist ein Sicherheitsfeature. Das will ich auch nicht ändern. Ja, der macht genau das. Also du gehst einmal mit einem Erfolg. Also wie macht der SSSD Passwortcaching? Man macht einmal quasi, zum Beispiel, Sudow oder irgendwas, was eine Passwort-Authentifizierung über PEM auslöst. Ja, und dann schreibt er das praktisch lokal in den Cache-Datenbank. Scharf 512 gehäscht mit ein paar Runden bla, bla, bla, keine Ahnung. Ich hab's vergessen, die Details. Aber das heißt natürlich auch wieder, ja, wenn man die, an die Dateien rankommt, dann stehen da halt Passwort hashes drin. Ja, die man dann halt eventuell auch wieder mit HashCat oder so halt Brutforce angreifen kann. Hat immer alles vor und nachteilig. Verfügbarkeit versus Sicherheit versus Bequemlichkeit. So dieses Bermuda-Dreieck. Also ich glaub, das funktioniert ganz gut. Für die Masse der Use Cases funktioniert das ganz gut. Es gibt natürlich Leute, die müssen Netzwerktreiber reinitialisieren, aber die bräuchten dann vielleicht den Notfall-Lock-On für die Konsole. Sonst noch Fragen? Ja, also, dann würde ich jetzt einfach sagen, vielen Dank für eure Aufmerksamkeit und schaut euch einfach eh dir mal an. Also da gibt's auch diverse Videos, wo ich das noch in meinem Detail erkläre. Es gibt auch auf der Webseite inzwischen auch hinreichend viel DOKO. Insbesondere gibt's da auch so ein bisschen, also es gibt auch schon vorkonfigurierte, zum Beispiel Debian-Paketierungs-Files und Spec-Files, zum Beispiel für CentOS, um den AI HostD und seine Frontend-Module. Also insbesondere die Frontend-Module dementsprechend zu kompilieren. Ja, genau. Vielen Dank.