Ich kann nun die Benutzer sehen, der Benutzer „global-binduser“ ist auch da (mit dem habe ich ja das LDAP gerade ausgelesen), aber ein „global-admin“ ist nicht da.
Wer legt den eigentlich an?
Ach ja: Da ist die Rede von diesem Wizard in der Web-GUI, den habe ich auch noch nicht gesehen / gefunden. Wo ist der?
Hi. Jetzt wo du es sagst… ist es nicht so, dass der erste Aufruf als root ausgeführt wird, dabei dann der Setup-Wizzzard abgearbeitet wird und man sich anschließend nur noch als global-admin anmelden soll/kann??
Ich habe das aktuelle walkthrough nocheinmal laufen lassen und nun erlaubt die Web-UI das Einloggen per „global-admin“. „root“ geht auch. Beide sind nicht im LDAP. Ersterer nicht Systembenutzer. Woher holt die Web-UI ihre Nutzer?
Die Änderung am walkthrough waren die Parameter an das linuxmuster-setup. Ich übergebe jetzt alle Parameter, wenn auch leer (zB opsi-ip, das ich nicht nutze). Dubios ist übrigens die Reaktion des Scripts auf die IP-Range, wenn man sie mit „-“ angibt (richtig ist wohl ein Leerzeichen) - das gibt wirklich komische Ergebnisse. Da ich --unattended angebe vermute ich, dass das Script nicht vollständig läuft, wenn nicht alle Parameter in der Kommandozeile gegeben wurden. Kann das sein?
Aha: Die Konfiguration ist in /etc/linuxmuster/webui/config.yml. Da steht tatsächlich LDAP. BindDN ist identisch, nur die SearchDN ist „weiter“, darum habe ich die Nutzer nicht gefunden, die beiden sind nicht in OU=SCHOOLS. „root“ ist allerdings nicht drin, „root“ wird als Sonderfall über den „OSAuthenticationProvider“ authentifiziert.
Oups: Die Fehlermeldung zeigt das Passwort in Klartext an:
Ja, das habe ich auch schon mal angemerkt:
Das Erst-PW befindet sich auf dem Server in der setup.ini und steht da im Klartext. Nicht optimal – um nicht zu sagen „sub-optimal“
Naja, nicht ganz so schlimm. Mein Screenshot zeigt, dass das Passwort (auch ein nicht-erst-passwort) beim Anmelden Klartext angezeigt wird, wenn ein Fehler passiert (zB Netzwerktimeout). Steht jemand neben mir, weil ich für ihn etwas an der Web-UI machen möchte, ist das Passwort damit bekannt. Das ist bei weitem gefährlicher als ein root-only-readable Config-File auf dem Server.
Nein, das tut es so erstmal nicht, ich will die Schritte aber separieren (Netzwerk, Virtualisierung, …), sodaß andere Virtualisierungen genutzt werden können.
Ich habe einfach die schlankeste genutzt, die ich gefunden habe. Da die meisten Virtualisierungen ähnliche Funktionen haben, sollte es kein Problem sein sondern nur Zeitaufwand.
Gegen xcp-ng sprachen für mich folgende Gründe: Es ist yum, also nicht Debian-basiert und benötigt immer noch einen Windows-basierten Client.
Was ist ein „echter“ Client - oder: wie kann ein Client „unecht“ sein?
Ja. Im log von tftp sieht man (wenn man verbose einschaltet) auch den Client zugreifen. Dann kommt ein Linbo-Splash-Screen mit Fehlermeldungen (ich habe auf dem Server tftp gestoppt, darum der Timeout in der 6. Zeile, dann kann man die sehen):
Was /ist/ ein „echter“ Client - oder: wie kann ein Client „unecht“ sein?
ein virtualisierter wäre für mich nicht „echt“ … aber das war
missverständlich ausgedrückt.
Steht „initializing Hardware“ in weiß auf schwarzem HIntergrund?
Ja. Im log von tftp sieht man (wenn man verbose einschaltet) auch den
Client zugreifen. Dann kommt ein Linbo-Splash-Screen mit Fehlermeldungen
(ich habe auf dem Server tftp gestoppt, darum der Timeout in der 6.
Zeile, dann kann man die sehen):
