Linuxclient - manuelle Installation

Axel · 18. Oktober 2018 um 14:35

Hallo Helge,
die beiden Pakete libnss-ldapd und libpam-ldapd habe ich installiert, wie du vorgeschlagen hast.
Das Ergebnis ist aber leider dasselbe, weder Lehrer noch Schüler können sich anmelden.
LG
Axel

baumhof · 18. Oktober 2018 um 14:51

Hallo Axel,

hier ist die hosts-Datei vom Client:

127.0.0.1 localhost
127.0.1.1 SCENIC-E

#The following lines are desirable for IPv6 capable hosts ::1
ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

die muss durch einen postsync gepatched werden, damit die
Namensauflösung richtig funktioniert.

Bei mir wird diese Datei per postsync auf den CLient geschoben:

# Diese Datei wird per postsync gepatcht. Zu bearbeiten ist sie auf dem
Server.
# Pfad: /var/linbo/linuxmuster-client/trusty/common/etc/hosts
# HOSTNAME wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1    HOSTNAME

#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server
eingetragen sind...
#SERVERIP server.linuxmuster.local server
# damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
#SERVERIP  server.lokal server.local

Dabei sind HOSTNAME und #SERVERIP Variablen die das postsyncscript kennt
(Vorsicht: einmal mit # und einmal ohne… ich weiß: nicht super, aber is
halt so …)

LG

Holger

Cgsman · 21. Oktober 2018 um 21:45

Hallo, Axel,

um die Authentifizierungs-Probleme zu diagnostizieren, musst Du das zugehörige Script einmal von hand laufen lassen und hier die Ergebnisse posten.
Wenn Du die Pakete aus linuxmuster-client-auth korrekt installiert hast, müsstest Du als superuser auf dem client, der sich nicht authentifizieren will - vorausgesetzt, der Server lässt sich generell erreichen (ping [server-ip]) - folgenden Befehl absetzen:

/usr/sbin/linuxmuster-client-auth-ldap-autoconfiguration

Dann müsste das Folgende (so ähnlich) erscheinen:

Autoconfiguring LDAP auth...
  Client IP is: <10.32.101.1>
  Client hostname is: <DEIN_CLIENT-NAME>
  Server IP is: <10.32.1.1>
  Server name is: <server.linuxmuster-net.lokal>
  Server host name is: <server>
  BaseDN is: <dc=linuxmuster-net,dc=lokal>
Configuring LDAP client to server 10.32.1.1, base dc=linuxmuster-net,dc=lokal...  done.
Autoconfiguring PAM_MOUNT...
  Client IP is: <10.32.101.1>
  Client hostname is: <SIEHE_OBEN>
  Server IP is: <10.32.1.1>
  Server name is: <server.linuxmuster-net.lokal>
  Server host name is: <server>
  BaseDN is: <dc=linuxmuster-net,dc=lokal>
Configuring pam_mount to serverIP 10.32.1.1...  done.

Was kommt da bei Dir ?

L.G.
Christoph

Axel · 23. Oktober 2018 um 08:31

Hallo Christoph,
die Ausgabe des Befehls

usr/sbin/linuxmuster-client-auth-ldap-autoconfiguration

ist bei mir fast identisch mit deiner (nur die IP-Adressen sind natürlich andere).
Ich bin gerade am Suchen, ob es mit dem Postsyncscript zusammenhängt, wie Holger meinte.
Aber danke für die Anregung - schon wieder etwas gelernt.
LG
Axel

Cgsman · 23. Oktober 2018 um 09:18

Hallo, Axel,

die gute nachricht: Die/var/log/auth-log-Zeilen mit der Meckerei über “faulty modules” kannst Du ignorieren, die haben viele Ubuntu-Benutzer (unabhängig von der Linuxmuster).

Ernster ist die ldap-Warnung - aber vielleicht auch nicht so wichtig.
Bitte logge Dich als linuxadmin ein und gib danach folgendes ein:

cat /var/log/auth.log|grep nss_ldap

Jetzt müsste so etwas kommen (zuerst die Meckerei, dann die Entwarnung weiter untern):
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: could not search LDAP server - Server is unavailable
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: reconnecting to LDAP server…
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: could not search LDAP server - Server is unavailable
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: reconnecting to LDAP server…
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…
Oct 22 01:31:25 win10pc01 dbus-daemon: nss_ldap: could not search LDAP server - Server is unavailable
Oct 22 01:31:25 win10pc01 nscd: nss_ldap: reconnecting to LDAP server…
Oct 22 01:31:25 win10pc01 nscd: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…
Oct 21 23:31:27 win10pc01 nscd: nss_ldap: reconnected to LDAP server ldap://10.32.1.1/ after 2 attempts
…
Oct 23 11:13:40 win10pc01 nscd: nss_ldap: could not search LDAP server - Server is unavailable**
Oct 23 11:13:40 win10pc01 nscd: nss_ldap: reconnecting to LDAP server…**
Oct 23 11:13:40 win10pc01 nscd: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…**
…

Oct 23 11:13:41 win10pc01 nscd: nss_ldap: reconnected to LDAP server ldap://10.32.1.1/ after 2 attempts

Ist das der Fall ?

Wenn nein, dann klär zur Sicherheit ab, ob Du alle LDAP-Pakete hast:

dpkg -l | grep ldap

ii  ldap-auth-client                            0.5.3                                        all          meta-package for LDAP authentication
ii  ldap-auth-config                            0.5.3                                        all          Config package for LDAP authentication
ii  libldap-2.4-2:amd64                         2.4.42+dfsg-2ubuntu3.2                       amd64        OpenLDAP libraries
ii  libnss-ldap:amd64                           265-3ubuntu2                                 amd64        NSS module for using LDAP as a naming service
ii  libpam-ldap:amd64                           184-8.7ubuntu1                               amd64        Pluggable Authentication Module for LDAP

gruß Christoph

Axel · 25. Oktober 2018 um 09:25

Hallo Holger,
bei mir liegt das Verzeichnis “common” (mit seinen Unterverzeichnissen) direkt unter /var/linbo/linuxmuster-client/. Es existiert kein Unterverzeichnis für das Image.
Der Name meines Images ist “mate-sw2.cloop”. Also müsste doch ein Verzeichnis “/var/linbo/linuxmuster-client/mate-sw2/common” existieren oder habe ich das falsch verstanden?
Die linuxmuster-client-servertools habe ich zu Beginn meiner Experimente installiert, vielleicht ist deshalb die Verzeichnisstruktur falsch. Ist es sinnvoll (sofern diese Vermutungen zutreffen) die servertools zu deinstallieren (apt purge) und nochmals neu zu installieren, oder die Verzeichnisse gleich von Hand anzulegen und die vorhandenen Dateien reinzukopieren.
Danke für die Unterstützung.
LG Axel

baumhof · 25. Oktober 2018 um 09:59

Hallo Alex,

bei mir liegt das Verzeichnis “common” (mit seinen Unterverzeichnissen)
direkt unter /var/linbo/linuxmuster-client/. Es existiert kein
Unterverzeichnis für das Image.
Der Name meines Images ist “mate-sw2.cloop”. Also müsste doch ein
Verzeichnis “/var/linbo/linuxmuster-client/mate-sw2/common” existieren
oder habe ich das falsch verstanden?
Die linuxmuster-client-servertools habe ich zu Beginn meiner Experimente
installiert, vielleicht ist deshalb die Verzeichnisstruktur falsch. Ist
es sinnvoll (sofern diese Vermutungen zutreffen) die servertools zu
deinstallieren (apt purge) und nochmals neu zu installieren, oder die
Verzeichnisse gleich von Hand anzulegen und die vorhandenen Dateien
reinzukopieren.

das bringt nichts, weil die linuxmuster-cleintservertools diese
Verzeichnisse nicht anlegen (sie können ja nicht wissen, wie du deine
Images im postsync nennst).

Du mußt nun so vorgehen:

organisier dir die universelle postsyncdatei und leg sie als diese
Datei ab:
/var/linbo/mate-sw2.cloop.postsync
in der postsync Datei steht ganz oben die „Patchklasse“ und hier wird
definiert, wie das Unterverzeichnis in /var/linbo/linuxmuster-client/
heißen muss: das hat also mit dem Imagenamen nichts zu tun!

Bei mir steht im postsync:
PATCHCLASS= „trusty“

Also liegen meine Patches „für alle“ dieser Klasse in
/var/linbo/linuxmuster-client/trusty/common/

Es gibt aber auch noch
/var/linbo/linuxmuster-client/trusty/r155/
in dem die Patches liegen, die nur auf Cleints in Raum 155 angewendet
werden (Vorsicht, der Raum wird aus dem Rechnernamen generiert: die
Rechner müssen also r155-pcXY heißen und nicht r155pcXY).

Bleiben wir aber bei:
/var/linbo/linuxmuster-client/trusty/common/
das ist das Basisverzeichnis auf dem Cleint.
Wenn ichhier ein Verzeichnis etc drin alege, dann landen Dateien die da
drin liegen im Verzeichnis /etc/ auf dem Cleint.

Bei mir liegt also eine hosts Datei auf dem Server in
/var/linbo/linuxmuster-client/trusty/common/etc/hosts

Mein postsync ist (der ist aber schon alt … da gibt es vielleicht
bessere inzwischen)

    echo "##### trusty-linuxmuster POSTSYNC BEGIN #####"

    # IP-Adresse des Server
    SERVERIP=10.16.1.1
    STARTCONF=/cache/start.conf

    # Raum feststellen. Dieses Skript geht davon aus
    # dass die Rechner Namen der Form
    # raumname-hostname haben, also z.B. cr01-pc18
    RAUM=${HOSTNAME%-*}
    # wenn der string leer ist, raum auf unknown setzen
    if [ "x${RAUM}" == "x" ]; then
        RAUM="unknown"
    fi

    # Das Verzeichnis, in dem die Serverpatches
    # local synchronisiert werden.
    PATCHCACHE=/linuxmuster-client/serverpatches
    # UVZ auf dem Server. Mit diesem Variablen kann
    # man verschiedene Images bedienen (was bei linux
    # selten nötig ist)
    PATCHCLASS="trusty"

    echo ""
    echo "Hostname:      ${HOSTNAME}"
    echo "Raum:          ${RAUM}"
    echo "Patchcache:    ${PATCHCACHE}"
    echo "Patchclass:    ${PATCHCLASS}"
    echo ""
    if [ ! -d /cache/${PATCHCACHE}/${PATCHCLASS} ]; then
      echo "Patchklasse ist nicht vorhanden."
      echo "Auf dem Server mit mkdir -p
/var/linbo/linuxmuster-client/${PATCHCLASS}/common/ das Grundverzeichnis
anlegen und dort die gepatchten Dateien ablegen."
    fi

    # -----------------------------------------
    # Patchdateien auf das lokale Image rsyncen
    # -----------------------------------------
    echo " - getting patchfiles"

    # RAUM     -> Raumname
    # HOSTNAME -> Rechnername
    # Verzeichnis anlegen, damit es sicher existiert
    mkdir -p /cache/${PATCHCACHE}
    rsync --progress -r
"${SERVERIP}::linbo/linuxmuster-client/${PATCHCLASS}" "/cache/${PATCHCACHE}"

    echo " - patching local files"
    # zuerst alles in common
    if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/common ]; then
        cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/common/* /mnt/
    fi

    # dann raumspezifisch
    if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM} ]; then
        cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/${RAUM}/* /mnt/
    fi

    # dann rechnerspezifisch
    if [ -d /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME} ]; then
        cp -ar /cache/${PATCHCACHE}/${PATCHCLASS}/${HOSTNAME}/* /mnt/
    fi

    # -----------------------------------
    # Berechtigungen anpassen, wenn nötig
    # -----------------------------------
    echo " - setting permissions of patched local files"

    # printers.conf
#    [ -f /mnt/etc/cups/printers.conf ] && chmod 600
/mnt/etc/cups/printers.conf
    rm /mnt/etc/cups/printers.conf*

    # .ssh verzeichnis
    chmod 700 /mnt/root/.ssh/
    chmod 600 /mnt/root/.ssh/authorized_keys
    # die Kamera in der Physik ueberfuellt die Datei:also nicht
schreibbar setzen
    chmod 444 /mnt/var/log/uvcdynctrl-udev.log
#    chown -R 1000:1000 /mnt/home/linuxadmin/.mozilla
    chown -R 1000:1000 /mnt/home/linuxadmin/

    # hostname in /etc/hosts patchen
    sed -i "s/HOSTNAME/$HOSTNAME/g" /mnt/etc/hosts
    sed -i "s/#SERVERIP/$SERVERIP/g" /mnt/etc/hosts

    # fstab anpassen, damit Swap-Partition stimmt
    echo "---- hier beginnen wir mit dem debuggen:"
    SWAPZEILENNR=$(grep -i "^fstype" $STARTCONF | cut -d"#" -f1 | grep
-n -i "swap" | cut -d":" -f1)
    echo Swapzeilennummer: $SWAPZEILENNR
    SWAP=$(grep -i "^dev" -m $SWAPZEILENNR $STARTCONF | tail -n1 | cut
-d"=" -f2 | tr -d [:blank:]|head -c9)
    echo Swap: $SWAP
    sed -i "s|#dummyswap|$SWAP|g" /mnt/etc/fstab

    echo "##### trusty-linuxmuster POSTSYNC END #####"

und meine dazu passende hosts Datei ist.

# Diese Datei wird per postsync gepatcht. Zu bearbeiten ist sie auf dem
Server.
# Pfad: /var/linbo/linuxmuster-client/trusty/common/etc/hosts
# HOSTNAME wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1    HOSTNAME

#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server
eingetragen sind...
#SERVERIP server.linuxmuster.local server
# damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
#SERVERIP  server.lokal server.local

Ich weiß: das klingt erstmal tierisch kompliziert: es muss aber so sein:
dass die Patchklasse unabhängig vom Image ist.
So kann ich nämlich auch zwei Images mit dem selben postsync beschicken.

Der postsync ist komplex, aber er kann verdammt viel.
Ich habe z.B. im Seminar jetzt 2 Räume mit nvme SSDs drin, die anderen
haben normale SSDs drin.
Das Problem ist, dass die dann Pfade in der fstab brauchen die eben
nicht /dev/sda3 für Swap und /dev/sda5 für virtual haben, sondern
/dev/nvme0n1p3 für swap und /dev/nvme0n1p5 für /virtual.
Sie sollen aber mit dem gleichen Image bespielt werden (wer will schon
zwei Images).
Die rootpartition ist wurscht: das macht linbo beim booten des Kernels
(die rootpartition übergeben).
Aber dann meckert ubuntu beim booten, weil es swap und virtual nicht findet.
Also hab ich für die beiden Räume eine andere fstab unter
/var/linbo/linuxmuster-client/trusyty/r003/etc/
und
/var/linbo/linuxmuster-client/trusyty/r004/etc/
Fertig: ein Image für alle

… Windows ist da ein ganz anderes Ding: das bekommt man garnicht hin,
dass das von SSD und von NVME bootet… Da hab ich jetzt also ein Image
mehr…

LG

Holger

Axel · 1. November 2018 um 13:45

Hallo Holger,

vielen Dank zuerst für deine ausführliche Anleitung.

Ich habe die generic.postsync nach /var/linbo/mate-sw2.cloop.postsync kopiert und PATCHCLASS=“mate32“ eingetragen.

Im Verzeichnis /var/linbo/linuxmuster-client/mate32/common/etc liegt nun folgende hosts-Datei:

# Diese Datei wird per postsync gepatcht. Zu bearbeiten ist sie auf dem Server.&quot;
# Pfad: ${linbodir}/${universalpostsyncdir}/${patchclass}/${HOSTS}
# HOSTNAME wird im Postsyncskript mit dem echten Namen gepatcht
127.0.0.1 HOSTNAME
#Die nächste Zeile enthält die Hostnamen so, wie sie auf dem Server eingetragen sind...
#SERVERIP server.linuxmuster-net.lokal server
# damit CUPS zufrieden ist, muss noch diese Zeile hier dazu:
#SERVERIP server.lokal server.local

Der Postsync wird aber anscheinend gar nicht ausgeführt. Die hosts-Datei auf dem Client ist nach wie vor dieselbe wie am 19.10. gepostet und die Anmeldung funktioniert nicht.

Linbo_wrapper sync:2 liefert folgendes Ergebnis:

Befehl: sync
Parameter: 2
Syncing Mate…
10.16.1.1
/dev/sda6
syncr 1: >>10.16.1.1<< 2:  >>/dev/sda6<< 3:  >>mate-sw2.cloop<< 4:  >><< 5:  >>/dev/sda2<<
6:  >>/dev/sda2<< 7:  >>vmlinuz<< 8:  >>initrd.img<< 9:  >>ro splash<<
RSYNC Download 10.16.1.1 → mate-sw2.cloop.torrent….
Starte Torrent-Dienst für mate-sw2.cloop.
Keine neuere Version vorhanden, ueberspringe mate-sw2.cloop.
Veranlasse Upload von image.log.
update 1: >>10.16.1.1<< 2: >>/dev/sda6<<
LINBO-Update wurde schon ausgeführt!
syncl 1: >>/dev/sda6<< 2: >>mate-sw2.cloop<< 3:  >><< 4:  >>/dev/sda2<<
5: >>/dev/sda2<< 6: >>vmlinuz<< 7: >>initrd.img<< 8: >>ro splash<<
Entpacke: mate-sw2.cloop → /dev/sda2 [Datei-Sync]….
## Wed Oct 31 17:31:15 UTC 2018 : Starte Synchronisation von mate-sw2.cloop.
……………...Beende Synchronisation von mate-sw2.cloop.
Fertig.
BIOS-System gefunden.
Setzte Hostname → r5-pc20.
patch_fstab 1: >>/dev/sda2<<
Setze Rootpartition: >>/dev/sda2<<
Veranlasse Upload von image.log.

Ich dreh mich wahrscheinlich im Kreis und seh den Wald vor lauter Bäumen nicht. Hast du eine Idee wo ich noch suchen kann?

Gruß Axel

Axel · 1. November 2018 um 14:21

Hallo Christoph,
die LDAP-Pakete, die du aufgelistet hast sind bei mir auch installiert, wenn auch zum Teil in einer älteren Version.
In der auth.log steht bei mir:

Oct 31 18:57:05 r5-pc20 dbus-daemon: nss_ldap: could not search LDAP server - Server is unavailable
…
Oct 31 18:57:10 r5-pc20 accounts-daemon: nss_ldap: could not search LDAP server - Server is unavailable
…
Oct 31 18:57:12 r5-pc20 nscd: nss_ldap: reconnected to LDAP server ldap://10.16.1.1/ after 2 attempts

Es scheint nur die letzte Verbindung zustande zu kommen. Eine Anmeldung als Lehrer/Schüler funktioniert nicht:

Oct 31 18:57:24 r5-pc20 systemd-logind[782]: New session c2 of user „xyz“
Oct 31 18:57:24 r5-pc20 systemd: pam_unix(systemd-user:session): session opened for user „xyz“ by (uid=0)
Oct 31 18:57:25 r5-pc20 lightdm: (mount.c:72): Messages from underlying mount program:
Oct 31 18:57:25 r5-pc20 lightdm: (mount.c:76): mount error(112): Host is down
Oct 31 18:57:25 r5-pc20 lightdm: (mount.c:76): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Oct 31 18:57:25 r5-pc20 lightdm: (pam_mount.c:522): mount of „xyz“ failed
Oct 31 18:57:25 r5-pc20 lightdm: (mount.c:72): Messages from underlying mount program:
Oct 31 18:57:25 r5-pc20 lightdm: (mount.c:76): mount error(112): Host is down
Oct 31 18:57:25 r5-pc20 lightdm: (mount.c:76): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Oct 31 18:57:25 r5-pc20 lightdm: (pam_mount.c:522): mount of students failed
…mount of shares, of pgm, of cdrom…failed

Danke für deine Hilfe bisher.
LG Axel

baumhof · 2. November 2018 um 09:50

Hallo Axel,

Ich habe die generic.postsync nach /var/linbo/mate-sw2.cloop.postsync
kopiert und PATCHCLASS=“mate32“ eingetragen.

wie sind den die Rechte der postsync Datei?
Wie sind die Rechte im Verzeichnis /var/linbo/linuxmuster-client und
darunter?

LG

Holger

Axel · 2. November 2018 um 13:28

Hallo Holger,
die Rechte sind bei mir wie folgt gesetzt:

-rw-rw---- 1 root root 4146 Oct 26 11:39 mate-sw2.cloop.postsync

drwxr-xr-x 4 root root 4096 Oct 26 11:46 linuxmuster-client
drwxr-xr-x 3 root root 4096 Oct 26 11:48 mate32

linuxmuster-client/mate32:
drwxr-xr-x 3 root root 4.0K Sep 19 2016 common

linuxmuster-client/mate32/common:
drwxr-xr-x 3 root root 4.0K Sep 19 2016 etc

linuxmuster-client/mate32/common/etc:
drwxr-xr-x 2 root root 4.0K Sep 19 2016 cups
-rwxr-xr-x 1 root root 472 Sep 19 2016 fstab
-rwxr-xr-x 1 root root 472 Oct 26 13:20 hosts

linuxmuster-client/mate32/common/etc/cups:
-rwxr-xr-x 1 root root 21 Sep 19 2016 client.conf

Experimentiert habe ich auch schon mit den Rechten -rwxrwx— beim postsync. Hat aber nichts gebracht, weshalb ich die Rechte wieder zurückgesetzt habe.
LG Axel

baumhof · 2. November 2018 um 21:24

Hallo Axel,

-rw-rw---- 1 root root 4146 Oct 26 11:39 mate-sw2.cloop.postsync
Experimentiert habe ich auch schon mit den Rechten -rwxrwx— beim
postsync. Hat aber nichts gebracht, weshalb ich die Rechte wieder
zurückgesetzt habe.

die Rechte sollten sein: rw-rw-r-- also 664
Ich meine, dass der Nutzer linbo das lesen können muss: und er gehört
nicht in die Gruppe root.

Die anderen Rechte sehen gut aus.

LG

Holger

Axel · 7. November 2018 um 09:56

Hallo Holger,
die Änderung der Rechte für die …cloop.postsync hat nichts bewirkt, Schüler/Lehrer können sich nach wie vor nicht am Client anmelden.
Weißt du wie die Ausführung der …cloop.postsync gesteuert wird, durch ein Skript oder eine conf-Datei?
LG Axel