Betatest: Probleme und -lösungen

Hi,
ich bitte um Feedback in diesem Thread, den ich (oder alle die, die das dürfen) in dem TOP-Post aktualisiere(n).

Betatest

Der Betatest wird hier: http://docs.linuxmuster.net/de/v7/about/beta7.html dokumentiert.

Feedback

Wir wünschen uns, dass hier der Feedback gemeldet und dokumentiert wird. Feedback zu allem, was funktioniert, alles was bisher noch nicht getestet wurde ab ein Beta-Tester funktionsfähig bekommt.

Basissystem

Probleme und Lösungen

nicht implementiert

nicht getestet

Erweiterungen

nicht implementiert

nicht getestet

Was bisher nicht getestet wurde zur Migration:

  • pykota (Druckerquotierung)
  • MRBS
  • Mail
  • IPFire-Regeln für OpenVPN
  • Moodle
  • Nextcloud

getestet

Dockermigration einzelner Erweiterungen

1 Like

Hi @jeffbeck,

bevor ich die migration auch zig Mal durchführe: Das linuxmuster-setup muss ja schon ausgeführt worden sein, richtig?
Ignoriert folglich das vampire-import-skript die Domäne komplett? DAs sollte ich wohl dokumentieren, dass man hinterher (in der v7) ziemlich wahrscheinlich eine andere Domäne hat als vorher (in der v6.2).

Was wiederum Auswirkungen darauf hat, wie die externen Services wie cloud/moodle/etc. funktionieren.

VG, Tobias

ja, setup muss durchgeführt sein. Dort wird die Domäne festgelegt (z.B. gleiche wie bisher)

Dann werden die user, usw. neu angelegt in der neuen Domäne (die auch wieder die alte sein kann)

LG, Rüdiger

ich höre da raus, dass es auch eine neue Domäne sein kann.
Ok. Vielen Dank für die Info.
VG, Tobias

Feedback zur Migration der Benutzer-Metadaten mit sophomorix-dump und sophomorix-vampire:

Läuft ganz durch in ca. 150 min. bei gut 1000 Benutzern, 40 Klassen, 15 Projekten,
homes und linbo geht auch durch, allerdings mit einigen Synchronisationsfehlern bei seltsamen Dateinamen und Dauer ca. 2h bei ca. 250GB an Daten zusammengenommen. Evtl. liegt das auch an langsamen Platten meines Testservers.

Hallo zusammen, hauptsächlich aber @toheine, @baumhof und eigentlich auch das gesamte Support und Doku-Team (jetzt muss ich erst die Namen raussuchen…),

Wie wäre es diesen Thread, den ich schon mal angelegt hatte zu nehmen und dort im TOP-Post auf die aktuellen Probleme und Lösungen zu verlinken?

Das kann man natürlich nicht per Mail machen, klar. Aber es geht schneller als das in der Doku live zu pflegen.
VG, Tobias

Das finde ich gut. Bedeutet ich darf da jetzt oben herumwerkeln? Z. B. IPFire-Regeln für OpenVPN durch OPNsense-Einrichtung f. OpenVPN ändern, etc.

sicher!
hast du die Berechtigung dazu? Wenn nein, ich glaube, ich kann sie dir nicht vererben. Dann hilft bloß hier den Beitrag zu schreiben und ich editiere oben, ODER wir machen diese Seite im Wiki.
VG, Tobias

Hallo Tobias,
tatsächlich konnte ich den Beitrag editieren. Ich habe soeben folgendes hinzugefügt.

Finde ich super … dann bekommst Du die Schelte wenn ich einen Shit verfasse :wink:

Ich fände einen zentralen “ToDo-Wiki”-Eintrag allerdings auch nicht schlecht.

Greetings
Tobi

Hi Tobi,

ist zwar jetzt die Meta-Diskussion, aber tatsächlich konntest du vermutlich nur deswegen den Eintrag editieren, weil ich unter dem Werkzeugsymbol den Beitrag als “Wiki” gekennzeichnet habe.
Ich weiß nicht, ob das jeder kann oder ob das an den erhöhten Rechten liegt, die ich irgendwann mal bekommen habe…

VG und Danke für den Eintrag, Tobias

Imagen eines neuen Clients (in diesem Falle Linux-Client, ich weiß nicht, ob das bei Windows auch passiert):

Bei einem komplett neuen Computer mit leerer Festplatte funktioniert bei mir der Punkt „imaging“ nicht. Sowohl „partitionieren“ als auch „cache wiederherstellen“ funktionieren nicht (ich bekomme unlesbare Fehlermeldungen mit nicht ASCII-Zeichen, exit code 1).

Stelle ich auf dem Server für diese Gruppe aber bei Start Options alles auf „auto“, so funktioniert es. Aber ich gerate dann in eine Endlosscheife, weil beim nächsten Start wieder alles plattgemacht wird.

Um den komplett neuen Client zu installieren, muss ich also am Server alles auf Auto stellen, wenn der Client in Limbo fertig synchronisiert hat, den Client ausschalten, am Server Auto wieder rausnehmen und dann den Client erneut starten.

Ist der Client hingegen einmal installiert, kann ich mit Linbo synchronisieren.

Denkbar ist, dass ich was falsch gemacht habe, aber da scheint mir irgendwas nicht zu stimmen. Ich müsste doch auch mal einen Client einzeln installieren können.

Edit: Das lag daran, dass man nach „registrieren“ auf dem Server die neue Liste auch noch einmal einlesen lassen muss. Man müsste überlegen, ob das so sinnvoll ist. Wenn man davon ausgeht, dass das linbo-Passwort nicht kompromittiert ist, dann wäre das schon sehr praktisch, einen Client registrieren zu können, ohne dabei ein Admin-Fenster auf dem Server irgendwo offen zu haben.

Ich bekomme in meiner virtuellen Testumgebung folgenden Fehler:

cifs vfs: smb signature verification returned error = -13

Ich habe im Internet danach gesucht, viele ähnliche Fragen gefunden, aber keine Antworten (außer, dass es mit der verwendeten Samba-Version zusammenhängt). Das Netzwerk hängt, wenn dieser Fehler kommt, und ist stark belastet. Hat jemand eine Idee?

Hallo Andreas,

bitte poste mal die start.conf.
und die Ausgabe von
fdisk -l /dev/sda

vom Client

LG

Holger

start.conf (vom client):

[LINBO]
DownloadType = rsync
AutoInitCache = no
SystemType = bios64
KernelOptions = splash quiet
Cache = /dev/sda2
Server = 10.16.1.1
Group = kubuntu
AutoFormat = no
AutoPartition = no

[Partition]
Bootable = yes
Dev = /dev/sda1
Label = Kubuntu
FSType = ext4
Id = 83
Size = 30G

[Partition]
Bootable = yes
Dev = /dev/sda2
Label = Cache
FSType = ext4
Id = 83
Size = 30G

[Partition]
Bootable = no
Dev = /dev/sda3
Label =
FSType = swap
Id = 82
Size = 8G

[Partition]
Bootable = no
Dev = /dev/sda4
Label = Daten
FSType = ntfs
Id = 7
Size =

[OS]
AutostartTimeout = 5
Kernel = vmlinuz
StartEnabled = yes
Name = Kubuntu
IconName = ubuntu.png
Image =
Boot = /dev/sda1
DefaultAction = start
Initrd = initrd.img
Version = 18.04
NewEnabled = yes
Autostart = yes
BaseImage = Kubuntu.cloop
Hidden = yes
SyncEnabled = yes
Root = /dev/sda1
Append = ro splash
Description = Ubuntu 16.04

linuxadmin@3NXDOMAIN:~$ sudo fdisk -l /dev/sda [sudo] password for linuxadmin: (pam_mount.c:365): pam_mount 2.16: entering auth stage Disk /dev/sda: 80 GiB, 85899345920 bytes, 167772160 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x3bb8f0f3

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 62916607 62914560 30G 83 Linux
/dev/sda2 * 62916608 125831167 62914560 30G 83 Linux
/dev/sda3 125831168 142608383 16777216 8G 82 Linux swap / Solaris
/dev/sda4 142608384 167772159 25163776 12G 83 Linux
(pam_mount.c:133): clean system authtok=0x557d5999fa40 (1073741824)
linuxadmin@3NXDOMAIN:~$


LG, Andreas

Hallo Andreas,

ich denke die Summer der Partitionen ist zu groß:
die ergeben 80GB und 80GB hat die Platte.
Ich würde die letzte Partition mal nur 8 GB groß machen: oder die
Größenangabe leer lassen: dann wird der „Rest“ genommen.

Nach Änderung der start.conf ein import nicht vergessen.

LG

Holger

Hi Holger,

Hat er doch!?

LG,
Jochen

Hallo Jochen,

Ich würde die letzte Partition mal nur 8 GB groß machen: oder die
Größenangabe leer lassen: dann wird der „Rest“ genommen.

Hat er doch!?

… stimmt …
jetzt wo ich noch mal hinschau, sehe ich es auch…

Wo stammte den die Ausgabe von
fdisk -l
her?

Könntest du mal
fdisk -l
von einem Client posten, bei dem das Partitionieren „von Hand“ nicht
geklappt hat?

Als erster Lösungsansatz würde ich vorschlagen:

  1. alle Buchstaben bei „Label“ in der start.conf „klein“ machen
  2. import
  3. test

LG

Holger

Hallo Holger,
ich glaube, wir arbeiten am falschen Problem. Das mit dem nicht „per Hand“ partitionieren können lag, wie ich im „edit“ dann schrieb (diese Edits kommen nicht per Mail, kann das sein?), daran, dass ich den Rechner zwar in der Linbo-Konsole registriert, danach die Liste auf dem Server aber nicht nochmal eingelesen hatte. Ich dachte, Du antwortest mir auf das cifs - Problem (und hatte mich schon etwas gewundert, was das mit /dev/sda zu tun haben soll).

Um es mal anders zu formulieren: Ich fände es gut, wenn man bei einem Rechner, wo man in Linbo „registrieren“ geklickt hat, beim nächsten Start gleich partitionieren könnte, ohne auf dem Server nochmal die Liste einzulesen. WEnn LInbo ein starkes Passwort hat, müsste das sicherheitstechnisch ok sein.

Das Problem, das ich in meiner virtuellen Testumgebung noch habe, sind die Netzwerkfehler mit Samba.

Hallo Andreas,

ich glaube, wir arbeiten am falschen Problem. Das mit dem nicht „per
Hand“ partitionieren können lag, wie ich im „edit“ dann schrieb (diese
Edits kommen nicht per Mail, kann das sein?), daran, dass ich den
Rechner zwar in der Linbo-Konsole registriert, danach die Liste auf dem
Server aber nicht nochmal eingelesen hatte. Ich dachte, Du antwortest
mir auf das cifs - Problem (und hatte mich schon etwas gewundert, was
das mit /dev/sda zu tun haben soll).

ja: die Edits kommen nicht an: ich hatte auf das Orginal geantwortet.

Gut dass der Fehler gefunden wurde: da ich das so überhaupt noch nicht
kannte.

Um es mal anders zu formulieren: Ich fände es gut, wenn man bei einem
Rechner, wo man in Linbo „registrieren“ geklickt hat, beim nächsten
Start gleich partitionieren könnte, ohne auf dem Server nochmal die
Liste einzulesen. WEnn LInbo ein starkes Passwort hat, müsste das
sicherheitstechnisch ok sein.

ja: das wäre ganz nett: stimmt.
Aber ich finde das nicht so wichtig: ich halte es für gut, wenn der
Rechneraufnahme noch ein „akt des Willens“ des Admins folgen muss.
Es ist eine Kleinigkeit und wenn man das einmal weiß, dann vergißt man
das auch nicht.
Vor allem: man kann ja nacheinander bis zu 99 Rechner aufnehmen und dann
einmal mit dem import übernehmen: es stört wirklich wenig.
Hingegen wäre ein Automatismus wieder Fehleranfällig: z.B. weil niemand
die consolenausgabe des imports sieht …

LG

Holger