Lmn 7.2 testing

Weiterentwicklung
362

Hallo zusammen,

bei einer Neuinstallation von 7.2(also kein Upgrade von 7.1) wird der Dropbear SSH-Client in Linbo nicht gestartet. Grund ist wahrscheinlich dass die SSH-Keys nicht vorhanden sind.
Linbo meldet das auch bei der (Re-)Installation:

cp: cannot stat '/etc/linuxmuster/linbo/dropbear_*_host_key': No such file or directory
# ls -la /etc/linuxmuster/linbo/
total 32
drwxr-xr-x 2 root root 4096 Jul 29 18:05 .
drwxr-xr-x 7 root root 4096 Jul 29 17:48 ..
-rw-r--r-- 1 root root 1629 Jul 29 17:46 ssh_config
-rw------- 1 root root 1405 Jun 15 16:05 ssh_host_dsa_key
-rw-r--r-- 1 root root  617 Jun 15 16:05 ssh_host_dsa_key.pub
-rw------- 1 root root 2610 Jun 15 16:05 ssh_host_rsa_key
-rw-r--r-- 1 root root  581 Jun 15 16:05 ssh_host_rsa_key.pub
-rw-r--r-- 1 root root  142 Jun 15 16:05 start.conf.default

Kann es sein, daß die Keys in 7.1 durch das Paket linuxmuster-linbo-common7 installiert wurden, welches es in 7.2 nicht mehr gibt?

Wie bekomme ich die Keys generiert?

Danke und viele Grüße
Klaus

363

Hallo Klaus,

Kann es sein, daß die Keys in 7.1 durch das Paket
linuxmuster-linbo-common7 installiert wurden, welches es in 7.2 nicht
mehr gibt?

soweit ich weiß, benötigt eine 7.2 INstallation auch die 7.1 repos.
Sind die bei dir drin?

LG

Holger

364

Hallo Holger,

Danke für Deine schnelle Rückmeldung!
Ja, ich habe nachgesehen, die 7.1 Repos sind drinnen. Es sieht so aus, als ob es linuxmuster-linbo-common7 auch in 7.1 gar nicht mehr gibt bzw. es nur ein Überbleibsel ist. Evtl. müsste man das also in Linbo einbauen, daß die Keys generiert werden, wenn diese nicht vorhanden sind.

Ich habe nun rausgefunden wie man das macht. Da ich nicht weiß, welcher der beiden Keys verwendet wird, habe ich beide generiert:

dropbearkey -t dss -f /etc/linuxmuster/linbo/dropbear_dss_host_key
dropbearkey -t rss -f /etc/linuxmuster/linbo/dropbear_rss_host_key
apt install --reinstall linuxmuster-linbo7

Dann funktioniert linbo-ssh wieder.

Viele Grüße
Klaus

365

llo Klaus,

ich hab mal ein issue für linuxmuster-linbo7 gemacht, damit es nicht
vergessen wird.

LG

Holger

1 „Gefällt mir“
366

Moin moin!

linuxmuster-linbo7 4.1.34 ist verfügbar:

  • Update kernel to 6.4.7 (4a2b48a).
  • Fix typo in kernel build run script (3a06c81).
  • Fix #100: dropbear ssh keys not generated when making an fresh install of 7.2 (no upgrade).

Die von openssh erzeugten SSH-Keys müssen im PEM-Format vorliegen, damit sie ins Dropbear-Format konvertiert werden können. Wird beim Paket-Upgrade erledigt.

VG, Thomas

1 „Gefällt mir“
367

Hallo Zusammen!

Ich hab jetzt unseren Schulserver auf auf 7.2 upgegraded.

Dabei ist mir folgendes aufgefallen:

  • Beim Upgrade von 18.04 auf 20.04 wird zweimal nach Kerberoseinträgen gefragt, die in der Doku nicht erwähnt werden: „Kerberos-Server für Ihren Realm“ und „Administrations-Server für Ihren Kerberos-Realm“ - ich habe beides leer gelassen. (@Doku-Team )

Am Ende unter 22.04 hatte/habe ich dann folgende Probleme:

  • Ein Start mit dem neuen linbo läuft ohne ein initcache in eine Endlosschleife mit dem schon beschriebenen glibc-Problem - [lmn7.2] linbo_gui glibc Fehler und Freeze - ich muss also einmal überall den cache aktualisieren.
  • linbo-remote funktioniert aktuell nur mit den Hostnamen der Rechner, nicht mit den IP-Adressen (@thomas )
  • ntp_signd - ähnlich wie schon beschrieben (z.B. LM 7.1 Upgrade auf 7.2 - #13 von steff66) - dadurch lief samba zunächst nicht
  • In der Schulkonsole funktioniert trotz entfernen von „-mNT1“ aus /usr/share/sophomorix/devel/sophomorix.ini und /usr/sbin/sophomorix-query (in /usr/sbin/sophomorix-transfer war der Eintrag nicht enthalten) weder Quota noch der Zugriff auf „Meine Dateien“ ( @Arnaud ).
    Ein Klick auf „Meine Dateien“ ergibt diese Fehlermeldung: „Konnte Verzeichnis nicht laden: There’s a problem with the kerberos authentication : Failed to authenticate with server: SpnegoError (1): SpnegoError (16): Operation not supported or available, Context: Retrieving NTLM store without NTLM_USER_FILE set to a filepath, Context: Unable to negotiate common mechanism“.
    „mNT1“ gibt es bei mir nur noch in /usr/sbin/sophomorix-cacls .
  • Beim Ausführen von sophomorix-quota erhalte ich am Ende vielfach diese Fehlermeldung:
    „ERROR -1: FAILED (256): /usr/bin/smbcquotas --debuglevel=0 -U administrator%‚***‘ -S UQLIM:$USER:0/0 //$SERVER/global“ ( @jeffbeck )

Vielleicht hat jemand an der einen oder anderen Stelle einen Lösungsansatz … ?
Weitere Test folgen … :wink:

Gruß - Rainer

368

Hallo Rainer,

das sollte eigentlich nachhaltig gefixed sein …
Welche linbo Version war den vorher auf den Clients? >= 4.0.44 ?

… auch seltsam, weil es bei mir auch mit IP Adressen funktioniert.

… das ist ein Problem.
Wir müssen uns überlegen, ob wir das in einem Paketupdate vor der
Aktualisierung fixen können: wenn nicht, dann sollte das prominent in
die Doku zum Upgrade: dass man das vorher anpassen sollte.

  • In der Schulkonsole funktioniert trotz entfernen von „-mNT1“ aus
    /usr/share/sophomorix/devel/sophomorix.ini und
    /usr/sbin/sophomorix-query (in /usr/sbin/sophomorix-transfer war der
    Eintrag nicht enthalten) weder Quota noch der Zugriff auf „Meine
    Dateien“ ( @Arnaud https://ask.linuxmuster.net/u/arnaud ).
    Ein Klick auf „Meine Dateien“ ergibt diese Fehlermeldung: „Konnte
    Verzeichnis nicht laden: There’s a problem with the kerberos
    authentication : Failed to authenticate with server: SpnegoError
    (1): SpnegoError (16): Operation not supported or available,
    Context: Retrieving NTLM store without NTLM_USER_FILE set to a
    filepath, Context: Unable to negotiate common mechanism“.
    „mNT1“ gibt es bei mir nur noch in /usr/sbin/sophomorix-cacls .

… die -mNT1 Option ist in etlichen Dateien zu entfernen: ich weiß
nicht, ob du alle erwischt hast.
Ich hab die das erste mal vor mehreren Monaten in einer Datei entfernt
und zuletzt in einer anderen vor etwa 2 Wochen … ich hab leider nicht
Liste geführt in welchen Dateien ich die Änderungen vorgenommen habe :frowning:

wenn ich jetzt mal sammle kommen diese Stellen auf:

… ich hoffe, dass das alles sind …

  • Beim Ausführen von sophomorix-quota erhalte ich am Ende vielfach
    diese Fehlermeldung:
    „ERROR -1: FAILED (256): /usr/bin/smbcquotas --debuglevel=0 -U
    administrator%‚***‘ -S UQLIM:$USER:0/0 //$SERVER/global“ ( @jeffbeck
    https://ask.linuxmuster.net/u/jeffbeck )

ich hab gerade
sophomorix-quota --set
aufgerufen: das lief ohne Probleme durch.

… bei Reiner, der auch während des upgrades das ntp Problem mit nicht
startendem samba hatte, hat das dazu geführt, dass nach dem zweiten
upgrade (von 20.04 auf 22.04) einzelne Pakete nicht konfiguriert oder
fertig konfiguriert waren.
Hast du getestet, ob da alles fertig ist jetzt?
apt update
apt dist-upgrade
nochmal gemacht?

früher ging in so einem Fall
dpkg-reconfigure -a
… aber ich glaube, das ist jetzt ein anderer Befehl …

LG

Holger

369

Hallo Rainer,

Probier mal bitte das :

wget https://raw.githubusercontent.com/linuxmuster/linuxmuster-webui7/lmn72/tests/test-smbclient.py
python3  test-smbclient.py

Das sollte helfen zu verstehen, welcher Subdomain bei dir nicht funktioniert.

Gruß

Arnaud

370

Moingiorno!

Fix is on the way.

Das ist ein Problem der Namensauflösung. Das funktioniert grundsätzlich. Überprüfe bitte mit nslookup. Evtl. Zusammenhang mit dem kerberos-Prob?

Schau ich mir nochmal an. Aber wenn man die Clients einmal mit initcache bootet läufts?

VG, Thomas

371

Moin moin!

linuxmuster-base7 7.2.0-rc11 ist raus:

  • postinst: fix permissions of samba’s ntp socket directory (f84835a).
  • linuxmuster-import-subnets: use gateway ip from setup.ini rather than firewall ip (fa83151).
  • change codename to „release candidate“ (8b86c6d).

VG, Thomas

372

Hallo Arnaud!

Danke für die schnelle Reaktion.

server # python3 test-smbclient.py
This script helps to test some domains to access samba shares, and you can try your own path too.
Samba realm used by the Webui → xxxDOMÄNE
Samba netbios used by the Webui → xxxSERVER
Samba domain used by the Webui → xxxSERVER.DOMÄNE
Samba domain to try (optional, something like server.linuxmuster.lan): xxxSERVER.DOMÄNE
Teacher login: xxx
Password:
Getting Kerberos ticket
No valid Kerberos ticket found !

Gruß - Rainer

373

Hallo Arnaud!
Ich hatte einen Fehler in /etc/resolv.conf (unter Ubuntu 20.04 hatte DNS nicht funktioniert, daher wurde vorübergehend die Datei geändert, aber nicht zurück geändert).
Jetzt geht die Dateianzeige und das Quota in der Schulkonsole. Und dein Script gibt auch die Ausgabe der Dateien, die ich in der Schulkonsole sehe. :slight_smile:
Gruß - Rainer

374

Hallo Thomas!

Danke für die schnelle Hilfe.
Die Namensauflösung war tatsächlich falsch.
Jetzt funktioniert auch linbo-remote mit der IP.
Das mit linbo muss ich mir jetzt nochmals ansehen - Fortsetzung folgt.

Gruß - Rainer

375

Hallo Rainer,
denk dran, dass man die remoteprozesse nicht mehr per screen anschaut,
sondern per tmux
Am einfachsten mittels
linbo-remote -r

LG

Holger

376

Also hier läuft das Upgrade geschmeidig. Der Client hat Linbo 4.0.46, der Server 4.1.34. Hier muss mensch sicherstellen, dass vor dem Upgrade wirklich das aktuelle Linbo auf den Clients ist.

VG, Thomas

377

Hallo,

Also hier läuft das Upgrade geschmeidig. Der Client hat Linbo 4.0.46,
der Server 4.1.34. Hier muss mensch sicherstellen, dass vor dem Upgrade
wirklich das aktuelle Linbo auf den Clients ist.

ja, das haben wir gut getestet: ich nehme an, dass die Fehlerhafte
Namensauflösung während des ersten Startens da reingespuckt hat bei Rainer.

LG

Holger

378

Oh…was heißt denn „aktuelles Linbo“. Reicht da ein 4er oder muss es wirklich brandaktuell sein?

Liebe Grüße
Frank

379

Hallo,

mir ist noch folgendes Problem in der webui aufgefallen:
Wenn ich bei der Linbo-Synchronisierung mehrere Rechner auswähle, um den gleichen Befehl auszuführen, z.B.

/usr/sbin/linbo-remote -i 10.0.47.1 -c partition,sync:1,sync:2
/usr/sbin/linbo-remote -i 10.0.47.2 -c partition,sync:1,sync:2
/usr/sbin/linbo-remote -i 10.0.47.3 -c partition,sync:1,sync:2

werden nur auf dem 3. PC die Befehle ausgeführt, PCs 1+2 bleiben stumm. Obwohl für alle 3 PCs in der Webui das grüne Häkchen kam.

Wenn ich aber auf der Konsole den Befehl

linbo-remote -r r047 -c partition,sync:1,sync:2

ausführe, werden alle PCs korrekt aktiv.

Viele Grüße,
Stefan

380

Hallo Frank,

es sollte das zum Zeitpunkt des Upgrades aktuelle sein…

Außerdem steht am Anfang der Upgradeanleitung: „system auf aktuellen
Stand bringen, dann weitermachen“ :slight_smile:
(wobei das nicht helfen muss, weil man deswegen ja dann nicht alle
Clients bootet um das lokale linbo auf den aktuellen Stand zu bringen, was aber eigentlich nötig wäre).

LG

Holger

381

Hallo @thomas !

Die Situation mit linbo ist wie folgt:

  • Die glibc-Fehler lassen sich bei mir umgehen, wenn ich auf den Clients den cache aktualisieren lasse (mittlerweile schon über 100 mal gemacht) → funktioniert
  • die postsync-Datei auf meinen Clients ist noch eine mit Variablen für die ServerIP, die jetzt nicht mehr funktionieren - siehe Lmn 7.2 testing - #101 von foer
  • ein Sync der zugehörigen Partition holt aber die aktuelle postsync-Datei - siehe Lmn 7.2 testing - #166 von thomas → funktioniert

Und jetzt kommt mein aktuelles Problem, für das ich keine Lösung finde - grub:

  • Wenn ich nun einen U2204-Client synchronisiere, dann wird anschließend zum Starten im grub immer EINE feste Festplatten-UUID verwendet (ce6d5ca4-60df-…-a3ce).
    Da die UUID nicht gefunden wird, landen alle synchronisierten Clients in der BusyBox und sind nicht mehr benutzbar.

Wenn ich mit linbo-ssh auf einem Client bin, erhalte ich mit „linbo_wrapper start:1“ folgende Ausgabe:
Starting Ubuntu 22.04 …
Found kernel boot/vmlinuz on partition /dev/sda2.
mk_boot /dev/sda2 boot/vmlinuz boot/initrd.img root=/dev/sda2 root=/dev/sda2 ro nosplash video=radeonfb vga=791 locale=de_DE
prepare_grub /cache/boot/grub /cache/boot/grub/grubenv /usr/share/grub
prepare_reboot /dev/sda /dev/sda2 /cache/boot/grub/grubenv boot/vmlinuz boot/initrd.img root=/dev/sda2 root=/dev/sda2 ro nosplash video=radeonfb vga=791 locale=de_DE /dev/sda1
repair_efi /dev/sda1
EFI bootnext for Ubuntu 22.04 has been set to 0002.
EFI bootorder has been successfully set.
BootNext: 0002
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0004
Boot0000* Diagnostic Program
Boot0001* grub
Boot0002* Ubuntu 22.04
Boot0003* Micron_1100_MTFDDAK256TBN
Boot0004* UEFI: PXE IP4 Realtek PCIe GBE Family Controller
Boot0005* UEFI: PXE IP6 Realtek PCIe GBE Family Controller
Installing GRUB in MBR/EFI of /dev/sda … OK!

Gestern konnten die Clients nach dem Synchronisieren noch starten, da hatte das postsync-Script aber noch den Fehler mit den Variablen. Trotzdem wurden die /etc/fstab der Rechner richtig gepatched und die Rechner waren benutzbar. (Vermutlich weil alle notwendigen Dateien noch im cache vorhanden waren.)

Wenn ich einen solchen Client heute starte, der noch kein aktuelles postsync erfahren hat, dann sieht die Ausgabe (über linbo-ssh) gleich aus und der Rechner startet weiterhin. Sobald aber einmal das postsync durchgelaufen ist, ist der Client kaputt.
Am postsync-Script selbst kann es aber nicht liegen, denn eine leere postsync-Datei liefert das gleiche Ergebnis.
Ich denke das fehlerhafte postsync-Script verhindert etwas anderes, was dann den grub „zerschießt“.

Wer hat eine Idee?

Gruß - Rainer