Fedora kickstart bajaim

Red Hat, Fedora, CentOS

Mivel nem találtam nekem megfelelő live linuxot, azt találtam ki, hogy csinálok egyet. Ehhez a Fedora Kickstart eszközét választottam. Igazából az a bajom, hogy nem tudom, hogyan másolhatnék a chroot-olt környezetbe file-okat. Mivel egyelőre shell scriptekről van szó, meg tudom oldani, hiszen írok egy kickstart file-t író szkriptet, amely egész egyszerűen here document-ként beszúrja postinstall scriptként a kívánt scriptjeimet.

A kérdés az, lehet-e ezt elegánsan, normálisan csinálni, netán bináris állományt tudok-e a telepítésembe másolni a post install scriptemből?

Ugye a gond az, hogy a chroot-olt környezetből az azon kívüli világot nem látom, ha jól sejtem, így nem tudom honnan másolni a file-okat.

  • 9260 megtekintés

( zamboriz v | 2013. 03. 31., v – 00:23 )

google kolléga tippje:

--nochroot

Allows you to specify commands that you would like to run outside of the chroot environment.

The following example copies the file /etc/resolv.conf to the file system that was just installed.

%post --nochroot cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf

Szánom-bánom kérdésem, kipróbálom. Más forrásra leltem, amikor Google-t néztem. Azt kipróbálva az image mellé próbálta másolni, amit akartam. Azt hiszem, a lényeg itt a /mnt/sysimage lesz, rögvest kipróbálom. Persze, némi idő, virtuális gépben egy teljes telepítés, miegymás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

/mnt/sysimage könyvtárat még csak nyomokban sem tartalmaz. Így aztán ignorálta a %post scriptemet. Mindegy, most megyek aludni, aztán ha nem lesz jobb megoldás, csinálok egy kickstart template-et, s írok egy scriptet, amelyik a template felhasználásával a kívánt scriptjeimet here documentként beszúrja. Így lesz egy hosszú és áttekinthetetlen, de működő kickstart file-om.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( zamboriz v | 2013. 03. 31., v – 08:53 )

Talán jobb lenne rpm-e(ke)t csinálni a felmásolandó fájlokból. Így akkor sem lesz gond, ha ugyanaz a kickstart hálózatról telepít, nem CD-ről.

Ez valóban talán a legkorrektebb megoldás, csak nem érzek magamban túl sok motivációt hozzá, mert így tanulhatok rpm file-t csinálni, spec file-t írni. Bár, ahogy nézem, ez sem egyéb, mint némi script írás, azzal meg nincs bajom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Különben nem igazán értem, hogy jön ide a telepítési forrás, CD/hálózat. Többnyire hálózatról csinálom, hogy up to date legyen, sőt, a Koji build szerverről letöltöttem a legfrissebb, az update repókban még meg sem jelent 3.8.5-201-es kernelt, s local repót csináltam, majd ezt is megadtam a kickstart konfigban.

A telepítési forrástól független az én nyomorom. Mindenesetre látom a fényt az alagút végén. Maradok a template alapján generált kickstart file-nál, mert ezt érzem egyszerűbbnek, ugyanakkor bináris állománynál rpm-et kellene generálni. Miközben a hozzászólást írom, rájöttem, hogy kell a bináris file átvitele. Ilyen például a háttérkép.

Most akkor vagy rpm-et csinálok, vagy gányolok, s átviszem here documentként base64-ben. Valahogy annyira prüszkölök az rpm készítéstől, hogy bármennyire is gány, amit csinálni készülök, mégis lehet, ezt választom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2013. 04. 02., k – 02:54 )

Csendben jegyzem meg, az elképzelésem működik. Csináltam kickstart template konfig file-t, benne speciális kommentekkel, amelyeket egy bash-ben írt nagyon primitív értelmezővel feldolgoztatok. Ebben szerepel helyettesítés, másfelől megadhatok forrást és célt. A forrás alkönyvtártól kezdve bejárja rekurzívan, amit alatta talál, s ír egy olyan postinstall scriptet, amelyik egyfelől tartalmazza az egyes alkönyvtárak létrehozását (mkdir -p elérési_út), másfelől a forrásban található file-okat base64 kódolással a kickstart file-ba teszi here document-ként, s persze beleírja, hogy ezt base64 dekódolni volna jó, s azt is, hogy hol hozza létre a célfile-t, s milyen névvel.

Generált nekem egy kb. 3 MB-os kickstart file-t, majd azt megemésztettem vele, s előállt a majdnem(*) megfelelő live linux, amelyben már az általam kívánt file-ok a helyükön voltak.

*: Egyelőre majdnem, mert a jogosultságok leírására, a megfelelő chown és chmod parancsok kickstart post-install scriptjébe generálására még ki kell találjak valamit.

:)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2013. 04. 09., k – 16:43 )

Ezt már a live Fedoráról írom. Mindent tud, amit szeretnék, már csak néhány apró bug van benne. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2013. 04. 09., k – 20:36 )

Erősen ontopic kérdésem jön. Live rendszerek többnyire squashfs filerendszert használnak. Ez read-only, eddig rendben is van. Amit nem értek, hogyan tudok telepíteni live rendszeren, illetve a file-ok hova kerülnek. A ramdisk lenne logikus, csak azt nem tudom, hol van ez, mert nem látom.

mount | grep ' / '
/dev/mapper/live-rw on / type ext4 (rw,noatime,seclabel,data=ordered)

ls -l /dev/mapper/live-rw
lrwxrwxrwx. 1 root root 7 ápr 9 19.44 /dev/mapper/live-rw -> ../dm-0

df -h /
Fájlrendszer Méret Fogl. Szab. Fo.% Csatol. pont
/dev/mapper/live-rw 3,9G 2,8G 1,1G 72% /

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

http://fedoraproject.org/wiki/LiveOS_image

".. use of device mapper snapshots to combine a read-only file system image (copied from the compressed SquashFS.img on the read-only LiveCD or installation .iso file) with a Copy-on-write service that tracks only changed blocks of data in the snapshot (overlay) file and then re-referencing file pointers to the updated blocks."

( locsemege v | 2013. 05. 02., cs – 01:31 )

Megcsináltam 3.8.11-es kernellel a live Fedorámat. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE