Fragen zum neuen Anmeldescript für Linuxclients (linuxmuster-linuxclient7)

Ursprünglicher Beitrag:

Hallo, super Sache.
Ich habe direkt eine Rückfrage:
Ist es bei Ubuntu Clients, die bereits mit dem „alten“ adsso-Script aufgenommen wurden, denn nun empfehlenswert, dass man das alte Paket entfernt und dann mit dem neuen Paket weiter macht und die Clients neu aufnimmt?? Oder was ist jetzt best-practice?
Viele Grüße,
Michael

Hallo Michal,

wie schon geschrieben sind die Informationen im Wiki zu finden:

1 Like

Hi, ja das ist ein howto, aber das beantwortet ja meine obige Frage nicht :thinking:
Viele Grüße
Michael

Hi Michael,

Dann ist deine Frage unklar.

VG,
Dorian

1 Like

Na ja – ich frage mich, ob ich bei einem Client, der bereits in der Domäne ist (also genauer gesagt unsere 20.04-Vorlage für die Ubuntu-Clients) und bereits funktioniert nun so vorgehen sollte, dass ich dem zitierten how-to folge und das alte Script entfernen sollte um ihn dann mit dem neuen Script erneut aufzunehmen?! Oder ist das in dem Fall egal und ich lasse alles so wie es ist?!

Es wurde imho nicht eindeutig so formuliert, dass das alte Script nun „deprecated“ ist bzw durch dieses Script abgelöst werden sollte? Falls das aber doch der Fall ist, würde ich unsere Master-Client mit dem neuen Script bestücken …

Ist die Frage jetzt klarer formuliert? :wink:
Viele Grüße,
Michael

Hi Michael,

Ja, jetzt ist es klarer.
Das alte Paket funktioniert schon länger in vielen Fällen micht und bekommt auch schon länger keine Updates mehr. Solanges dein Image funktioniert kannst du es natürlich weiter benutzen. Du wirst aber keinen Support mehr bekommen.
Es ist deine eigene Entscheidung, ob du umstellst oder nicht, die Neuen Funktionen stehen alle im Post von Andreas.

VG, Dorian

1 Like

Hi,
ok, dann werde ich umstellen.
Danke für die Klarstellung.
Viele Grüße — und schön, dass der linux-Client nun wieder gleichziehen kann!
Michael

… ich wollte das gerade direkt umstellen und habe festgestellt, dass in der Doku bisher steht:
Install the package linuxmuster-linuxclient7 (TODO: add repo) – da ist die Doku offenbar noch lückenhaft. Ich habe in meinen sources diesen Eintrag stehen:

/etc/apt/sources.list.d/lmn.list mit dem Inhalt:
deb https://archive.linuxmuster.net/ focal/
(darin befindet sich offenbar das neue Paket → linuxmuster-linuxclient7_1.0.0-rc01_all.deb)
Wenn ich aber apt update ausführe, erhalte ich leider:

W: GPG-Fehler: https://archive.linuxmuster.net focal/ Release: Detached signature file '/var/lib/apt/lists/partial/archive.linuxmuster.net_focal_Release.gpg' is in unsupported binary format
E: Das Depot »https://archive.linuxmuster.net focal/ Release« ist nicht signiert.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).

Wo steckt hier der Fehler?
Danke nochmal,
Michael

Hallo Michael,

Und hier den Trick : Installation Ubuntu 20.04 Client from Scratch - linuxmuster-client-adsso - #4 von schajor

Gruß

Arnaud

2 Like

Hi.
Ich habe es gerade nach Anleitung durchgeführt – also zuerst die Migration und dann das Setup. Am Ende wurde gemeldet, dass der Domain-Join erfolgreich war. Ich habe danach wie gefordert einen Neustart durchgeführt und ein Image geschrieben. Der erste Systemstart sieht jetzt so aus:

Der Login funktioniert also leider nicht. Ideen?
Ach ja: Ein Blick in die Datei cat /var/log/auth.log zeigt dies:

Apr 21 20:36:01 vm-fossa gdm-password]: pam_sss(gdm-password:auth): received for user <mein-login>: 6 (Zugriff verweigert)
Apr 21 20:36:08 vm-fossa realmd[1021]: quitting realmd service after timeout
Apr 21 20:36:08 vm-fossa realmd[1021]: stopping service
Apr 21 20:36:09 vm-fossa gdm-password]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: Datei oder Verzeichnis nicht gefunden
Apr 21 20:36:12 vm-fossa gdm-password]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: Datei oder Verzeichnis nicht gefunden
Apr 21 20:36:12 vm-fossa gdm-password]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=<mein-login>
Apr 21 20:36:12 vm-fossa gdm-password]: pam_sss(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=<mein-login>
Apr 21 20:36:12 vm-fossa gdm-password]: pam_sss(gdm-password:auth): received for user <mein-login>: 6 (Zugriff verweigert)
Apr 21 20:36:16 vm-fossa gdm-password]: pam_unix(gdm-password:auth): Couldn't open /etc/securetty: Datei oder Verzeichnis nicht gefunden

Ist das da ein Typo?? securetty?? Das Verzeichnis /etc/security ist da!

Viele Grüße,
Michael

Hi Michael,

Sende mal bitte den Output von
linuxmuster-linuxclient7 print-logs -c

EDIT: Hmm, obwohl, das schein schon vor dem Login zu hängen, also bei sssd…

Was meldet
linuxmuster-linuxclient7 status

VG, Dorian

1 Like

ich schicke dir das per PM, ok? Kommt sofort…

Ok, wenn wir eine Lösung finden, poste ich es hier

EDIT: Das Problem hat sich „von selbst“ gelöst, also bitte in einem ähnlichen Fall erstmal neustarten und nochmal probieren.

1 Like

[etwas später]
Der Login als User funktionierte nun – ich habe es mit dem Ubuntu 20.04-Client versucht, den Mathias @rettich seinerzeit erstellt und hier über die linuxmuster-Tools zur Verfügung gestellt hatte.

Ich habe mich auf dem Client zunächst als linuxadmin angemeldet – dann nochmal abgemeldet und erneut mit meinem Login angemeldet … das funktioniert nun zwar – dann erschien aber dies:

Screenshot_20210421_211210

Danach sieht es zunächst gut aus! Die Shares sind jetzt da und heißen jetzt genauso wie unter Windows (großartig!!!) – lediglich die Verzeichnisse Bilder, Dokumente usw haben jetzt falsche Rechte:


Darauf kann ich jetzt nicht mehr zugreifen. Das liegt offenbar daran, dass diese Verzeichnisse aus irgendwelchen Gründen alle nach / umgebogen wurden. Mathias: Kannst du nochmal erklären, warum das so gemacht wurde? Müsste man doch ganz einfach wieder zurück nach /home/linuxadmin stellen können, oder?

Übrigens: Das neue Script ist wieder ein großer Wurf! Es ist auf diese Art viel übersichtlicher und auch näher am Windows-Client, da alle Shares überall gleich heißen. Das gefällt mir sehr gut!

Viele Grüße,
Michael

Hi Michael,

Also:
Der erste Screenshot zeigt drei Fehler:

  1. "mount error no such file or directory … " Das bedeutet, dass in der gpo ein share eingetragen ist, das es nicht gibt.
  2. "lpadmin: Unable to query printer … " (2x) Das bedeutet, dass ein Drucker, der in der GPO eingetragen ist, auf dem Cups server nicht gefunden wurde. Hierbei ist wichtig: Der Drucker MUSS in Cups und in der Devices.csv IDENTISCH benannt sein.
    Zum debuggen, um welchen drucker / welches share es sich handelt, hilft der Befehl linuxmuster-linuxclient7 print-logs -c.

Zu deinem zweiten Screenshot:
Lösche die Ordner als Linuxadmin (zur not mit sudo) und erstelle sie neu.
Dann einmal
linuxmuster-linuxclient7 prepare-image
und ein neues Image erstellen.

VG, Dorian

1 Like

Hallo Dorian.
Danke, heute nehme ich mich der Sache nochmal an …

zum 1. Fehler: Wenn ich mich unter Win10 als global-admin verbinde und den Gruppenrichtlinieneditor aufrufe, steht bei mir:


(das gleiche Bild übrigens, wenn ich nicht die lokale GPO sondern die GPO-Verwaltung für die Domain starte. Da muss eine neue Richtlinie her…)

Da ist also offenbar noch gar nichts in Sachen Drucker konfiguriert?! Gibt es da bereits eine Anleitung, wie man CUPS auf dem v7-Server und GPO miteinander verbinden muss?

Der Error-Log zu linuxmuster-linuxclient7 print-logs -c ist ewig lang – aber es werden tatsächlich mehrere Fehler gemeldet. Das schicke ich Dir wieder per PM, ok?

Viele Grüße,
Michael

Du schaust einfach an der falschen Stelle. Die lokalen Gruppenrichtlinien spielen dafür natürlich gar keine Rolle. Es geht hier um die sophomorix GPO welche natürlich auf dem Server konfiguriert ist.
In der Gruppenrichtlinienverwaltung kannst du dir dann die sophomorix:school:default-school anzeigen lassen. Im Punkt Einstellungen siehst du auch was in dieser Konfiguriert ist und kannst dich entsprechend an diese Stelle durch hangeln.

Das soll aber eigentlich nicht das Thema sein. Da stimmen ja die Einträge dann generell nicht zu 100%, das sollte auch unter Windows auffallen :slight_smile:

EDIT: Das Netzlaufwerk wird mit ziemlicher Sicherheit Laufwerk P: für Projekte sein. Hier war wohl seit Jahren ein falscher Pfad eingetragen. Rüdiger hat das AFAIK aber auch schon im letzten sophomorix Paket gefixt, müsste ich mir aber nochmal im Detail anschauen.

Der Pfad wird mit \\server\default-school\projects angelegt sollte aber \\server\default-school\share\projects heißen.

Lässt für mich darauf schließen das niemand Laufwerk P vermisst hat bisher… :slight_smile:

1 Like

Hallo Andreas,
danke - hier nochmal der richtige Screenshot direkt hinterher:

Die Drucker wurden alle automatisch von CUPS gefunden oder sind seit der Migration automatisch da … die Laufwerke stimmen mit Deinen überein.

Hi Michael,

Noch eine kleine Ergänzung zu dem was @Till geschrieben hat:
Hier gibt es eine Anleitung zum Bearbeiten der Sverseitigen GPO:
https://docs.linuxmuster.net/de/latest/systemadministration/gpo/gpo.html

VG, Dorian

1 Like

Mir fiel gerade noch etwas anderes auf: Ich war als User angemeldet – hatte mich dann abgemeldet und bin erneut als linuxadmin rein (um die toten Links von oben zu entfernen). Dabei fiel mir auf, dass mein User-Verzeichnis unter /home/<mein-login>/media/<mein-login> nicht ausgehängt wurde. Der gesamte Inhalt ist weiterhin da…
Die Verzeichnisse ISO (R:) und Projects (P:) sind hingegen leer…