Unseren Testserver habe ich heute Morgen auch auf v7.2 gebracht. Im Wesentlichen lief das glatt … ein paar Dinge habe ich mir aber dennoch notiert, die auch dem Versionssprung von 18.04 auf 22.04 geschuldet sind:
ich hatte sehr viele alte kernel-modules für den Kernel 4.15.x drauf, die ich alle entfernt habe (es gab eine Warnung während des Updates „no candidate found …“ o.ä.): Anzeigen lassen kann sich das z.B. so: dpkg --list | egrep -i 'linux-image-4.|linux-headers-4.' | awk '/rc/{ print $2}'
FreeRadius scheint das Upgrade mitgemacht zu haben: Wir haben da ein paar Dinge eingestellt … das wurde scheinbar alles übernommen. Getestet habe ich es aber noch nicht.
der checkMK_Agent wurde entfernt – warum auch immer.
Aber meine eigentliche Frage ist: Die Quota im WebUI werden unter v7.2 nicht mehr richtig angezeigt. Hier ist die Anzeige unter Version 7.0:
und hier die gleiche Anzeige unter v7.2:
Ist das bei Euch auch so? Was gilt es da zu tun? Wenn ich mir
repquota -a |head
*** Report for user quotas on device /dev/sdb1
Block grace time: 7days; Inode grace time: 7days
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 12 0 0 0 0 0
#3000000 -- 2338324 0 0 82 0 0
anschaue, stehen da keine Usernamen sondern die IDs (?) der User. Gibt’s da einen Zusammenhang?
… direkt noch eine Beobachtung: Ich habe eine VM gestartet, um das neue LINBO v4.1 zu sehen. Der neue Kernel Version 6.x startet zwar und man sieht auch „One Step Beyond“(dieses Mal kein Bob Dylan Song ?).
Dann aber geht’s nicht weiter. Der LINBO-Kreis dreht sich endlos im Kreis
und eine Druck auf ESC liefert dann die Ursache:
Weiter geht’s hier leider im Moment nicht.
… direkt noch eine Beobachtung: Ich habe eine VM gestartet, um das neue
LINBO v4.1 zu sehen. Der neue Kernel Version 6.x startet zwar und man
sieht auch „One step beyond“(dieses Mal kein Bob Dylan Song ?).
Dann aber geht’s nicht weiter. Der LINBO-Kreis dreht sich endlos im
Kreis und eine Druck auf |ESC| liefert dann die Ursache:
linbo-v72
fu hast wohl noch
blacklist=radeon
… also den alten AMD Befehl drin und nicht
nomodeset
Versuch mal ganz ohne.
Und wenn das nicht geht, dann nomodeset dazu schreiben.
linuxmuster-import-devices jeweils nicht vergessen und sicher stellen,
dass die GRUPPE.cfg geschrieben wird.
Dann kann ich als nächstes ja mal die differentiellen Images ausprobieren.
[etwas später – oder auch nicht]
Hm – ich komme bei LINBO nicht mehr mit unserem alten Standard-Passwort rein. Stattdessen erhalte ich immer Falsches Passwort! – wurde da etwas geändert?
Der Hashing-Algorithmus hat sich geändert.
Ist das generell so oder nur bei einem bestimmten Client? Kann eigentlich nur vorkommen, wenn die lokale LInboversion <4.1 ist.
Genau das, was Holger oben vermutet hat: Da stand in der start.conf.win10 bei den Kernel-Paremtern der Eintrag KernelOptions = quiet splash dhcpretry=10 modprobe.blacklist=radeon
Irgendwann brauchten wir das mal – ich weiß aber nicht mehr auf welcher Hardware das notwendig war (evtl Yoga-12-Laptops? )
Unter /etc/rsyncd.secrets steht das richtige Passwort. Dann nochmal update-linbofs … mal sehen
Nö – will leider nicht. Ich habe ein super einfaches Passwort mit 8 Zeichen aber ohne Sonderzeichen gewählt. Es ist ein Großbuchstabe dabei und 4 Ziffern. Hier nochmal die Ausgabe auf dem Server:
update-linbofs
Hashing linbo password ... Success!
Processing linbofs64 update ...
100 % 29,2 MiB / 133,3 MiB = 0,219 2,1 MiB/s 1:02
Ok!
0+0 records in
0+0 records out
0 bytes copied, 0,000111558 s, 0,0 kB/s
mkfs.fat 4.2 (2021-01-31)
xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.
Drive current: -outdev 'stdio:/srv/linbo/linbo.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 41.5g free
Added to ISO image: directory '/'='/var/cache/linuxmuster/linbo/iso'
xorriso : UPDATE : 990 files added in 1 seconds
xorriso : UPDATE : 990 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 432 bytes from file '/usr/lib/ISOLINUX/isohdpfx.bin'
xorriso : WARNING : Boot image load size exceeds 65535 blocks of 512 bytes. Will record 0 in El Torito to extend ESP to end-of-medium.
libisofs: NOTE : Aligned image size to cylinder size by 392 blocks
xorriso : UPDATE : 33.23% done
ISO image produced: 125952 sectors
Written to medium : 125952 sectors at LBA 0
Writing to 'stdio:/srv/linbo/linbo.iso' completed successfully.
Ok, danke. Ich dachte, der Parameter lautet nur auf blacklist=radeon. Wenn modprobe.blacklist tatsächlich auch vorkommen kann, muss ich das abfangen.
Der Passwort-Fehler ist seltsam. Was passiert, wenn du auf der Linbo-Konsole linbo_auth <password> eingibst? Wird das aktualisierte Linbo nach update-linbofs heruntergeladen? Hast du warmstart abgeschaltet? Falls ja, musst du den Linbo-Client nochmal neustarten.
Die VM war komplett aus. Gerade nochmal neu gestartet. Beim Start sieht alles normal aus – die Bootreihenfolge für diese VM steht auf „Net, scsi0“. Dann muss es auf der VM doch aktuell sein, oder?
linbo_auth <password>
Das liefert auch auf der Konsole:
vm-win10: ~ # linbo_auth Pass5678
Using local authentication ...
Password does not match
Die Datei auf dem Server sieht übrigens so aus (und wurde seitdem nicht geändert):
[root@server:~]$ cat /etc/rsyncd.secrets
# modified by linuxmuster-setup at 20190914143026
linbo:Pass5678
[root@server:~]$
Vielleicht wird da zuviel gehashed? Oder passt das alles so?
Nochmal zu den Quota: Hat sich da auch etwas geändert? Gerade im WebUI zufällig auf …/view/lm/users/teachers → Quota anzeigen
dort erhalte ich diese Meldung:
Serverfehler
Server error occured. This is likely a bug.
Request
GET /api/lmn/quota/usermap/<ein login>
Type
ValueError
Message
invalid literal for int() with base 10: 'not available'
Traceback
Traceback (most recent call last):
File "/usr/local/lib/python3.10/dist-packages/aj/api/endpoint.py", line 75, in wrapper
result = fx(self, context, *args, **kwargs)
File "/usr/lib/linuxmuster-webui/plugins/lmn_quotas/views.py", line 65, in handle_group_quota
if int(share['HARDLIMIT_MiB']) == share['HARDLIMIT_MiB']:
ValueError: invalid literal for int() with base 10: 'not available'
Ja, es gibt eine Fehlermeldung, und zwar: -sh: syntax error: unexpected ";" – kann es damit zusammenhängen, dass bei mir im Linbo_Salz zufällig ein Semikolon erzeugt wurde? Ach so – ein $ Zeichen ist auch dabei … und auch ( und ) und % … ist das das Problem?
Bei mir sieht ein Teilstring des Salzes zufällig so aus: $(;C) – da kann die Shell schon drüber stolpern, oder?
Mit den Doppel-Quotes läuft es durch aber liefert nicht den gleichen String wie unter linbo_pwhash. Kann das irgendwie an Proxmox und den vCPUs liegen?
Ja, dann zählen die 2. Quotes zum Salt. Bin da im Moment ratlos. Works for me. Mein Salt hat auch jede Menge Sonderzeichen drin. Und bei mir läuft das auch unter Proxmox.
Mal abwarten was andere Tester berichten.
Ich habe die VM gerade nochmal neu gestartet … das Salz wurde erneuert und zwar client- und serverseitig. Wann/wie oft/durch welche Aktion wird die Erneuerung denn veranlasst?
Auch mit dem neuen Salz und Einzelquotes '<linbo_salt>' liefert die VM einen anderen Passworthash als er unter /etc/linbo_pwhash steht. Seltsam ist aber: Wenn ich das gleiche auf dem Server ausführe, passt es!
Die Frage ist also: Was macht der Server anders als LINBO? Andere Version von argon2 oder sowas in der Art vielleicht?
… ein paar Dinge habe ich mir aber dennoch notiert, die auch dem Versionssprung von 18.04 auf 22.04 geschuldet sind:
?).
)
