Linuxclient - manuelle Installation

Axel · 16. Oktober 2018 um 10:05

Hallo Max,
der Client ist in der workstations-Datei und bekommt eine IP. Beim parallel installierten Windows funktioniert auch die Benutzeranmeldung ohne Probleme.
LG
Axel

Axel · 16. Oktober 2018 um 10:23

Hallo Tobias,
im Verzeichnis /etc/pam.d gibt es keine lightdm.conf. In pam.d gibt es nur eine lightdm, lightdm-autologin und lightdm-greeter.
In der lightdm-greeter steht folgendes:
linuxadmin@r5-pc20:/etc/pam.d$ cat lightdm-greeter
#%PAM-1.0
auth required pam_permit.so
auth optional pam_gnome_keyring.so
auth optional pam_kwallet.so
auth optional pam_kwallet5.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_limits.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional pam_gnome_keyring.so auto_start
session optional pam_kwallet.so auto_start
session optional pam_kwallet5.so auto_start
session required pam_env.so readenv=1
session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale

Ich kann ja mal die Zeilen mit “pam_kwallet…” auskommentieren und sehen was passiert. Oder müssen diese Objekte nachträglich noch installiert werden?
LG
Axel

Tobias · 16. Oktober 2018 um 19:36

Hi Axel,

stimmt, dort heißen die Dateien nicht „.conf“

das klingt ja so, als sei das kwallet nicht installiert. Ich würde nicht die lightdm.greeter sondern die lightdm öffnen und die pam_wallet auskommentieren (und lightdm restarten). Probieren schadet nicht, aber das „optional“ deutet ja darauf hin, dass es vllt. auch ohne gehen sollte.

VG, Tobais

Axel · 17. Oktober 2018 um 14:25

Hallo Tobias!
In der lightdm gibt es kein „pam_kwallet…“. Also hab ich die entsprechenden Zeilen in ligthtdm-greeter auskommentiert und lightdm neu gestartet. Bringt aber nichts. Nach Eingabe der Anmeldedaten erhalte ich wieder eine leere Anmeldemaske.
Dann habe ich nach installierbaren Paketen mit „kwallet“ gesucht und 2 gefunden: libpam-kwallet4 (KDE 4) und libpam-kwallet5 (Kf5). Letzteres habe ich installiert. Bringt aber auch nichts. Lediglich der entsprechende Fehler taucht nicht mehr in der auth-log auf.
Der Fehler „PAM unable to dlopen(pam_kwallet.so)“ bleibt bestehen.
Ich denke der Hauptfehler liegt darin, dass der Client keine Verbindung zum LDAP-Server herstellen kann:

Oct 17 16:13:40 r5-pc20 sh: nss_ldap: reconnecting to LDAP server…
Oct 17 16:13:40 r5-pc20 sh: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…
Oct 17 16:13:40 r5-pc20 dbus-daemon: nss_ldap: reconnecting to LDAP server…
Oct 17 16:13:40 r5-pc20 dbus-daemon: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)…
Oct 17 16:13:40 r5-pc20 sh: nss_ldap: could not search LDAP server - Server is unavailable

Daher auch die mount-Probleme, wenn ich mich als Lehrer oder Schüler anzumelden versuche:

Oct 17 17:44:49 r5-pc20 lightdm: pam_unix(lightdm:session): session opened for user janzondi by (uid=0)
Oct 17 17:44:49 r5-pc20 systemd-logind[660]: New session c6 of user janzondi.
Oct 17 17:44:49 r5-pc20 systemd: pam_unix(systemd-user:session): session opened for user janzondi by (uid=0)
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:72): Messages from underlying mount program:
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:76): mount error(112): Host is down
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:76): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Oct 17 17:44:50 r5-pc20 lightdm: (pam_mount.c:522): mount of janzondi failed
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:72): Messages from underlying mount program:
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:76): mount error(112): Host is down
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:76): Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Oct 17 17:44:50 r5-pc20 lightdm: (pam_mount.c:522): mount of students failed
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:72): Messages from underlying mount program:
Oct 17 17:44:50 r5-pc20 lightdm: (mount.c:76): mount error(112): Host is down
usw.

Hast du eine Idee woran es liegen kann, dass der Client keine Verbindung zum LDAP herstellen kann?
Ein ping vom Client zum Server mit IP funktioniert, ein ping mit dem distinguished name (of the LDAP search base), wie ich ihn bei der Konfiguration des Paketes linuxmuster-client-auth eingetragen habe, funktioniert nicht.
Danke für deine Geduld.
LG
Axel

baumhof · 17. Oktober 2018 um 14:51

Hallo Axel,

bitte poste mal die /etc/hosts
vom Client

LG
Holger

helge.m · 17. Oktober 2018 um 14:57

Hallo Axel,
installiere mal die Daemonvarianten. die enthalten die gleichen Programme, aber gepflegt:
sudo apt install libnss-ldapd libpam-ldapd

Ich habe auch gerade einen eignen Linuxclient auf debian-Basis gemacht und das war mit ein Problem. Die Pakete ohne d sind buggy.
Viele Grüße,
Helge

Axel · 18. Oktober 2018 um 14:32

Hallo Holger,
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

LG
Axel

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