Hier nochmal etwas strukturierter:
die Datei /etc/resolv.conf ist ein Link, der auf
/run/systemd/resolve/stub-resolv.conf
verweist.
In dieser stub-Datei steht ein falscher Nameserver drin (127.0.0.53).
In dem gleichen Verzeichnis ist aber auch eine Datei resolv.conf
Diese enthält unseren Schulserver als Nameserver.
Das habe ich jetzt von einem Client, an dem ich noch nicht rumgefummelt habe, das war also ein Client, der vor 2 Wochen noch funtkioniert hatte.
Irgendwo muss der nameservereintrag ja herkommen, das muss irgend ein Linuxmuster-Skript machen, und irgendetwas sorgt dafür, dass es jetzt nicht mehr geht.
Nein, diese Konfiguration ist für mich vollkommen richtig.
Ich würde mit den DNS unter Ubuntu spielen, es ist nicht mehr so einfach wie /etc/resolv.conf editieren. Insbesondere ist es explizit geschrieben, dass die Datei von systemd verwaltet ist.
Ich habe den gleichen Eintrag bei mir, und die Anmeldung funktioniert problemlos. Einzige Unterschied zwischen uns beide ist folgende :
options edns0 trust-ad
Ich weiß ehrlich nicht, ob es wichtig für den KDC ist.
Ich glaube lieber, dass das Update auf Ubuntu den DNS neu konfiguriert hat, und damit hast du deine eigene Konfiguration verloren.
Geht ein kinit als Lehrer der nicht im Cache ist ?
Das Problem tritt auch an clients auf, an denen ich das Update noch nicht eingespielt habe.
Wie „spiele“ ich denn mit dem DNS? Ich habe jetzt erst mal den resolv-conf-systemd-service abgeschaltet, anschließend modifizierte mir networkmanager die resolv.conf, das habe ich jetzt auch noch abegeschaltet, jetzt muss ich schauen.
OK, client ist neu gestartet:
resolv.conf manuell gesetzt
kinit für Lehrer der nicht im cache ist GEHT jetzt sofort
Hallo Andreas.
Ich denke weiterhin, dass du ein änliches Problem hast wie ich hier … kannst du mal als User das Anmeldescript manuell ausführen?
Also cd /etc/linuxmuster-client/scripts und dort dann: login.sh
Wird da etwas gemeldet? Vor allem etwas in Sachen CIFS?
Versuche es mal so – zunächst als linuxadmin anmelden und dann in einer Konsole su <lehrername> -s /bin/bash
Vielleicht kannst du einen User/Lehrer über diesen Weg anmelden?!
Nein, es sollte auch kein Home_auf_Server Ordner im Heimatverzeichnis von linuxadmin geben, ansonstens führt es zu Probleme, deswegen fragt Rainer.
In /etc/security/pam_mount.conf.xml.
Aber an deiner Stelle würde ich erst mal die Logs von /var/log/syslog überprüfen. Das gibt es bestimmt Fehlermeldungen bei der Anmeldung.
Hi.
Ich hatte oben doch schon mal auf den anderen Threads verwiesen. Ich meine, dass es an dem minimalen Protokoll liegen kann, das Samba erlaubt. Seit dem wanna-cry-Bug wurde das alte smb.v1 verbannt und nur noch höhere Protokolle zugelassen. Ich meine aber, dass bei dem mount Befehl versucht wird, smb.v1 zu verwenden…
Ich denke, dass die Optionen des mount-Befehls ein Problem haben … du kannst natürlich testweise mal auf dem Server das alte SMB.v1 wieder erlauben und schauen, ob es dann wieder geht …
Ich hatte ja testweise auf dem Client die version auf 3.0 hochgesetzt - muss man da nochwas dran ändern? Hat bei mir jedenfalls nicht geklappt, oder ich habe was falsch gemacht.
Das sieht mir ganz und gar nicht richtig aus, wir haben ja kein 192er Netz.
du hast einen zweiten DHCP im Netz …
Bei mir hat mal ein Switch nach Stromausfällen seine VLAN config
vergessenund war dann wieder „flach“, was dazu führte, dass ROT und GRÜN
gemischt waren: also der DHCP der Fritzbox ins Grüne Netz
„reingestrahlt“ hat.
Such mal nach dem falschen DHCP.
Das erklärt auch, weswegen die Anmeldung, die sonst immer ging, nicht
mehr geht.
und wundere dich nicht: linbo bekommt immer die IP vom richtigen DHCP
… war bei mir auch so … warum weiß ich nciht.
Fehler -13 und „less secure“-Meldung wegen v1.0 habe ich auch, daran liegt nicht das Loginproblem. Ein zweiten DHCP-Server könnte auf jedem Fall ein Problem sein, habe ich daran gedacht.
Dank an Euch alle. Diese geheimnisvolle 192.168.148.101 lässt sich auch pingen, da ist was, was da nicht hingehört.
Ich habe meinen Kollegen + Netzwerkexperten gegeben, das anzuschauen, und einsteweilen einen Not-Client mit lokaler ANmeldung gezimmert.
Der Tag war zwar extrem frustrierend, aber über Fernwartung mit linbo-remote und vnc habe ich sehr viel gelernt.
Hallo Andreas!
Auf den Switches kann man normalerweise auslesen welche MAC-Adresse über welchen Port verbunden ist.
Die MAC-Adresse findest du vermutlich über # arp -a
So kann man sich über die Uplink-Ports zum zugehörigen Switch hangeln und dort den Port auslesen.
Dann weißt du an welchem Port der Rechner zu finden ist.
Viel Erfolg!
Gruß - Rainer
Es geht wieder. Ich habe das Posting von @Arnaud auf „Lösung“ gesetzt, weil über KRB5_TRACE diese geheimnisvolle IP-Adresse gefunden wurde, die Ursache des Problems war.
Diese IP ist kein wilder DHCP Server oder ein unartiger Switch, sondern unser Server selbst, der über eine zweite Netzwerkkarte (alles virtuell innerhalb Proxmox) noch in einem anderen Netz hängt, über das wir unsere Backups machen. Beim letzten Proxmox-Update sind diese Netzwerkkarten irgendwie durcheinandergeraten, sodass der Server sich mit dieser IP im 10er Netz meldete. Das hat die meisten Dienste nicht gestört, Kerberos aber schon.
Letztlich war das also gar kein Linuxmuster-Problem. Um so toller finde ich es, wie viel Hilfe ich hier bekommen habe, die letztlich zum Erfolg führte.