Hallo,
ich bin neu hier, habe meine ersten “Gehversuche” mit linuxmuster unternommen und bin dann von der Infrastrukturänderung überrascht worden.
Ich habe jetzt erfahren das ich die cloop’s manuell installieren muß.
Kann mir jemand sagen wie ich mit den heruntergeladenen cloops verfahren muß? Soweit habe ich schon mitgekriegt, das die cloop (z.B. xenial916.cloop )Datei in das Verzeichnis /var/linbo gehört. Ist das richtig, müssen noch weitere Dateien heruntergeladen werden? Was muß ich noch machen?
Ich setze hier mal Mails von @baumhof (Hotline) zusammen, die alle offenen Fragen beantworten sollten.
Falls Fragen bleiben sollten bitte posten:
leider mussten unsere downloadserver auf andere Server umziehen. Siehe hier:
Das sehr genialer linuxmuster-client-servertools Paket läuft deswegen
ins leere.
ihr könnt sie unter der neuen Downloadadresse herunterladen …
Leider sind die cloops an sich noch nicht alles:
zum standardlinuxmuster-cloop gehören vor allem die postsync scripte und die
dazugehörige Verzeichnisstrucktur.
Diese legt das linuxmuster-client-servertools script alle mit an.
Die Verzeichnisstrucktur ist nicht komplex und kann schnell selbst
angelegt werden.
die Punkte stehen für die Verzeichnisse/Dateien wie sie auf dem Client
dann vorliegen sollen.
Also legt man eine fstab, die auf dem Client in /etc/ liegen soll also nach:
Es gibt aber auch eine Verzweigung: neben „common“ kann man auch
„rechnername“ und „raumname“ liegen haben.
Die Hierarchie ist: zuerst common, dann raum, dann rechner.
Wenn ich also eine fstab für einen Client haben will, die anders ist
also die in common, dann lege ich sie nach
Da zuerst common gesynct wird und am Ende der echnerspezifische
Bereich „gewinnt“ dieser.
Man sollte aber daran denken, dass wenn man eine Datei für einen rechner
spezifisch synct, dass diese als generische Datei auch in common liegen
sollte: sonst muss man aufpassen, dass man nie ein Image von diesem
Rechner aus macht.
Beispiel:
Raumbezogen mache ich das für meine neuen Rechner im Seminar.
Dort habe ich drei Räume, alle mit dem gleichen Image, alle unterschiedliche Hardware.
Aber der eine Raum hat neue Rechner und die haben nvmeSSDs, also muss
bei denen in der fstab
/dev/nvme0n1p1 (usw.) stehen statt /dev/sda1
(usw)
Ich hatte erst nur eine extra fstab für den Raum im Raumunterverzeichnis.
Nachdem ich ein Image in diesem Raum (für alle) erstellt hatte, lagen
die anderen Rechner auf der Nasse: sie hatten eine falsche fstab.
Also legte ich eine mit /dev/sdaX in common und schon war es egal wo ich
ein Image erstelle.
Klingt erstmal komplex: ist es auch, aber nur, weil es ein sehr mächtige
Werkzeug ist.
Am Ende noch ein Hinweis: die Rechte der Dateien sind wichtig.
Diese werde, so wie sie auf dem Server liegen, auf dem Client abgebildet.
Normalerweise muss man da mal drüber schauen, dann klappt das.
Aber es gibt Dateien, die haben wichtige Rechte.
z.B. die Datei /root/.ssh/authorized_keys
Bei mir:
So muss sie auf dem Server liegen: aber mit den Rechten 644 wird sie auf
dem Client vom ssh Dämon ignoriert (zu offen).
Ich kann sie aber nicht mit 600 auf dem Server liegen haben, weil linbo
sie dann nicht syncen kann (keine Rechte auf lesen).
Also liegt sie wie oben auf dem Server und wird im postsync mittels der
folgenden Zeilen mit anderen Rechten versorgt:
dazu noch eine Frage - ich steh da gerade auf dem Schlauch - müsste es nicht eine ausführbare Datei mit dem Namen postsync.sh geben?
Oder ist diese quasi identisch mit dem [cloop].postsync ?
Kann man dann von irgendwo die Neueste postsync-Datei (= das universelle postsync-Script ?) herunterladen und ihren Inhalt nach [cloop].postsync kopieren ?
dazu noch eine Frage - ich steh da gerade auf dem Schlauch - müsste es
nicht eine ausführbare Datei mit dem Namen postsync.sh geben?
nein: die .cloop.postsync ist die Datei mit dem script.
Diese wird von linbo auf den Client bewegt und dort ausgeführt.
Oder ist diese quasi identisch mit dem [cloop].postsync ?
jup
Kann man dann von irgendwo die Neueste postsync-Datei (= das universelle
postsync-Script ?) herunterladen und ihren Inhalt nach [cloop].postsync
kopieren ?
du kannst eien von mir haben oder sie selber erschaffen.
Das geht in etwa so:
linuxmuster-client -a configure -H xenial -p xenial -c xenial916.cloop
ich bin jetzt schon ein Stück weiter gekommen, habe die Cloop's
heruntergeladen, einen “linuxmuster-client -a configure -H xenial
-p xenial -c xenial916.cloop” ausgeführt, die Cloops erscheinen in
der Imageverwaltung, lassen sich kopieren etc. , ich habe das
"xenial-qgm.cloop kopiert und und als cora01.cloop gespeichert,
eine neue Konfiguration “cora01” erstellt, mit sda1 (55G) als
Betriessystempartition, sda2 (1G) als swap, sda3 (50GB) als Cache.
Der Client startet dann auch Linbo mit PXE. Die Partitionierung
und Formatierung wird auch durchgeführt {…habe ich direkt von der
Linbo-Konsole durchgeführt}. Ich habe die Partionierung von der
Linux-konsole mit fdisk überprüft, alles stimmt. Wenn ich jetzt
den Schalter “Gnu-linux installieren und neu starten” drücke, wird
mit dem Fehler beendet, /dev/sda1 könne nicht eingehangen werden.
Ich habe zu Überprüfung dann mal versucht sda1 von der
Linux-Konsole einzuhängen, und war erfolgreich.
Kannst du mir weiterhelfen? Wo finde ich die Logs, die mir sagen
ich bin jetzt schon ein Stück weiter gekommen, habe die Cloop’s heruntergeladen, einen linuxmuster-client -a configure -H xenial -p xenial -c xenial916.cloop
ausgeführt, die Cloops erscheinen in der Imageverwaltung, lassen sich kopieren etc. , ich habe das "xenial-qgm.cloop kopiert und und als cora01.cloop gespeichert, eine neue Konfiguration “cora01” erstellt, mit sda1 (55G) als Betriessystempartition, sda2 (1G) als swap, sda3 (50GB) als Cache.
Der Client startet dann auch Linbo mit PXE. Die Partitionierung und Formatierung wird auch durchgeführt {…habe ich direkt von der Linbo-Konsole durchgeführt}.
Ich habe die Partionierung von der Linux-konsole mit fdisk überprüft, alles stimmt. Wenn ich jetzt den Schalter “Gnu-linux installieren und neu starten” drücke, wird mit dem Fehler beendet, /dev/sda1 könne nicht eingehangen werden. Ich habe zu Überprüfung dann mal versucht sda1 von der Linux-Konsole einzuhängen, und war erfolgreich.
Zuletzt habe ich gesehen, daß in dem ensprechenden ...linbo.log steht, daß versucht wird /dev/sda1 als NTFS einzuhängen. Das System ist aber als GNU-Linux in der Konfiguration angelegt:
ich hab hier auch noch das Ende der /var/log/linuxmuster/linbo/admin-test2_linbo.log:
## Hardware setup - end ##
Installing for i386-pc platform.
grub-install: warning: cannot open directory `/usr/share/locale': No such file or directory.
Installation finished. No error reported.
Moeglicher Fehler erkannt: linbo_cmd laeuft bereits.
1415 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd ready
1420 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd ready
Moeglicher Fehler erkannt: linbo_cmd laeuft bereits.
1447 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd mac
1452 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd mac
Moeglicher Fehler erkannt: linbo_cmd laeuft bereits.
1467 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd version
1471 root 0:00 {linbo_cmd} /bin/sh /usr/bin/linbo_cmd version
NTFS signature is missing.
**Failed to mount '/dev/sda': Invalid argument**
**The device '/dev/sda' doesn't seem to have a valid NTFS.**
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
## Log session end: Fri Jun 21 13:26:50 CEST 2019 ##
## Log session begin: Fri Jun 21 13:26:50 CEST 2019 ##
Kann /dev/sda1 nicht einhaengen!
## Log session end: Fri Jun 21 13:26:50 CEST 2019 ##
## Log session begin: Fri Jun 21 13:27:57 CEST 2019 ##
Kann /dev/sda1 nicht einhaengen!
## Log session end: Fri Jun 21 13:27:57 CEST 2019 ##
Ich verstehe nicht, was das da soll:
NTFS signature is missing.
**Failed to mount '/dev/sda': Invalid argument**
**The device '/dev/sda' doesn't seem to have a valid NTFS.**h hier nicht, was das da soll:
kann eigentlich nicht sein, das Image ist 3,4 Gb groß und die Partition ist 55 Gb groß. Waran kannst du das denn sehen? Was mir aber noch auffällt, ist das hier /dev/sda laut log versucht wird einzuhängen.