Hallo,
hätte evtl. jemand einen frisch eingerichteten Linux-Mint-Client zum V7.1 zum Download für mich?
(Oder eine funktionierende(!) Anleitung, wie ich aus einem frisch installierten Mint ein Cloop machen kann…)
Danke!
Gruß
Guido
Hi,
ich habe vor 1/2 Jahr nach dieser Anleitung:
https://docs.linuxmuster.net/de/latest/clients/client_templates/os_installation/linux-clients/index.html
aus KDE Neon ein Cloop gemacht, das hat sehr gut geklappt. Müsste mit Mint (das ja auch auf Ubuntu basiert) genauso gehen.
Falls jemand einen fertigen Client hat, wäre es natürlich einfacher. Viel Erfolg!
Hallo Andreas,
ich hatte versucht nach der von dir verlinkten Anleitung „Linux-Client“ einen Mint21-Client für V7.1 zu erstellen. Leider war ich da nicht erfolgreich. Offenbar gibt es ein Problem mit dem Paket „linuxmuster-linuxclient7“ (v1.0.8-1), was (noch nicht) mit Mint 21 funktioniert.
Wäre daher auch an einem eingerichteten Linux-Mint-Client zum Download interessiert, notfalls sogar Mint 20. 
Viele Grüße
Helmut
Hallo!
Ich hänge mich mal an diesen Thread: auch ich versuche derzeit, meinen Mint21-Client zu erstellen und scheitere derzeit auch an linuxmuster-linuxclient7 (v1.0.8-1). Erste Frage an die Linuxmuster-Gemeinde: hat das überhaupt Aussicht auf Erfolg? Wenn es einen guten Grund gibt, dass das nicht klappt, dann muss ich halt von Mint derzeit Abstand nehmen …
Zu den Details:
Der Domain-Join scheint zu funktionieren. Das Problem geht danach los (ich habe mal etwas versucht im Python-Code zu debuggen, komme aber nicht so richtig weiter). Ich starte linuxmuster-linuxclient7 wie folgt:
sudo linuxmuster-linuxclient7 setup
als User linuxadmin auf dem Host „testmint1“. Das Problem startet im Schritt „Installing server ca certificate …“:
[INFO] It looks like the domain was joined successfully.
[INFO] Installing server ca certificate ...
[DEBUG] Calculating mountpoint of //server.<meinedomain>/sysvol
[WARNING] Uid could not be found! Continuing anyway!
[DEBUG] Trying to mount '//server.<meinedomain>/sysvol' to '/srv/samba/TESTMINT1$/sysvol'
[DEBUG] * Creating directory...
[WARNING] * The target directory already exists, proceeding anyway!
[DEBUG] * Executing '/usr/sbin/mount.cifs -o file_mode=0700,dir_mode=0700,sec=krb5,nodev,nosuid,mfsymlinks,nobrl,vers=3.0,user=TESTMINT1$,domain=<meinedomain> //server.<meinedomain>/sysvol /srv/samba/TESTMINT1$/sysvol'
[DEBUG] * Trying to mount...
[DEBUG] * Success!
[DEBUG] Calculating mountpoint of //server.<meinedomain>/sysvol
[INFO] Copying CA certificate from server to client!
[ERROR] Failed!
[ERROR] === An exception occurred ===
[ERROR] [Errno 13] Permission denied: '/srv/samba/TESTMINT1$/sysvol/<meinedomain>/tls/cacert.pem'
[ERROR] === end exception ===
Was mich etwas wundert: der Share wird mit dem Usernamen (wird im Code als Default-Username gezogen) gleich dem Hostnamen verbunden (mag aber an meiner Unkenntnis liegen). Die Datei „cacert.pem“ befindet sich schon genau dort, darf jedoch vom User TESTMINT1$ nicht gelesen werden.
Hat jemand eine Idee?
Beste Grüße,
Jens
P.S.: Habe jetzt mal - um weitere Erfahrung mit dem Erstellen von Linux Clients in der Zwischenzeit zu sammeln - dasselbe mit einem Ubuntu 22.04.1 LTS probiert: führt zu selber Fehlermeldung. Ist an meinem 7.1-Server irgendwas „krumm“?
Hallo,
ich war nun (mit einem „ugly workaround“) doch erfolgreich: ich weiß nicht, warum „linuxmuster-linuxclient7 setup“ versucht, das cacert.pem gemounted mit dem User TESTMINT1$ zu kopieren. Ich weiß nicht, wie das funktionieren soll (wenngleich das Script (in anderer Umgebung?) ja sicher bei vielen funktioniert hat).
Ich habe mir nun so geholfen, dass ich den User TESTMINT1$ temporär zum „Domain Admin“ in der LMN-Domäne auf dem Server gemacht habe:
samba-tool group addmembers "Domain Admins" TESTMINT1$
Anschließend lief linuxmuster-linuxclient7 erfolgreich durch und ich konnte meinen Workaround zurückrollen:
samba-tool group removemembers "Domain Admins" TESTMINT1$
Nicht schön, hat aber funktioniert.
Sollte jemand Lust und Zeit haben, da mal mit mir drauf zu schauen, was da schief läuft: mein Testsystem steht zur Verfügung.
Beste Grüße,
Jens
Hi Jens,
die Berechtigungen sollten eigentlich standardmäßig so sein, dass die Domain Computers Gruppe zugriff auf die cacert Datei hat. Oder ist dem nicht so? @jeffbeck @Till ?
Müssten wir mal die ACLs sehen und vergleichen. Meiner Meinung nach ja.
Hallo,
nachdem ich eine Abkürzung über einen Ubuntu 20.04-Client mit Mate-Oberfläche eingeschlagen habe, bleibt seine Installation immer an der gleichen Stelle hängen. Das Script ‚linuxmuster-linuxclient7 setup‘ endet am Ende mit:
...
[INFO] #### Joining domain linuxmuster.lan ####
* Resolving: _ldap._tcp.linuxmuster.lan
* Performing LDAP DSE lookup on: 10.16.1.1
* Successfully discovered: linuxmuster.lan
Passwort für global-admin:
* Unconditionally checking packages
* Resolving required packages
* LANG=C /usr/sbin/adcli join --verbose --domain linuxmuster.lan --domain-realm LINUXMUSTER.LAN --domain-controller 10.16.1.1 --login-type user --login-user global-admin --stdin-password
* Using domain name: linuxmuster.lan
* Calculated computer account name from fqdn: WIENEN-TEST01
* Using domain realm: linuxmuster.lan
* Sending NetLogon ping to domain controller: 10.16.1.1
* Received NetLogon info from: v7server.linuxmuster.lan
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-PRmVl5/krb5.d/adcli-krb5-conf-IEqb72
* Authenticated as user: global-admin@LINUXMUSTER.LAN
* Using GSS-SPNEGO for SASL bind
! Couldn't authenticate to active directory: SASL(-1):
generic failure: GSSAPI Error: Unspecified GSS failure. Minor
code may provide more information (Server not found in Kerberos
database)
adcli: couldn't connect to linuxmuster.lan domain: Couldn't
authenticate to active directory: SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information (Server not found in Kerberos database)
! Insufficient permissions to join the domain
realm: Dem Bereich konnte nicht beigetreten werden:
Insufficient permissions to join the domain
[ERROR] Failed! Did you enter the correct password?
============================================
The setup FAILED, see previous errors!
Plase check your configuration and try again.
============================================Ich habe das Passwort mit Sicherheit korrekt eingegeben…
Bevor ich lange suche, würde ich mich über irgendeinen schon eingebundenen Linux-Client freuen, den ich herunterladen und dann anpassen kann.
Gruß
Guido
Das hilft dir garnichts, der Domain join wird auch da nicht funktionieren.
Hast du das Passwort vom global-admin eingegeben?
danke für Eure Hinweise. Ich bin (noch) Samba-Gringo und hab mich jetzt erst mal ein paar Stunden mit Samba ACL’s beschäftigen müssen (gar nicht so leicht, da gute Informationen zu finden - eigentlich hab ich mir alles irgendwo zusammensuchen müssen; im Samba Wiki steht viel, aber wie man die ACE’s lesen muss, hab ich bis jetzt nicht wirklich gefunden - bin für jeden Hinweis dankbar). Wenn im Folgenden was nicht passt, bitte gern korrigieren - wie gesagt: ich stehe da noch am Anfang.
Die ACL für die cacert.pem sieht so aus:
root@server:~# samba-tool ntacl get /var/lib/samba/sysvol/<meinedomain>/tls/cacert.pem
security_descriptor: struct security_descriptor
revision : SECURITY_DESCRIPTOR_REVISION_1 (1)
type : 0x9014 (36884)
0: SEC_DESC_OWNER_DEFAULTED
0: SEC_DESC_GROUP_DEFAULTED
1: SEC_DESC_DACL_PRESENT
0: SEC_DESC_DACL_DEFAULTED
1: SEC_DESC_SACL_PRESENT
0: SEC_DESC_SACL_DEFAULTED
0: SEC_DESC_DACL_TRUSTED
0: SEC_DESC_SERVER_SECURITY
0: SEC_DESC_DACL_AUTO_INHERIT_REQ
0: SEC_DESC_SACL_AUTO_INHERIT_REQ
0: SEC_DESC_DACL_AUTO_INHERITED
0: SEC_DESC_SACL_AUTO_INHERITED
1: SEC_DESC_DACL_PROTECTED
0: SEC_DESC_SACL_PROTECTED
0: SEC_DESC_RM_CONTROL_VALID
1: SEC_DESC_SELF_RELATIVE
owner_sid : *
owner_sid : S-1-5-21-3434558821-1608669798-3106598102-500
group_sid : *
group_sid : S-1-5-32-544
sacl : NULL
dacl : *
dacl: struct security_acl
revision : SECURITY_ACL_REVISION_ADS (4)
size : 0x0060 (96)
num_aces : 0x00000004 (4)
aces: ARRAY(4)
aces: struct security_ace
type : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
flags : 0x03 (3)
1: SEC_ACE_FLAG_OBJECT_INHERIT
1: SEC_ACE_FLAG_CONTAINER_INHERIT
0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
0: SEC_ACE_FLAG_INHERIT_ONLY
0: SEC_ACE_FLAG_INHERITED_ACE
0x03: SEC_ACE_FLAG_VALID_INHERIT (3)
0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
0: SEC_ACE_FLAG_FAILED_ACCESS
size : 0x0018 (24)
access_mask : 0x001f01ff (2032127)
object : union security_ace_object_ctr(case 0)
trustee : S-1-5-32-544
aces: struct security_ace
type : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
flags : 0x03 (3)
1: SEC_ACE_FLAG_OBJECT_INHERIT
1: SEC_ACE_FLAG_CONTAINER_INHERIT
0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
0: SEC_ACE_FLAG_INHERIT_ONLY
0: SEC_ACE_FLAG_INHERITED_ACE
0x03: SEC_ACE_FLAG_VALID_INHERIT (3)
0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
0: SEC_ACE_FLAG_FAILED_ACCESS
size : 0x0018 (24)
access_mask : 0x001200a9 (1179817)
object : union security_ace_object_ctr(case 0)
trustee : S-1-5-32-549
aces: struct security_ace
type : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
flags : 0x03 (3)
1: SEC_ACE_FLAG_OBJECT_INHERIT
1: SEC_ACE_FLAG_CONTAINER_INHERIT
0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
0: SEC_ACE_FLAG_INHERIT_ONLY
0: SEC_ACE_FLAG_INHERITED_ACE
0x03: SEC_ACE_FLAG_VALID_INHERIT (3)
0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
0: SEC_ACE_FLAG_FAILED_ACCESS
size : 0x0014 (20)
access_mask : 0x001f01ff (2032127)
object : union security_ace_object_ctr(case 0)
trustee : S-1-5-18
aces: struct security_ace
type : SEC_ACE_TYPE_ACCESS_ALLOWED (0)
flags : 0x03 (3)
1: SEC_ACE_FLAG_OBJECT_INHERIT
1: SEC_ACE_FLAG_CONTAINER_INHERIT
0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT
0: SEC_ACE_FLAG_INHERIT_ONLY
0: SEC_ACE_FLAG_INHERITED_ACE
0x03: SEC_ACE_FLAG_VALID_INHERIT (3)
0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS
0: SEC_ACE_FLAG_FAILED_ACCESS
size : 0x0014 (20)
access_mask : 0x001200a9 (1179817)
object : union security_ace_object_ctr(case 0)
trustee : S-1-5-11
Dabei lösen sich die berechtigten SID’s so auf:
- S-1-5-32-544: BUILTIN\Administrators
- S-1-5-32-549: BUILTIN\Server Operators
- S-1-5-18: NT AUTHORITY\SYSTEM
- S-1-5-11: NT AUTHORITY\Authenticated Users
Zur letzten Gruppe sollte dann ja der Computer-User TESTMINT1$ gehören. Dessen Credentials kenne ich aber nicht, so dass ich es nicht ausprobieren kann. Verbinde ich aber den SYSVOL-Share von einem anderen Rechner mit einem „natürlichen User“, kann ich auf die Datei zugreifen.
Weiter bin ich jetzt noch nicht gekommen … habt ihr noch eine Idee, warum es nicht funktioniert haben könnte?
Jens
Hallo Jens,
nicht dass ich mcih da auskennen würde: ich hab nur einen Gedanken dazu:
Zur letzten Gruppe sollte dann ja der Computer-User TESTMINT1$ gehören.
Dessen Credentials kenne ich aber nicht, so dass ich es nicht
ausprobieren kann.
das ist ein Computerkonto: deswegen auch der Dollar hintendran.
Die Credentials stehen im AD und werden bei der Rechneraufnahme in die
AD ausgetauscht: danach ist der Rechner drin.
Wenn er in der Domäne ist, dann ist er „Angemeldet“: da mußt du also nix
weiter machen.
Ist er in der Gruppe und kommt trotzdem nicht an das Share, dann ist
noch was an der Domänenaufnahme schräg (würde ich sagen).
Im Moment der Domänenaufnahme mountet aber eigentlich der global-admin
die Shares…
LG
Holger
Hallo Holger,
in meinem Post oben sieht man ja, dass der Share mit dem Computerkonto gemounted wird:
[DEBUG] * Executing '/usr/sbin/mount.cifs -o file_mode=0700,dir_mode=0700,sec=krb5,nodev,nosuid,mfsymlinks,nobrl,vers=3.0,user=TESTMINT1$,domain=<meinedomain> //server.<meinedomain>/sysvol /srv/samba/TESTMINT1$/sysvol'
Die Frage ist: warum? Soll das so sein? Die Credentials vom global-admin wären ja nach Eingabe des Passwortes durchaus vorhanden …
Beste Grüße,
Jens
Hallo Jens,
[DEBUG] * Executing ‚/usr/sbin/mount.cifs -o
file_mode=0700,dir_mode=0700,sec=krb5,nodev,nosuid,mfsymlinks,nobrl,vers=3.0,user=TESTMINT1$,domain= //server./sysvol /srv/samba/TESTMINT1$/sysvol‘ |Die Frage ist: warum? Soll das so sein?
weiß ich nciht.
Anscheinend sind die Credentials in der /etc/krb5 nicht korrekt.
Gibt es die Datei?
Wann wurde sie erstellt?
Versuch doch nochmal die Domänenaufnahme, aber lösch die Datei vorher
und die da ebenfalls liegende .conf)
LG
Holger
Nein, das macht der Computeraccount. Der global-admin wird nur verwendet, um das Passwortd vom Computeraccount zu setzen.
VG,
Dorian
Hallo zusammen,
ich habe jetzt mein LMN7.1-Testsystem (die server-VM) neu aufgesetzt, um Abhängigkeiten zu meinem Samba-Startup-Problem auszuschließen. Außerdem habe ich noch als Übernahme aus diesem Thread vor linuxmuster-linuxclient7 setup die libsss-sudo nachinstalliert.
In diesem Setup lief jetzt linuxmuster-linuxclient7 setupohne Probleme am Stück durch … ich vermute, es war die fehlende libsss-sudo. Wenn dieser Punkt bei Gelegenheit ins Script einfließen könnte, wäre das Problem vermutlich erledigt. Ich erlaube mir mal, ein Github-Issue dazu zu erstellen. Ich hoffe, das passt so …
Schönen Sonntagnachmittag!
Jens
2 „Gefällt mir“
Hallo Jens,
In diesem Setup lief jetzt |linuxmuster-linuxclient7 setup|ohne Probleme
am Stück durch … ich vermute, es war die fehlende |libsss-sudo|. Wenn
dieser Punkt bei Gelegenheit ins Script einfließen könnte, wäre das
Problem vermutlich erledigt. Ich erlaube mir mal, ein Github-Issue dazu
zu erstellen. Ich hoffe, das passt so …
Super: Danke 
LG
Holger
Hi,
ich habe nicht nur das Passwort vom global-admin eingegeben, ich habe es auch mit neuen Passwörtern für den global-admin versucht.
Auch das Paket libsss-sudo habe ich überprüft, es war jedoch schon installiert.
Wenn ich heute keinen Erfolg verzeichnen kann, würde ich es morgen über die Hotline versuchen, sollte diese verfügbar sein…
Gruß
Guido
Nachtrag:
Hier das Ergebnis der AD-Abfrage:
linuxadmin@wienen-test01:~$ adcli info linuxmuster.lan
[domain]
domain-name = linuxmuster.lan
domain-short = LINUXMUSTER
domain-forest = linuxmuster.lan
domain-controller = v7server.linuxmuster.lan
domain-controller-site = Default-First-Site-Name
domain-controller-flags = pdc gc ldap ds kdc timeserv closest writable good-timeserv full-secret
domain-controller-usable = yes
domain-controllers = v7server.linuxmuster.lan server.linuxmuster.lan
[computer]
computer-site = Default-First-Site-Name
Und hier die Abfrage am Server bezüglich des global-admin:
root@v7server:~# klist
Ticketzwischenspeicher: FILE:/tmp/krb5cc_0
Standard-Principal: global-admin@LINUXMUSTER.LAN
Valid starting Expires Service principal
10.10.2022 10:16:28 10.10.2022 20:16:28 krbtgt/LINUXMUSTER.LAN@LINUXMUSTER.LAN
erneuern bis 11.10.2022 10:16:23
Ich könnte mir vorstellen, dass der Hostname v7server, satt server ist. Ich bin mir nicht sicher, ob das so unterstützt wird.
@Till @jeffbeck kann man das machen?
Auch noch auffällig ist, dass server.linuxmuster.lan als zweiter AD Controller gefunden wird. Ich hab das Gefühl, dass da was größeres mit eurem Setup „vermurkst“ ist…
Hallo,
evtl. sollte man darauf hinweisen, dass man den Server niemals anders nennen darf, als Server…
Danke für die Lösung!
Gruß
Guido