Anmeldung Linuxclient

Hallo zusammen, wir haben da ein echtes Problem…
Wir haben in Vorbereitung auf das Upgrade auf die V7, das wir im Sommer machen wollen, schon mal unsere Switche angepasst (VLANs nochmal verändert, größere Adressbereiche etc.). Dabei haben wir auch den IP-Bereich geändert - Server war 10.32.1.1. - jetzt 10.16.1.1 (Nicht fragen! War keine gute Idee).
Jedenfalls mussten wir auf unserer bestehenden LMN 6.2 linuxmuster-setup --modify ausführen und sind seither am Nacharbeiten. Das meiste läuft schon wieder, aber wir sind heute den ganzen Tag an einem komischen Problem gehängt - und gescheitert.

Während auf den Nucs im Computerraum alles funktioniert, machen die Notebooks (gleiches Client-Image) Probleme:

Die bekommen beim Booten die richtige IP, können auch das cloop-syncen etc.
Aber die Anmeldung am Client-Ubuntu (16.04) klappt nur mit lokalen usern. Und selbst das geht extrem langsam. Wenn man dann lokal angemeldet ist, kann man aber normal surfen.

Wir haben das Postsync abgesucht und haben nichts Verdächtiges gefunden. :face_with_monocle:
Verwunderlich war, dass die Namenszuordnung am Anfang nicht funktioniert hat. in /etc/hostname stand 3NXDOMAIN. Wir haben dann eine /etc/hosts per postsync nachgeschoben. Seither passt der hostname… aber die Anmeldung eines Schulnetznutzers klappt trotzdem nicht.

Falls sich noch jemand an die 6.2. erinnert :wink:… Hat jemand eine Idee was dahinter stecken kann?

Was mir noch auffiel: Auf die nucs komme ich per linbo-ssh, auf die Notebooks nicht.

Falls jemand einen Ansatz hat - wir wären echt dankbar für Hinweise.
Grüße
Michael

Morgen Michael,

Bin nicht so der LMN-Checker was den ganzen postsync-Kram betrifft, aber wenn Du per linbo-ssh da nicht draufkommst, dann ist da vermutlich kein Public Key vom Server reingepatcht worden. Ich weiss allerdings nicht, wann das gemacht wird.
Wird sich ja aber noch jemand melden, der’s besser weiss.

Gruss Harry

Hallo Michael,

es kann nun also an der Hardware oder am Ort liegen.
Das ist ja einfach: nimm ein Notebook und trag es an die Netzwerkdose
eines NUCs und versuch ihn da.

Wenn die NUCs in einem anderen Subnet sind, dann schieb diese Laptop in
der workstations auch in das andere subnet und versuch es dann.

Ich vermute, dass da auf dem L3 Router falsch ist beim Subnet der
Laptops… oder auf einem nachgeordneten Switch … das ist ja das
schöne am subnetting: es kann so vieles sein :slight_smile:

LG

Holger

Hallo Harry, hallo Holger, vielen Dank für eure Hinweise - leider haben beide nicht zum Erfolg geführt.

Aber zumindest hats meinen Kollegen und mich dazu verleitet genauer in die logs zu schauen und als wir schon fast ins Bett wollten haben wir die Lösung gefunden - ohne sie wirklich zu verstehen…
Vielleicht hier jemand?

Das war echt weird:

Uns ist neben dem beschriebenen Problem mit zunächst fehlendem Hostnamen und der nicht funktionierenden Anmeldung als Netznutzer noch etwas komisch war.
Ohne LAN-Kabel fuhr der Client schnell hoch und die Anmeldung an einem lokalen Profil ging auch schnell.

In der /var/log/syslog konnte man sehen, was die Anmeldung ausbremst:
ca. 15 sekunden mit Meldungen wie dieser:
nscd: nss-ldap: do_open: do_start_tls failed:stat=-1

Wir haben ewig getestet… Der ldap des servers war erreichbar.
Den richtigen Hinweis brachte dann diese Seite:

Scheinbar konfligieren dbus und nscd miteinander. Wir haben dann genau das gemacht, was in dem verlinkten Artikel stand und alles war wieder gut.

So und jetzt: Hä??? Warum tritt das plötzlich auf, nachdem wir unsere Switche überarbeitet haben???
Wenn mir das jemand erklären kann, dann wäre ich nicht nur glücklich (weil’s wieder läuft) sondern auch schlauer (weil erleuchtet).

Grüße
Michael