Hi.
Ein paar neue Beobachtungen mit dem bionic-Client:
Anmeldung als User klappt, Firefox fragt Proxy ab aber apt update läuft anschließend nicht
Seltsamerweise versucht apt eine IPv6 Adresse aufzulösen, was dann scheitert!!
Der linuxadmin kommt gar nicht ins Internet. Soll das so bleiben? Können nur User, die sich am Proxy auth. danach ins Netz?
Die Auflösung vom lightdm-Greeter stimmt in meiner VM nicht. Sie ist viel zu hoch. Wenn man angemeldet ist, ist es aber ok.
Ich habe eine Hardwareklasse „Linuxmint“ erzeugt (wir sind noch unentschlossen, ob wir später Ubuntu oder Mint nehmen). Der Prozess der Rechneraufnahme usw hat geklappt. Ich habe auch das linuxmuster-client-adsso-setup installiert und anschließend den Client in die Domäne aufgenommen. Auch das lief fehlerfrei. Den Ordner auf dem Server unter linuxmuster-client/bionic habe ich zu …/mint kopiert, sowie die .postsync-Datei kopiert. Das lief alles glatt; auch der Hostname stimmt dieses Mal. Wenn der Mint-Client startet kann ich aber wieder keinen User anmelden. Die .macct-Datei ist erzeugt und das Image erfolgreich hochgeladen. … da ist weiterhin der Wurm drin … nur wo?
Der linuxadmin kommt gar nicht ins Internet. Soll das so bleiben? Können
nur User, die sich am Proxy auth. danach ins Netz?
das kommt darauf an, wie du das in opnsense und client eingestellt hast:
Variante 1) (default und „das sollte so sein“)
proxy auth ist eingeschaltet (opnsense) und am Cleint ist der Proxy
eingetragen und wird vom Browser verwendet.
Effekt: solange du den Cleint an dem du sitzt nicht in die Alias Gruppe
„noproxy“ rein nimmst, kann der linuxadmin nicht ins Netz.
Das ist keine Frage von „soll das so sein“ sondern: das ist technisch so.
Das ist unter Windows ganz genau so mit dem lokalen admin.
Variante 2)
Die Regel voreingestellte Regel in der opnsense unter
firewall->regeln->LAN die etwa heißt „Internet fürs ganze Netz“ ist
aktiviert: dann darf am Cleint kein Porxy verwendet werden und jeder
kommt ins Netz auch der lokale Admin.
Ich habe Variante 1 und erstelle meine ubuntu Images meist auf dem KVM
Host in einer VM, die eben in der noProxy Alias Gruppe ist.
in der neuen postsync-DAtei musst du auch noch anpassen, dass deine PATCHCLASS=„mint“ heißt und nicht mehr „bionic“. WEnn du das nicht machst, nimmt der postsync des mint-images weiterhin die DAteien aus linuxmuster-client/bionic.
Ich habe, als ich unseren Client erstellt habe, keine einzige Textdatei per Hand angefasst. Wird der hier oft erwähnte postsync automatisch angelegt beim Aufruf von client-adsso ?
Also ich habe den Eintrag in der postsync-Datei nachgeschaut – da stand tatsächlich noch bionic drin. Hab’s geändert, den mint-Client neu gestartet und synchronisiert: Anmeldung weiterhin nicht möglich.
Ubuntu Client gestartet: Und siehe da: Auch hier ist keine Anmeldung mehr möglich (was gestern Abend aber noch ging). Das läuft noch nicht rund…
Noch eine Beobachtung: Der Server hatte UTC Zeit eingestellt. Hieß es nicht, dass die Anmeldung zeitkritisch? Kann das mit verschiedenen Systemzeiten zusammenhängen !?!? Ich habe gerade
dpkg-reconfigure tzdata abgesetzt
… dann aber gesehen, dass LINBO auch UTC Zeit benutzt (also 2 Stunden zurück). Was ist richtig?
Der Ubuntu-Client kann sich wieder anmelden. Da lag es aber vermutlich am Grafikkartentreiber, den ich jetzt auf SPICE geändert habe …
Es sind leider alles nur winzige Beobachtungen … aber vielleicht ist ja die richtige dabei!?
Nachtrag: ich habe auch noch festgestelt, dass linbo-ssh auf den bionic-client nicht mehr läuft: Permission denied (publickey)
wie nimmt man den einen Client in die alias Gruppe auf?
in der opnsense auf Firewall → Alias
und dann in der Zeile „noproxy“ ganz hinten auf den Stift.
Im Fenster beherzt zweimal unten reinklicken und lotippen.
Danach speichern
Das Problem ist bei mir auch aufgetreten, aber es ist erst aufgefallen, nachdem ich schon an relativ vielen stellen Hand angelegt hatte. Ich war deshalb nicht sicher, ob das selbst verschuldet war.
Wir hatten den Splash (über die start.conf? Da wo auch der aedon Treiber ) direkt zu Beginn ausgeschaltet. Ich habe zwar nicht drauf geachtet, hatte aber nicht den Eindruck, dass diese Fehler von Anfang an auftraten. Ich habe gestern angefangen, das ganze System nochmal von Grund auf zu installieren, dann werde ich drauf achten…
Hi.
Kann kein Zufall sein; ich habe am client nicht sooo viel geändert (ein apt dist-upgrade war allerdings dabei) – und ich kann mich seltsamerweise trotz der ganzen Fehler als domänenuser anmelden!
Den anderen Weg hatte ich auch versucht … ich hatte linuxmint genommen und dort das linuxmuster-client-adsso-setup erfolgreich ausgeführt. Anschließend ein Image hochgeladen und drauf geachtet, dass die .macct-Datei am Server angekommen ist. Anmelden konnte ich mich trotzdem nicht. Auch das Löschen der kerberos-Datei unter /etc mit anschließendem neuen adsso hat nichts gebracht. Es bleibt seltsam, dass LINBO als Zeit UTC anzeigt und dass der hostname unter MINT in langer Form da steht, wenn das adsso gelaufen ist aber normal gestartet wird – während der hostname in Kurzform da steht, wenn ich sync-Starte. Das ist beim Ubuntu Client nicht – da steht er bei mir immer in Kurzform!
Was mir auch noch auffiel: In den Firefox-Settings stand im bionic-Client irgendwo bei Proxy eine Domain, die bereits angepasst auf Holgers oder Dominiks Schule war. Auch diese Stelle muss man später manuell ändern…
Ich hoffe im Moment, dass der Cient in dem Zustand, in dem er momentan ist, überhaupt zu retten ist.
(@baumhof ) Holger, hast du diese ganzen FAILED-Meldungen auch (evtl unbemerkt hinter dem ubuntu-Logo)??
Die Anpassungen sind in den Ausnahmen zum Proxy. Ob da Dominiks Schule drin steht ist grad wurscht.
ABer man kann die eigene interne domäne dorthin aufnehmen.
Das ist seltsam. Hast du ein dist-upgrade auf dem Client gemacht? Das lief hier zwischendurch mal, als der client ganz am Anfang noch im roten Netz war (dauer-online).
Ich kann dank ZFS auf einen früheren Snapshot zurück; leider müsste ich jetzt raten, zu welchem Zeitpunkt es noch lief…
Bleibt die Frage, warum @gamma und ich das gleiche Problem haben? Das kann doch kein Zufall sein?!?
Dies ist bei mir übrigens die erste Meldung mit einem Fehler beim Start.
sda3 ist aber da und in der fstab auch als swap eingetragen …
Hm – ich habe die systemctl status < vgl snapshot oben>.service gerade alle überprüft: Die laufen alle. Vielleicht hat die Kiste (Proxmox auf kleinem Server) einfach nicht genug Power, um die Services schnell genug hoch zu ziehen?
Hier aber noch eine Meldung, die meines Wissens so nicht sein darf: Der Client läuft als Local Master Browser?? Das müsste doch der Server und nicht der Client sein???
Des g’hört so, sagt Frau Werwolf.
Nee, im Ernst. Das ist mir auch aufgefallen, aber das liegt nicht an dem einen client: jeder client der hochfährt, fährt auch einen „nmbd“ hoch und dann ist immer der der „local master“ der gerade als letztes in deinem subnetz hochfuhr. Ich habe keine Ahnung, ob das sinnvoll ist. Geschadet hat es noch nicht großartig bei mir.
VG, Tobias
