Univention Bugzilla – Bug 28037
Partitionierung / Imagerollout
Last modified: 2013-03-26 09:14:25 CET
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.
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!)
Wenn das Image auf die Platte/Flash-Speicher geschrieben wird, sollte vor dem Schreiben geprüft werden, ob ausreichend freier Speicher verfügbar ist.
(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
Die Verteilung per Bittorrent ist Teil von Bug #28505. Hier geht es primär um die Partitionierung und die Verteilung per HTTP.
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.
Paritionierung und Image-Rollout funktionieren prinzipiell. In den späteren Milestones werden sich ohnehin noch weitere Anpassungen ergeben, deshalb hier erstmal keine detaillierteren Tests.
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.
(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.
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
(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.
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".