Copyright (c) 1998 Martin Hamilton, Alle rechten gereserveerd. Dit is vrije documentatie; je kunt het onder de voorwaarden van versie 2 of later van de opnieuw distribueren en/of aanpassen.

Als je aan dit document via een Linux HOWTO mirrorsite of een CD-ROM bent gekomen, wil je wellicht de er nog op nazien of hier een nieuwere versie van in omloop is.

RedHat Linux versie 5 komt met een weinig bekend (en tot nu, niet erg gedocumenteerde) faciliteit genaamd KickStart. Hiermee kun je (bijna) alles van de RedHat Linux installatie automatiseren, waaronder: Selecteren van de taal Netwerkconfiguratie en selecteren van de distributiebron Toetsenbordkeuze Bootloader installatie (b.v. lilo) Diskpartitionering en aanmaak bestandssysteem Muiskeuze X Window systeem serverconfiguratie Keuze van de tijdszone Keuze van een (initieel) root wachtwoord Welke packages te installeren

Scherpzinnige RedHat gebruikers zullen zich inmiddels waarschijnlijk hebben gerealiseerd dat dit in belangrijke mate de hoofdstappen zijn die een handmatige installatie van een RedHat Linux systeem inhouden. KickStart maakt het je mogelijk een script te schrijven voor het reguliere installatieproces, door de informatie die je normaal gesproken op het toetsenbord op zou geven in een configuratiebestand te plaatsen.

Maar wacht - er is meer :-)

Na het normale installatieproces te hebben beëindigd, laat KickStart je ook een lijst specificeren met opdrachten op niveau van de shell die je zou willen hebben uitgevoerd. Dit betekent dat je automatisch extra lokale software kunt installeren die niet als onderdeel van RedHat Linux wordt gedistribueerd (ja, er zijn zelfs meer vrij verkrijgbare softwareprogramma's dan datgene dat je bij de RedHat distributie krijgt. Een aantal kunnen vanwege wettelijke gronden niet door RedHat worden gedistribueerd, b.v. de ssh en PGP encryptie systemen). Mogelijk heb je die nodig voor een volledig functioneel besturingssysteem.

Er zijn twee benaderingen bij een KickStart installatie - één daarvan is eenvoudigweg je KickStart configuratiebestand naar een RedHat bootdiskette kopiëren. De andere is gebruik te maken van een reguliere bootdiskette en je Kickstart configbestand via het netwerk ophalen.

In beiden gevallen heb je nodig:

Intel (i386) klasse computers - waarmee KickStart alleen schijnt te werken tijdens moment van schrijven. KickStart configbestand - hier zullen we het in de volgende sectie over hebben. RedHat bootdisk - bij voorkeur uit de updates directory, om voordeel te hebben van eventuele correcties/updates van drivers. DNS records voor de IP-adressen die je zal gaan gebruiken - optioneel, maar zal de installatie onderbreken doordat het je vraagt naar de domeinnaam van je computer.

Als je je configbestand over het netwerk op wilt halen, zal je het via NFS moeten exporteren, dit is de enige toegangsmethode die op het moment wordt ondersteund. Het configbestand laat je een andere NFS server specificeren waar het de RedHat distributie zelf van ophaalt.

Je kunt voor je computer een statisch IP-adres configureren - b.v. een speciaal adres gereserveerd voor KickStart installaties. Als alternatief kun je KickStart opgeven een BOOTP/DHCP server te gebruiken om het IP-adres op te halen als je het niet als vaststaand adres in het configbestand wilt coderen. Een aantal servers zal nieuwe adressen in een gegeven bereik automatisch toewijzen, zoals b.v. .

Meer informatie over NFS en BOOTP/DHCP is te vinden in Appendix A.

In essentie is alles wat je moet doen je KickStart configbestand naar /ks.cfg op de RedHat bootdiskette kopiëren, b.v. mcopy ks.cfg a: De RedHat bootdiskette is echter tamelijk vol, en wellicht bemerk je dat je een aantal van de andere bestanden moet verwijderen om ruimte te maken voor het KickStart configbestand. Het lukte mij voldoende ruimte vrij te maken door de diverse berichtbestanden te verwijderen die normaal gesproken worden weergegeven door de SYSLINUX bootloader, b.v.

mdel a:\*.msg Een andere benadering zou kunnen zijn de drivers voor een deel van de hardware die je toch niet hebt weg te gooien, zie de sectie over het aanpassen van de bootdiskette hieronder. Wellicht dat je ook syslinux.cfg, het SYSLINUX configbestand wilt wijzigen. Ook deze is op de RedHat bootdiskette in de top level directory terug te vinden. De volgende syslinux.cfg bijvoorbeeld zal er voor zorgen dat automatisch, zonder de normale onderbreking, de KickStart mode wordt ingegaan als de computer opstart: default ks prompt 0 label ks kernel vmlinuz append ks=floppy initrd=initrd.img

Naar alle waarschijnlijkheid wil je je boot- en aanvullende diskettes baseren op de meest recente diskimages die beschikbaar zijn in updates/i386 op je lokale RedHat mirrorsite. Oudere images kunnen fouten bevatten of bieden minder ondersteuning voor hardwaredrivers.

Het configbestand bestaat uit drie hoofdsecties:

Systeem info, b.v. diskpartitionering en netwerkconfig Te installeren RedHat packages Post-installatie uit te voeren shellopdrachten

Er zijn nog een aantal andere mogelijkheden waar we het hier niet over zullen hebben, maar die wellicht wel werken. Kijk voor meer informatie in het voorbeeld KickStart config in misc/src/install/ks.samp en doc/README.ks onder de top level i386 RedHat distributie directory op je CD-ROM of lokale RedHat mirror site.

Boot zoals gewoonlijk vanaf je RedHat bootdiskette de computer waarop RedHat zal worden geïnstalleerd, maar in plaats van het indrukken van de RETURN achter de SYSLINUX prompt tik je linux ks in.

Als je geluk hebt, is dit alles wat je in hoeft te tikken!

Als je de RedHat bootdiskette zoals hierboven uiteengezet hebt aangepast, hoef je zelfs dit niet te doen :-)

Aangezien we slechs de normale stappen van een RedHat installatie aan het automatiseren zijn, zullen de normale dialogen verschijnen als/wanneer KickStart niet meer weet wat het vervolgens moet doen. In het meest waarschijnlijke geval zal je netwerkinterface niet onmiddellijk automatisch worden gedetecteerd en zal je worden gevraagd naar het IRQ en I/O-adres. KickStart heeft meestal hulp nodig bij ISA-kaarten, en detecteert PCI-kaarten automatisch.

Je kunt zoals gewoonlijk door het wisselen van virtuele consoles in de gaten houden wat KickStart aan het doen is:

Alt-F1 - installatie dialoog Alt-F2 - shellprompt Alt-F3 - installatielog (meldingen van het installatieprogramma) Alt-F4 - systeemlog (meldingen van de kernel, enz.) Alt-F5 - andere meldingen

De RedHat bootdisk boot.img is in het MS-DOS formaat en maakt gebruik van het SYSLINUX programma om te booten. De aanvullende disk supp.img is een Linux ext2 bestandssysteem. Je kunt deze bestanden beiden aan je bestandssysteem mounten en ze hacken als je in je Linux-kernel ondersteuning hebt voor het loopback bestandssysteem:

# mkdir -p /mnt/boot /mnt/supp # mount -o loop -t msdos boot.img /mnt/boot # mount -o loop supp.img /mnt/supp

Nu zou je de bestanden op de boot- en aanvullende disk onder respectievelijk de /mnt/boot en /mnt/supp moeten kunnen zien. Hè! Mogelijk kunnen oudere versies van mount de optie -o loop niet hanteren. In deze gevallen moet je expliciet gebruik maken van losetup om voor ieder bestand het loopback device te configureren, b.v.

# losetup /dev/loop0 boot.img # mount -t msdos /dev/loop0 /mnt/boot

Wellicht dat je expliciet de optie -t ext2 op moet geven bij het mounten van een ext2 bestandssysteem zoals hetgeen op de aanvullende disk. Maar het ziet ernaar uit dat mensen met moderne Linux distributies zich hier geen zorgen over hoeven maken.

Als je het niet te moeilijk wilt maken, dan kun je dit altijd omzeilen, en echte diskettes manipuleren in plaats van deze diskette-images.

Als je wat met de installatieprocedure zelf wilt aanrommelen, de broncode is te vinden op de RedHat CD-ROM of je lokale RedHat mirrorsite. Het bevindt zich in de misc/src/install onder de toplevel directory van de i386 distributie.

Als je de RedHat bootdisk bestudeert, zul je zien dat er naast de Linux kernel vmlinuz, een groot bestand initrd.img is:

- -rwxr-xr-x 1 root root 559 May 11 15:48 boot.msg - -rwxr-xr-x 1 root root 668 May 11 15:48 expert.msg - -rwxr-xr-x 1 root root 986 May 11 15:48 general.msg - -rwxr-xr-x 1 root root 968842 May 11 15:48 initrd.img - -rwxr-xr-x 1 root root 1120 May 11 15:48 kickit.msg - -r-xr-xr-x 1 root root 5352 May 11 15:48 ldlinux.sys - -rwxr-xr-x 1 root root 875 May 11 15:48 param.msg - -rwxr-xr-x 1 root root 1239 May 11 15:48 rescue.msg - -rwxr-xr-x 1 root root 402 May 11 15:48 syslinux.cfg - -rwxr-xr-x 1 root root 444602 May 11 15:48 vmlinuz

Je raadde het al, dit is een ander ext2 bestandssysteem dat als een bestand is opgeslagen --- maar met een handigheidje. Het is in feite ook gecomprimeerd. Je kunt het decomprimeren en het resultaat ervan mounten, b.v.

# gzip -dc /mnt/boot/initrd.img >/tmp/initrd.ext2 # mkdir /mnt/initrd # mount -o loop /tmp/initrd.ext2 /mnt/initrd

Waarschijnlijk het belangrijkste onderdeel van dit bestandssysteem is de verzameling laadbare kernelmodules die in de bootdisk is opgenomen. Als je een nieuwe driverversie hierin op wilt nemen, dan moet je of vmlinuz door een nieuwe kernel vervangen, welke statisch is gelinkt, of het in de verzameling modules vervangen. Bovendien moet je wellicht andere modules verwijderen om plaats te maken.

Het bestand modules/modules.cgz bestaat uit de verzameling modules. Vraag je je af wat dat zou kunnen zijn? In feite is het een gecomprimeerd cpio archief, geloof het of niet! En je dacht dat niemand cpio nog gebruikte... Zelfs RPM maakt intern nog gebruik van cpio Zo kun je er wat mee rommelen:

# gzip -dc /mnt/initrd/modules/modules.cgz >/tmp/modules.cpio # cpio -itv modules.listing # mkdir modules # cpio -idumv <../modules.cpio Ik denk dat er thans onder Linux geen manier is (tenminste in hoofdstroom distributies) om transparant gecomprimeerde bestandssystemen te benaderen. Laat het me weten als je meer weet!

Denk aan het volgende als je wijzigingen aanbrengt:

Maak voor het opnieuw aanmaken van het archief gebruik van cpio. Hoe je dit doet wordt als oefening aan de lezer overgelaten... Gebruik gzip om het resulterende archief te comprimeren. Kopieer het naar /mnt/initrd, of waar je je ongecomprimeerde initrd.img archief dan ook plaatst. Unmount /mnt/initrd (of hoe je het ook noemde). Comprimeer het nieuwe initrd.img wederom met gzip. Kopieer het resulterende archief naar de bootdisk-image - in ons voorbeeld /mnt/boot/initrd.img. Unmount de bootdisk-image, b.v. /mnt/boot.

Tenslotte kun je met deze aangepaste bootdisksetup nieuwe bootdiskettes aanmaken, b.v.

# cat boot.img >/dev/fd0

V: Na de KickStart installatie boot mijn computer niet. De BIOS geef een melding als Missing operating system.

A: Het lijkt erop dat de partitie met het rootbestandssysteem niet opstartbaar is. Gebruik fdisk om naar de opstartbare status over te schakelen.

V: Na de disketteboot, krijg ik de melding: Error opening files for kickstart copy: File exists.

A: Gebruik een recentere versie van de boot.img en supp.img - kijk in de directory updates van je lokale RedHat mirror site. Een aantal oudere versies hiervan voor RedHat 5.1 bevatte een fout.

V: Kun je ook alle uitstaande patches (bijgewerkte RPM's) automatisch toepassen? Hoe?

A1: Kopieer de RPM's die je wilt installeren naar de RPMS directory van waaruit de installatie plaats gaat vinden, zie dat je van de oudere RPM's afkomt, en werk het bestand RedHat/base/hdlist bij met de nieuwe RPM details. Zie Appendix C voor een script van Eric Doutreleau dat dit voor je doet. Als je het zelf doet, denk er dan aan daarna genhdlist uit te voeren!

A2: Probeer dit Perl-script: . Het vergelijkt de RPM's die op je systeem zijn geïnstalleerd met die in een voorgestelde directory en rapporteert over degenen waarvan wordt verondersteld dat ze moeten worden bijgewerkt. Ze kunnen zelfs worden geïnstalleerd als je dat het script toevertrouwd.

A3: heeft een krachtiger (12MB C code vs. een Perl pagina!) versie van A2.

V: Een enkel config bestand op de installatieserver voor alle clients, misschien als een uitwijkmogelijkheid na het uitproberen van IPADDR-kickstart ?

A1: Gebruik de BOOTP/DHCP 'boot file' parameter bf om de bestandsnaam in te stellen.

A2: Voeg een record bf=/kickstart/ks.cfg toe aan de relevante ingang in /etc/bootptab.

V: Meer flexibiliteit wanneer er iets mis gaat - b.v. vraag naar de alternatieve lokaties als de distributie niet op de CD-ROM is te vinden.

A: ?

V: Expliet uitsluiten van packages - b.v. alles behalve sendmail.

A: Zet het BASE package opnieuw op zonder sendmail.

V: Kies welke services automatisch worden gestart bij de systeemstart door de runlevel scripts onder /etc/rc.d/.

A: Het chkconfig utility laat je configureren welke services automatisch tijdens het booten worden uitgevoerd. Je kunt het volgende in je post-installatie scriptsectie uit laten voeren, b.v. voor het uitvoeren van ypbind in run levels 3, 4 en 5:

chkconfig --level 345 ypbind on

en het zal de ypbind level op de 345 level starten.

V:Laat uitvoer op een andere virtuele console verschijnen bij de uitvoering van shellopdrachten in de %post sectie, in plaats van het hoofdscherm te overschrijven. Zou kunnen worden gedaan in de sectie shellopdrachten met open?.

A: Geen probleem - doe bijvoorbeeld dit:

exec >/dev/tty5

V:Controleert de aanmaakcode voor het bestandssysteem op slechte blokken?

A: Als je naar de virtuele console overschakelt waarop de uitvoer van de aanmaak van het bestandssysteem wordt weergegeven, zie je geen enkele vermelding van de uit te voeren 'read-only' test. Het lijkt erop dat het antwoord 'nee' is.

V:Kan ik het zo regelen dat een aantal machines anders worden geconfigureerd dan anderen?

A: Je zou de host afhankelijke gegevens in de script sectie van de KickStart configuratie kunnen plaatsen - b.v. alleen een gegeven RPM op een gegeven machine installeren. Het zou handig zijn als er een voorwaardelijke installatiefaciliteit in de packages sectie van het configuratiebestand was, b.v. overschakelen bij een andere architectuur, of bij een hostnaam/domein naam/IP-adres.

V:Zijn er wijzigingen tussen RedHat 5.1 en 5.2 ?

A1: Veel wijzigingen in het installatieprogramma, maar voornamelijk correcties op programmeerfouten en cosmetische verbeteringen. Geen impact op KickStart zover als ik je kan zeggen - van een diff -rcs van de twee misc/src/install directory's.

A2: RH5.2 heeft nu blijkbaar de automatische IP toekenning/DHCP patches voor bootpd opgenomen, maar ze hebben de documentatie achterwege gelaten waarin wordt aangegeven hoe je het gebruikt.

V: (Hoe) kun je een specifieke partitie of partities wissen? b.v. /home behouden maar / legen.

A: Dit kan (nog) niet!

V:Kun je het zo regelen dat je partities op meerdere drives worden aangemaakt? b.v. / op sda en /home op sdb.

A: Ik denk van niet - het ziet ernaar uit dat je alleen toegang krijgt tot de eerste drive vanuit het partitionerings hulpmiddel.

V:Is het mogelijk bestaande partities op te laten nemen in de mounttabel, of is het alleen mogelijk de aanmaak van nieuwe partities te specificeren die dan zullen worden opgenomen?

A: ?

V: Waar is het bestand dat wordt aangemaakt bij de uitvoering van mkkickstart?

A: Het maakt geen bestand aan - het dumpt de KickStart configuratie naar stdout.

V: In de virtuele console 4 (Alt-F4) krijg ik Unable to load NLS charset cp437(nls_cp437). Wat betekent dit? Moet ik me zorgen maken?

A: Het lijkt erop dat je aan het proberen bent een CD-ROM gebrand met het Joliet (Unicode uitbreidingen op ISO 9660) bestandssysteem te mounten. In theorie zijn de bestandsnamen op de CD-ROM wellicht bewerkt en komen ze niet correct over onder Linux. In praktijk schijnt het geen problemen te veroorzaken - zou een onechte afhankelijkheid kunnen zijn?

V:Waarom wordt het X Window Systeem geïnstalleerd? Ik plaatste het niet in mijn lijst met packages.

A: De XFree86-VGA16 RPM is een 'basiscomponent', en wordt als zodanig altijd geïnstalleerd - tenzij je de definitie van de basisklasse wijzigt.

V: Kan ik in mijn post-installatie script de packages gebruiken die inmiddels zijn geïnstalleerd om geweldige dingen mee uit te halen die niet mogelijk zijn met de beperkte tools op de diskettes?

A: Ja - b.v. als je ervoor kiest Perl te installeren wanneer je de KickStart config samenstelt, is bijna alles mogelijk in ongeveer vijf regels :-)

Met dank aan Eric Doutreleau voor de info betreft chkconfig, de hack voor het configuratiebestand SYSLINUX, en het Perlscript voor het bijwerken van de RPM's op de distributieserver. Met dank aan Robert Kaminsky voor het uitgebreide onderzoek. Met dank aan Piete Brooks, Flavia Regina Munhoz, Tom Toffoli, Bob Robbins, Charlie Brady en Ragen Herrington, voor hun opmerkingen en vragen.

Als je je afvraagt wat in hemelsnaam deze BOOTP en DHCP zooi is, is meer informatie beschikbaar op de . NFS wordt in de NFS-HOWTO apart gedocumenteerd en er is ook een DHCP mini-HOWTO. Ik heb getracht voldoende details aan te leveren zodat je ermee kunt beginnen, maar heb de onderwerpen niet al te diepgaand behandeld - laat het me weten als je denkt dat dit een beetje te veel van het goede is.

In de BOOTP/DHCP + NFS configuratie die we gaan bespreken, zou het KickStart configuratiebestand via NFS te mounten moeten zijn door de machine van waaraf wordt geïnstalleerd /kickstart/IPADDR-kickstart op de BOOTP/DHCP server, waar IPADDR het IP-adres is van de nieuwe machine, b.v. /kickstart/198.168.254.254-kickstart voor de machine 198.168.254.254.

Je zou deze lokatie moeten kunnen overschrijven door de bf parameter (boot file) in je BOOTP/DHCP response te retourneren. Wellicht dat het zelfs mogelijk is deze via NFS geheel vanaf een andere machine te mounten.

Maak het bestand /etc/exports aan met een volgende vergelijkbare inhoud om een aantal directory's voor NFS vanaf een bestaande Linux-box te exporteren:

/kickstart *.swedish-chef.org(ro,no_root_squash) /mnt/cdrom *.swedish-chef.org(ro,no_root_squash)

Als je het IP-adres dat je met DNS gaat gebruiken niet hebt geregistreerd dan kan het zijn dat wordt aangegeven dat de NFS-server en/of de RPC portmapper het aflegt. Je kunt dit waarschijnlijk voorkomen door de IP-adres/netmask paren in de configuratiebestanden te plaatsen, b.v.

/kickstart 198.168.254.0/255.255.255.0(ro,no_root_squash)

en in /etc/hosts.allow:

ALL: 194.82.103.0/255.255.255.0: ALLOW

Dit komt doordat de meeste Linux-distributies gebruik maken van TCP-wrappers voor een aantal of alle aan NFS gerelateerde daemons voor het toegangsbeheer. De syntax van /etc/exports kan op andere Unix-varianten anders zijn - de NFS-servers gebundeld met Linux-distributies bieden gewoonlijke een veel breder bereik aan opties dan die met andere Unix-versies worden geleverd.

Als je in je KickStart configuratiebestand een rootwachtwoord opneemt, of via NFS, directory's met gevoelige informatie exporteert, zal je ervoor moeten zorgen dat je deze informatie aan zo weinig mogelijk mensen blootstelt. Dit kun je bewerkstelligen door de NFS exportpermissies zo verfijnd mogelijk in te stellen, b.v. door een bepaalde host of een bepaald te exporteren subnet te specificeren in plaats van een geheel domein. Het is allemaal mooi en simpel als je een speciaal IP-adres voor KickStart installaties vrijhoudt, behalve als je het later moet wijzigen - of de machine opnieuw moet configureren om het IP-adres via BOOTP/DHCP te krijgen.

De meeste NFS-servers vereisen dat je mountd en nfsd (onder een aantal Unix-versies worden deze opdrachten voorafgegaan door rpc.) te kennen geeft dat het bestand /etc/exports is gewijzigd - gewoonlijk doe je dit door een SIGHUP te verzenden. Er is vaak een programma of script genaamd exportfs die dit voor je doet, b.v.

# exportfs -a

Wellicht dat de directory's niet automatisch worden geëxporteerd wanneer NFS na het booten van de machine niet werkend en draaiend was. Probeer te rebooten, of start als root de volgende programma's op:

# portmap # rpc.nfsd # rpc.mountd

Zoals opgemerkt, wordt op een aantal systemen het voorvoegsel rpc. niet gebruikt. Onder de meeste moderne Unix-distributies zijn deze programma's te vinden in de directory's /usr/sbin of /usr/libexec. Wellicht dat deze zich nog niet in je pad bevinden, b.v. als je su gebruikte om root te worden. Het programma portmap wordt soms ook rpcbind genoemd, b.v. onder Solaris, is voor een aantal versies van nfsd vereist dat met een opdrachtregelopdracht het aantal uit te voeren kopieën van de server wordt opgegeven, en het kan zijn dat je bemerkt dat je ook een andere daemon met de naam biod moet draaien. Het bovenstaande zou voldoende moeten zijn op (bijna?) alle Linux systemen.

Als je gebruikt maakt van de CMU BOOTP server en dynamische adresseringsextensies waarnaar eerder werd gerefereerd, dan zou een voorbeeld /etc/bootptab record (/etc/bootptab is de normale lokatie van het BOOTP/DHCP configuratiebestand) er ongeveer zo uit zien:

.dynamic-1:ip=198.168.254.128:T254=0x30:T250="ds=198.168.254.2: dn=swedish-chef.org:sm=255.255.255.0:gw=198.168.254.1: dl=0xFFFFFFFF":

Hiermee wordt aangegeven IP-adressen dynamisch toe te kennen bij het aantreffen van nieuwe machines, te beginnen bij 198.168.254.128 en verdergaand voor de volgende 48 (de hexidecimale waarde is 30) adressen. Iedere client zal de waarde T250 teruggeven. In dit geval wordt hiermee ingesteld:

de DNS server ds op 198.168.254.2 de domeinnaam dn op swedish-chef.org de subnetmask sm op 255.255.255.0 de standaardgateway gw op 198.168.254.1 de lease lengte dl (hoelang het adres geldig is) op "forever"

Er schijnen een aantal andere verseis van deze server in omloop te zijn die de dynamische adressering niet ondersteunen. Hiervoor zou je een opsomming moeten geven van de hardware (typisch de Ethernet MAC) adressen van iedere te-installeren machine in /etc/bootptab, en de regels zouden er dan ongeveer zo uit zien:

bork.swedish-chef.org:ip=198.168.254.128:ha=0000E8188E56: ds=198.168.254.2:dn=swedish-chef.org:sm=255.255.255.0: gw=198.168.254.1:dl=0xFFFFFFFF":

De parameter ha correspondeert met het hardware-adres van de computer waarop wordt geïnstalleerd.

Het RPM pakketformaat is reeds zeer goed gedocumenteerd, in het bijzonder in het boek Maximum RPM van Ed Bailey, wat je kunt downloaden vanaf de - tevens beschikbaar via alle goede boekwinkels! Dit zijn slechts een paar aanwijzingen voor mensen die haast hebben.

RPM packages worden samengesteld vanuit een spec bestand. Dit bestaat (op een vergelijkbare wijze als het KickStart configbestand) uit voorgeschreven stappen die moeten worden genomen om het package samen te stellen. Er wordt vanuit gegaan dat je het vanaf de bron op moet bouwen, mogelijk voor meerdere platformen, en waarbij wellicht patches voor het compileren moeten worden toegepast. Eenmaal samengesteld en geïnstalleerd zal een binaire RPM worden aangemaakt uit de bestanden en directory's die je opgeeft als zijnde geassocieerd met het package. Het is belangrijk er notitie van te nemen dat RPM er geen idee van heeft welke bestanden en directory's aan een gegeven package zijn gerelateerd - je moet dit opgeven. Hier is een voorbeeldspecificatie voor een aangepaste RPM van de :

Summary: Squid Web Cache server Name: squid Version: 1.NOVM.22 Release: 1 Copyright: GPL/Harvest Group: Networking/Daemons Source: squid-1.NOVM.22-src.tar.gz Patch: retry-1.NOVM.20.patch %description Dit is slechts een eerste probeersel om de Squid Web Cache in te pakken voor een eenvoudige installatie op onze RedHat Linux servers %prep %setup %build configure --prefix=/usr/squid perl -spi -e 's!#( -DALLOW_HOSTNAME_UNDERSCORES)!$1!' src/Makefile make %install make install %files /usr/squid

Zo bouw je deze RPM:

% mkdir -p SOURCES BUILD SRPMS RPMS/i386 % cp ~/squid-1.NOVM.22-src.tar.gz SOURCES % cp ~/retry-1.NOVM.20.patch SOURCES % rpm -ba squid-1.NOVM.22+retry-1.spec

Hiermee zal automatisch een subdirectory onder de BUILD directory worden aangemaakt, waarin de broncode zal worden uitgepakt en dan de patch zal worden toegepast (voor het patchen zijn een aantal opties beschikbaar - kijk in het boek voor details). Nu zal RPM automatisch het package bouwen door configure en vervolgens make uit te voeren, het met make install installeren, en een momentopname te nemen van de bestanden onder /usr/squid. Het is dat laatste wat de binaire RPM van de Squid software zal vormen.

We kunnen willekeurige shellopdrachten bij het uitpak-, bouw- en installatieproces invoegen, zoals b.v. de aanroep naar perl waarmee één van Squid's parameters tijdens het compileren wordt verfijnd.

De uiteindelijke binaire RPM zal onder de RPMS directory in de voor het platform specifieke subdirectory i386 worden achtergelaten. In dit geval zal het squid-1.NOVM.22-1.i386.rpm worden genoemd. De bestandsnaam wordt aangemaakt door de waarden van de volgende parameters uit het spec bestand aaneen te schakelen: Name, Version en Release - plus het hardwareplatform in kwestie, in dit geval i386. Probeer dit in gedachten te houden bij het aanmaken van je eigen RPM's, om te vermijden ze al te lange of moeilijke namen te geven!

Het is het ook waard in gedachten te houden dat je RPM's kunt bouwen zonder dat je het gehele softwarepackage opnieuw moet samenstellen, b.v.

Summary: Linux 2.0.36 kernel + filehandle patch + serial console patch Name: linux Version: 2.0.36+filehandle+serial_console Release: 1 Copyright: GPL Group: Base/Kernel Source: linux-2.0.36+filehandle+serial_console.tar.gz %description Dit is slechts een eerste poging in de Linux kernel met patches samen te stellen voor installatie op onze RedHat Linux servers. %prep echo %setup echo %build echo %install echo %post /sbin/lilo %files /lib/modules/2.0.36 /boot/vmlinuz

In dit geval maken we eenvoudigweg een RPM gebaseerd op het /boot/vmlinuz bestand en de inhoud van de directory /lib/modules/2.0.36, en voeren /sbin/lilo uit nadat het package op een doelcomputer is geïnstalleerd. Laat het me weten als je een veel nettere manier weet om het spec bestand te schrijven.

Hier is Eric's script voor het opnemen van bijgewerkte RPM's in de RedHat distributie: #!/usr/bin/perl # $redhatdir="/cdrom/i386"; $rpmdir="/cdrom/i386/RedHat/RPMS/"; $updatedir="/cdrom/updates/"; @OTHERDIR=($updatedir); foreach $dir (@OTHERDIR) { print "update voor $dir\n"; system(" find $dir -name \"*.rpm\" -exec cp {} $rpmdir \\; "); } chdir($contribdir) || die "peux pas aller dans $contribdir $!\n"; system("chmod -R 755 $redhatdir"); chdir($rpmdir) || die "problem to go in $rpmdir $!\n"; # # verwijder het oude bestand # opendir(DIR,'.'); @package=grep(/\.rpm$/,readdir(DIR)); foreach $file (@package) { $file =~ /(.*)\-([\d+|\.]+\w*)\-(\d+)\.[i386|noarch].*/; $nom=$1; $version=$2; $buildvers=$3; if ($NOM{$nom}) { $version2=$VERSION{$nom}; $buildver2=$BUILDVERS{$nom}; $file2=$FILE{$nom}; $nom2=$NOM{$nom}; if ( $version2 gt $version ) { print "$file2 is nieuwer dan $file\n"; unlink($file); } else { if ( $version2 lt $version ) { print "$file is nieuwer dan $file2\n"; unlink($file2); $VERSION{$nom}=$version; $BUILDVERS{$nom}=$buildvers; $FILE{$nom}=$file; $NOM{$nom}=$nom; } else { if ( $buildver2 > $buildvers ) { print "$file2 : $buildver2 est mieux que $file : $buildvers\n"; unlink($file); } else { print "$file2 : $buildver2 is ouder dan $file : $buildvers\n"; unlink($file2); $VERSION{$nom}=$version; $BUILDVERS{$nom}=$buildvers; $FILE{$nom}=$file; $NOM{$nom}=$nom; } } } } else { $VERSION{$nom}=$version; $BUILDVERS{$nom}=$buildvers; $FILE{$nom}=$file; $NOM{$nom}=$nom; } } # hier doen we het zware werk # system("$redhatdir/misc/src/install/genhdlist $redhatdir");