7.1.3. Automatyzacja instalacji RedHata: KickStart

RedHat KickStart (KS) daje możliwość zainstalowania RedHata według pewnego schematu. Może to być przydatne w sytuacjach, gdy instalowanych jest wiele, identycznie skonfigurowanych hostów; dzięki RH KS można również (przynajmniej teoretycznie) zlecić instalowanie RH laikowi, bo wybór elementów do instalacji oraz konfiguracja systemu zostaną przeprowadzone automatycznie (laik będzie wówczas odpowiedzialny za wymianę płytek instalacyjnych i naciskanie Entera). KickStart pozwala na:

• Wybór pożądanych pakietów (ich dołożenie/usunięcie w stosunku do oficjalnej dystrybucji)

• Zainstalowanie wybranych pakietów przez sieć (z serwera FTP lub HTTP)

• Batchową konfiguracją wielu elementów systemu

• Łatwość i szybkość konfiguracji samego KS

• Przeniesienie konfiguracji KS na inną wersję RH niż wersja, na/dla której utworzono pierwotną konfigurację KS.

Dokumentację do systemu RedHat KickStart można znaleźć na płycie RedHata "Dokumentacja". Ponadto w RH 7.3 jest standardowo instalowany plik /usr/share/doc/anaconda-7.3/kickstart-docs.txt, zawierający pewne informacje dotyczące KS-a (KS jest elementem Anacondy - programu instalacyjnego dla RH). Niniejsze streszczenie powstało na podstawie tej dokumentacji oraz na podstawie własnych doświadczeń z KS na systemach RH 6.2 i RH 7.3.

Żeby uaktywnić KickStarta w czasie instalacji RH, należy przekazać do jądra parametr ks=<lokalizacja pliku konfiguracyjnego KS (ks.cfg)> [1]. Plik ks.cfg może się znajdować na dyskietce (ks=floppy), jak również w sieci (ks=nfs: lub ks=http:), może być reprezentowany przez urządzenie w katalogu /dev/ (ks=hd:) albo może być umieszczony na płytce (ks=cdrom:). I nie musi się nazywać ks.cfg, lecz np. praterm-ks.cfg. Wówczas parametr "ks=" musi zawierać nazwę pliku, np. "ks=hd:fd0/praterm-ks.cfg".

Z KickStarta najłatwiej skorzystać tworząc odpowiednią dyskietkę startową RH, np. przy pomocy komendy dd (załóżmy, że w /mnt/cdrom jest zamontowana płyta z oryginalnym RedHatem):

dd if=/mnt/cdrom/images/boot.img of=/dev/fd0,

Kilka słów należy się dyskietce instalacyjnej RedHata. Do uruchomienia i sparametryzowania procesu instalacji RH używa narzędzia zwanego SysLinux. Prosty boot manager pozwala użytkownikowi wybrać jedną z możliwości instalacji; różnice są wprowadzane na poziomie parametrów przekazywanych do jądra. Dyskietka ma DOS-owy system plików, łatwo jest więc zmodyfikować owe parametry lub dodać swoje własne rozszerzenia. Plikiem konfiguracyjnym dla SysLinuksa jest syslinux.cfg, którego zawartość do złudzenia przypomina format pliku lilo.conf, nie będzie więc tu opisywana. Żeby uruchamiany był KS, należy dodać linię ks=floppy do parametrów jądra w danym trybie, po czym przekopiować przygotowany wcześniej plik ks.cfg na dyskietkę. Instalacja KickStart uruchomi się wówczas automatycznie. Dodatkowo, możliwe jest, podobnie jak w przypadku oryginalnej instalacji RH, wprowadzenie różnych opcji instalacji, np. "Instalacja minimalna (wymagane 900MB miejsca na dysku)", "Instalacja pełna (2.5GB)" albo "Instalacja sieciowa". W tym celu modyfikujemy odpowiednio plik syslinux.cfg oraz pliki zawierające wyświetlane informacje, np. boot.msg, minimalna.msg, pelna.msg, sieciowa.msg. Niezbędne staje się też stworzenie kilku plików konfiguracyjnych dla KickStarta, i ustawianie innej opcji "ks=" w każdym z trybów, np. "ks=hd:fd0/ks-minimalna.cfg", "ks=hd:fd0/ks-pelna.cfg" itd.

Obraz dyskietki instalacyjnej znajduje się na CDROM-ach instalacyjnych RedHata i jest używany w procesie instalacji. Zmodyfikowanej wersji dyskietki można zatem użyć przy tworzeniu własnej dystrybucji RH.

Format pliku ks.cfg

Plik ks.cfg zawiera odpowiedzi na pytania (niekoniecznie wszystkie), które są normalnie zadawane w procesie instalacji. Jeżeli pewnej odpowiedzi nie ma w pliku, użytkownik zostanie o to zapytany w trakcie instalacji. Ponieważ pewne ustawienia są stosowane zawsze przy instalacji RH dla potrzeb SZARP-a, np. wybór języka, strefy czasowej, firewalla, hasło dla roota, bootloader, i inne (por. Sekcja 7.1), ks.cfg z tym przypadku będzie zawierał odpowiedzi na te pytania. Na inne (np. numer IP hosta) użytkownik będzie musiał odpowiedzieć samemu podczas instalacji.

Format pliku ks.cfg różni się pomiędzy wersjami 6.x i 7.x RedHata. Różnice są wprawdzie niewielkie i duży podzbiór komend jest wspólny dla obu wersji, ale należy być świadomym tego przy korzystaniu z istniejących plików ks.cfg oraz dokumentacji do systemu KS. Należy również pamiętać o tym, że w RH6.2 komendy KS miały znacznie mniej parametrów (np. konfigurując X Window System w KS z RH6.2 nie można było ustawić rozdzielczości, podczas gdy w RH7.3 można ustawić nie tylko rozdzielczość ale i głębię kolorów).

Automatyczną konfigurację w ks.cfg dla RH 7.3 niektórych z opcji przedstawiono poniżej; ustawiany jest tu język instalacji (angielski - en_US), wsparcie i ustawienie jako domyślnego języka polskiego, ustawienia klawiatury, myszy, hasła "na roota", opcji firewalla (otwarcie 3-ch portów), włączenie shadowingu dla haseł, ustawienie strefy czasowej oraz żądanie zainstalowania bootloadera (GRUB-a):

install
lang en_US
langsupport --default pl_PL en_US.iso885915 pl_PL
keyboard us
mouse generic3ps/2 --device psaux
rootpw --iscrypted $1$Ë0ĹŃÜIĹa$hmRXwbpzFytxg0bU/0TML/
firewall --medium --port smtp:tcp --port http:tcp --port ssh:tcp
authconfig --enableshadow --enablemd5
timezone --utc Europe/Warsaw
bootloader

Jeżeli konfigurujemy np. 20 hostów z identyczną kartą graficzną (i z podobnym monitorem) to możemy automatycznie skonfigurować też iksy, jak poniżej:

xconfig --card "RIVA128" --videoram 4096 --hsync 31.5-48.5 --vsync 50-70 --resolution 1024x768 --depth 16 --startxonboot 

Pominięcie symbolu karty graficznej (lub/i rozmiaru RAM-u na karcie) spowoduje, że system spróbuje automatycznie ją wykryć i, jeśli mu się powiedzie, użytkownik nie zostanie zapytany o kartę.

xconfig --hsync 31.5-48.5 --vsync 50-70 --resolution 1024x768 --depth 16 --startxonboot 

Możliwe jest też automatyczne partycjonowanie dysku. Poniżej pokazano partycjonowanie dysku wg następującej zasady:

• 200MB dla dosa

• RAMx2 (wartość rekomendowana) dla swapa

• reszta - / dla Linuksa

Przed dodaniem jakiejkolwiek partycji wyrzucone będą z dysku wszystkie istniejące dotychczas partycje (clearpart --all):

clearpart --all
part /mnt/dos --fstype vfat --size 200
part swap --recommended
part / --fstype ext3 --size 10000 --grow

KickStart pozwala również określić pakiety oraz moduły (zbiory pakietów, poprzedzone znakiem "@") do zainstalowania, np.:

%packages
@ Printing Support
@ Classic X Window System
@ X Window System
@ KDE
@ Network Support
@ Router / Firewall
@ Authoring and Publishing
@ Emacs
@ Utilities
@ Software Development
@ Kernel Development
szarp
codebase
codebase-devel

lub po prostu:

%packages
@ Everything

Możliwe jest także umieszczenie własnych skryptów i komend po zainstalowaniu wszystkiego (np. w celu stworzenia katalogów, modyfikacji konfiguracji):

%post
echo "nameserver 192.168.1.1" > /etc/resolv.conf
mkdir /usr/work

W pliku konfiguracyjnym KS możliwa jest też konfiguracja sieci oraz przeprowadzenie całej instalacji przez sieć. Wówczas instalacja RH wyglądać może tak:

• Wkładam dyskietkę (ze skonfigurowanym KS-em) do stacji.

• Uruchamiam komputer tak, żeby wystartował z dyskietki.

• Gdy już instalacja wystartuje zwykle mamy możliwość wyboru źródła pakietów do zainstalowania (lokalny CD-ROM, dysk twardy, NFS, FTP, HTTP). W przypadku opisywanym tu wybieramy opcję: lokalny CD-ROM.

Najlepszym rozwiązaniem (minimalizacja ruchu w sieci a zarazem dostęp do najnowszych wersji pakietów) jest instalacja hybrydowa, np. całość systemu instalowana jest z płytek, natomiast reszta (najnowsze biblioteki motifa, SZARP, niestandardowe pakiety) mogą być zainstalowane przez sieć. Jest to możliwe m.in. dzięki opcjom programu rpm, którego wywołanie można umieścić w sekcji %post w pliku konfiguracyjnym KS w formie jak niżej:

rpm -i ftp://user:password@host:/path/packet.rpm

Po każdej instalacji RedHata w katalogu /root generowany jest plik anaconda-ks.cfg z konfiguracją, wg której przebiegała instalacja. Plik ten może posłużyć za wzorzec do tworzenia własnych plików konfiguracyjnych ks.cfg.

Przykładowy plik konfiguracyjny ks.cfg dla RH6.2 przedstawiono poniżej:

install
lang en_US
keyboard us
mouse generic3ps/2 --device psaux
auth --useshadow --enablemd5
rootpw --iscrypted $1$Ë0ĹŃÜIĹa$hmRXwbpzFytxg0bU/0TML/
timezone --utc Europe/Warsaw
lilo --location mbr
# W nie ma polecenia booloader, jest tylko lilo
xconfig --hsync 31.5-48.5 --vsync 50-70 --startxonboot 
# Nie ma możliwosci ustawienia typu i systemu plików dla partycji
clearpart --all
part /mnt/dos --size 200
part swap --size 200
part /  --size 1000 --grow
network --bootproto static --ip 192.168.1.111 --netmask 255.255.255.0

%packages
# Nie ma opcji @ Everything
@ Printer Support
@ X Window System
@ Mail/WWW/News Tools
@ DOS/Windows Connectivity
@ Utilities
@ Graphics Manipulation
@ Multimedia Support
@ Networked Workstation
@ Dialup Workstation
@ Authoring/Publishing
@ Emacs
@ Development
@ Kernel Development
@ Workstation Common
@ GNOME
@ KDE
@ Network Server
@ News Server
@ NFS Server
@ SMB (Samba) Server
@ Anonymous FTP Server
@ Web Server
@ DNS Name Server
@ Postgres (SQL) Server
@ Network Management Workstation
%post
mkdir /usr/work
/usr/sbin/useradd palacz
chfn -f '' palacz
/usr/bin/passwd -d palacz

Uwaga! Plików ks.cfg nie powinno się pisać ręcznie, należy raczej wykorzystać istniejący już plik anaconda-ks.cfg lub RedHatowe narzędzie graficzne pod nazwą ksconfig, które służy właśnie do konfiguracji i generowania plików ks.cfg.