Bug 28037 - Partitionierung / Imagerollout
Partitionierung / Imagerollout
Status: CLOSED FIXED
Product: Univention Corporate Client (UCC)
Classification: Unclassified
Component: General
unspecified
Other Linux
: P5 enhancement
: UCC 1.0
Assigned To: Stefan Gohmann
Felix Botner
: interim-2
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-23 17:26 CEST by Stefan Gohmann
Modified: 2013-03-26 09:14 CET (History)
4 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2012-07-23 17:26:56 CEST
Folgendes Verhalten ist geplant:

Wenn ein Image gestartet wird, so gibt es am Bootloader eine Auswahl, ob das Image installiert oder gestartet werden soll. Bei einem Boot aus dem Netzwerk kann dieses Verhalten über das Managementsystem gesteuert werden.

Beim Boot kann dann in der initrd eine Installation auf die lokale Festplatte erfolgen. Das läuft ähnlich ab, wie beim aktuellen Flash in Flash Update in TCS. Allerdings wird das Image als BitTorrent Image auf einer Partition  abgelegt. Das System bindet dieses Image r/w ein und startet das System.
Wenn für das System kein neues Image verfügbar ist, so wird das Image nicht überschrieben und die lokalen Änderungen bleiben erhalten.

Die Benutzerdaten liegen auf einer eigenen Partition. Die Paritionierung ist im Image hinterlegt und sollte nachfragen, ob partitioniert werden soll. Die Partitionierungsangaben im Image sollten Werte in Prozent sein. Über eine Bootoption muss die Nachfrage, ob Partitioniert werden soll, übersprungen werden können.

In einer Config Partition sollte der Join Status und ggf. andere spezifische Daten abgelegt werden.

Im ersten Schritt sollte geprüft werden, ob BitTorrent für eine solche Verteilung möglich und sinnvoll ist.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2012-08-15 18:05:28 CEST
Auf einem HPt5735 (1GHz; 1GB RAM; 1GB Flash) wurde eine SystemRescueCD via USB-Stick gebootet und dann per scp rtorrent und die erforderlichen Libraries draufkopiert. 

Tracker und Seeder war eine KVM-Instanz auf utby mit rtorrent. 
Übertragen wurde ein 381MB ISO-Image.

Initialer Download der 381MB Server → Client: ca. 60 Sekunden.
Anschließende Neuberechnung des Dateihashes auf dem Client: ca. 6 Sekunden

Nach dem Download wurden Buffercache und Inodeinformationen im Speicher verworfen:
echo 3 > /proc/sys/vm/drop_caches

Anschließende Neuberechnung des Dateihashes (381MB): ca. 23 Sekunden
Anschließende Neuberechnung des Dateihashes (381MB): ca. 5 Sekunden

Der Upload des Images Thinclient → performanter Server:
ohne Verwerfen des Dateicaches: ca. 6 Sekunden
mit Verwerfen des Dateicaches: ca. 23 Sekunden (ohne vorheriges Rehashing!)
Comment 2 Moritz Muehlenhoff univentionstaff 2012-09-14 12:24:20 CEST
Wenn das Image auf die Platte/Flash-Speicher geschrieben wird, sollte vor dem Schreiben geprüft werden, ob ausreichend freier Speicher verfügbar ist.
Comment 3 Moritz Muehlenhoff univentionstaff 2012-09-14 12:24:54 CEST
(In reply to comment #2)
> Wenn das Image auf die Platte/Flash-Speicher geschrieben wird, sollte vor dem
> Schreiben geprüft werden, ob ausreichend freier Speicher verfügbar ist.

-> Bug 20705
Comment 4 Stefan Gohmann univentionstaff 2012-10-19 09:33:54 CEST
Die Verteilung per Bittorrent ist Teil von Bug #28505. Hier geht es primär um die Partitionierung und die Verteilung per HTTP.
Comment 5 Stefan Gohmann univentionstaff 2012-10-30 10:58:30 CET
Das Verfahren ist jetzt wie folgt umgesetzt:

Das Image Toolkit erzeugt einen Kernel, eine Initrd und ein Image. Zusätzlich erstellt das Toolkit ein ISO Image, welche per DVD oder USB Stick gestartet werden kann. Später soll auch ein Debian Paket erstellt werden: Bug #28033

Initrd, Kernel und Image müssen derzeit im Verzeichnis /var/lib/univenton-boot abgelegt werden. Das Image Toolkit erstellt auch eine register-Datei, damit kann das Image im Managementsystem registriert werden.

Einem UCC Client kann dann per UMC ein Image zugeordnet werden. Wird kein Image zugeordnet, so kann die UCR Variable ucc/pxe/image gesetzt werden. Dann wird der Wert per Default verwendet, beispielsweise:
 ucr set ucc/pxe/kernel=ucc-thinclient-v1.img.kernel
Das Listener Modul uccpxeboot erstellt dann entsprechend eine PXE Bootdatei.

Zusätzlich kann für einen UCC Client die Bootvariante ausgewählt werden. Im Moment kann zwischen den folgenden Werten gewählt werden:
 - none 
   → es wird normal gestartet, ohne das ein Image Update getestet wird
 - overlayfs 
   → ein Live-System, alle Änderungen werden verworfen
 - update 
   → Update des Images falls das Image auf der Server Seite aktualisiert wurde und Neuinstallation falls noch kein Image ausgerollt wurde. Im Update Fall wird nicht neu partitioniert.
 - rollout 
   → wie update, nur dass am Ende noch der Join durchgeführt wird
 - installation 
   → eine erneute Installation, auch wenn schon eine Installation vorhanden ist. Es wird auch neu partitioniert. Lokale Daten, auch auf /home gehen verloren!


Im Image ist hinterlegt, wie die Partitionierung durchgeführt werden soll. Es muss auf jeden Fall eine eigene Bootpartition geben, da ansonsten die Kernel Aktualisierung nicht funktioniert. Grub müsste sonst das Image mounten und den Kernel dort booten.
Dadurch das /boot eine eigene Partitionierung ist, funktioniert es aber sehr gut, weil eine Kernel Aktualisierung innerhalb des Images die Daten auf die Bootpartition schreibt.


Wenn das Image auf das System kopiert wird, so wird im ersten Schritt partitioniert. Sämtliche Schritte erfolgen dabei in der initrd. Bevor die Partitionierung gestartet wird, gibt es eine Sicherheitsabfrage. Das Kopieren erfolgt derzeit per rsync. Die Daten liegen anschließend auf der im Image angegeben root-Partition. Es werden auf dem System noch weitere Dateien abgelegt:
 - local_image
   → die Datei beinhaltet den Namen des lokal kopierten Images
 - local_image.md5
   → die MD5 Summe des lokalen Images das kopiert wurde
 - <das eigentliche Image>
   → das Image, in das später gebootet wird
 - ucc_root_device
   → eine leere Datei, durch die erkannt wird, dass dies ein UCC Root Device ist

Ein Image wird im Update Fall nur kopiert, wenn die Upstream MD5 Summe nicht mit der lokal gespeicherten MD5 Summe übereinstimmt. Da das System später beim Booten das lokale Image verändert, wird eine lokale MD5 Summe unterschiedlich sein, deshalb wird die MD5 Summe beim Kopieren des Images lokal auf dem UCC Client mit gespeichert.

Auf dem gestarteten UCC Client ist das lokale root Dateisystem unter /ucc_root eingebunden. Wenn man dort die MD5 Summe ändert, dann wird auf jeden Fall beim nächsten Boot ein Image Update durchgeführt.

Beim Image Update werden die UCR Einstellungen und die Dateien kopiert, die per univention-ucc-manage-persistent registriert wurden.

Das Image Update kann entweder erfolgen, wenn aus dem Netz gebootet wird oder aber wenn vom lokalen System gestartet wird. Wenn vom lokalen System gestartet wird, dann muss das Image aber gejoint sein, da der UCC Client die Einstellung nicht per Boot cmdline übergeben bekommt. Dieser Punkt ist noch nicht umgesetzt: Bug #28972.

Ein Debug der initrd ist nicht ganz einfach. Eine Möglichkeit ist es mit boot=ucc und ucc=debug zu starten. Anschließend kann man das Skript /scripts/ucc bearbeiten und die einzelnen Funktionen aufrufen.
Comment 6 Moritz Muehlenhoff univentionstaff 2012-10-31 14:59:58 CET
Paritionierung und Image-Rollout funktionieren prinzipiell. In den späteren Milestones werden sich ohnehin noch weitere Anpassungen ergeben, deshalb hier erstmal keine detaillierteren Tests.
Comment 7 Kevin Dominik Korte univentionstaff 2012-11-12 13:53:03 CET
Die Config Angabe type wird nicht verwendet. Im Installationsscript wird anstelle dessen die Option Name ausgewertet, was zu einer Fehlermeldung während der Partitionierung führt.
Comment 8 Stefan Gohmann univentionstaff 2012-11-23 10:15:25 CET
(In reply to comment #7)
> Die Config Angabe type wird nicht verwendet. Im Installationsscript wird
> anstelle dessen die Option Name ausgewertet, was zu einer Fehlermeldung während
> der Partitionierung führt.

Das wird jetzt berücksichtigt.
Comment 9 Felix Botner univentionstaff 2013-01-03 18:07:53 CET
QUESTIONS:

Sollten wird vielleicht im toolkit Paket ein Beispiel für sbin/custom_partition mitbringen?

Ich habe das mit folgendem getestet:

partition_device="$1"
parted -s "${partition_device}" mklabel GPT
disk_size=$(/sbin/parted -s "${partition_device}" unit MB print | sed -ne "s|^Disk ${partition_device}: ||;s|MB$||p")
type="primary"
parted -s "${partition_device}" mkpart "$type" "10" "60"
parted -s "${partition_device}" set 1 bios_grub on
parted -s "${partition_device}" mkpart "$type" "61" "161"
parted -s "${partition_device}" mkpart "$type" "162" "$disk_size"
/sbin/mkfs.ext3 "${partition_device}2"
/sbin/mkfs.ext3 "${partition_device}3"
mkdir -p /ucc_tmp/root
mkdir -p /ucc_tmp/boot
mount "${partition_device}3" /ucc_tmp/root
touch /ucc_tmp/root/ucc_root_device
echo "/dev/loop0    /   ext3   errors=remount-ro   0   1" >>/ucc_tmp/fstab
echo "${partition_device}2     /boot ext3 defaults    0   2" >>/ucc_tmp/fstab
echo "${partition_device} ext3 /boot" >> /ucc_tmp/copy_files



Partitionierung:

Klappt soweit, die Standard-Images lassen sich auf einer leeren Platte und auf einer bereits partitionierten Platte installieren. Anpassungen an der Image Config bzgl. der Partitionierung werden angewendet

device: vda
remove_partitions:
 vda1
 vda2
 vda3

partition1_name: efi
partition1_size: 10
partition1_flags: bios_grub
partition1_image_mount: false
partition1_copy_files: false

partition2_name: boot
partition2_size: 50
partition2_fs: ext4
partition2_mountpoint: /boot
partition2_image_mount: true
partition2_copy_files: true

partition3_name: root
partition3_size: 10000
partition3_fs: ext4
partition3_mountpoint: /
partition3_image_mount: false

partition4_name: home
partition4_size: expand
partition4_fs: vfat
partition4_mountpoint: /home
partition4_image_mount: true

Falls es ein sbin/custom_partition, wird dieses verwendet.

Imagerollout:

LiveSystem, Rollout (mit bzw. ohne vorherig installiertes System), (re)Installation und Update klappen prinzipiell. Beim Update gibt es noch ein Problem, das wird jedoch an Bug #28972 behoben.

Falls kein Boot Verfahren ausgewählt ist (ucc=none) wird ohne update etc das lokal installierte System gestartet
Comment 10 Stefan Gohmann univentionstaff 2013-01-07 07:09:10 CET
(In reply to comment #9)
> QUESTIONS:
> 
> Sollten wird vielleicht im toolkit Paket ein Beispiel für sbin/custom_partition
> mitbringen?

Ja, steht jetzt an Bug #29138.
Comment 11 Moritz Muehlenhoff univentionstaff 2013-03-26 09:14:25 CET
UCC 1.0 has been released: 
http://forum.univention.de/viewtopic.php?f=26&t=2417
http://forum.univention.de/viewtopic.php?f=54&t=2418

If this error occurs again, please use "Clone This Bug".