Sprawozdanie z przygotowywania maszyny wirtualnej ze

Sprawozdanie z przygotowywania maszyny wirtualnej ze skonfigurowanym
systemem PLD Linux
1. W celu przygotowania maszyny wirtualnej dla VMware Playera skorzystałem
z niezależnego narzędzia VMX Builder – zapewne skorzystanie z usługi sieciowej
EasyVMX!byłoby prostsze, ale w dniu tworzenia maszyny usługa ta była niedostępna.
2. Poza ustaleniem trywialnych właściwości maszyny wirtualnej, konieczne było ręczne
dodanie do urządzeń napędu CD (który został za pomocą VMware Playera powiązany
z plikiem RCDx86_297.iso) oraz utworzenie dysku twardego (rozmiar 2GB wydaje się być
co najmniej wystarczający).
3. Podział na partycje został wykonany w następujący sposób:
Urządzenie
Typ partycji
Eytkieta
Planowany punkt
montowania
Rozmiar
/dev/sda1
Podstawowa
BOOT
/boot
16MB
/dev/sda5
Logiczna
ROOT
/
896MB
/dev/sda6
Logiczna
VAR
/var
296MB
/dev/sda7
Logiczna
HOME
/home
296MB
/dev/sda8
Logiczna
SWAP
swap
640MB
W celu nadania odpowiednich etykiet użyłem parametru -L narzędzi mke2fs oraz mkswap.
4. Ze względu na nietypową kolejność dodawania urządzeń za pomocą VMX Buildera, dysk
twardy jest rozpoznawany przez uruchamiany z dysku system jako /dev/hdb (/dev/hda to
stacja CD) – pomimo że z poziomu RescueCD przypisano mu urządzenie /dev/sda.
Rozwiązaniem tego konfliktu nazw okazało się stworzenie linków twardych w /dev podczas
pracy z poziomu RescueCD i ponowne wykonanie w tych warunkach geninitrd. Zmiany
w /etc/fstab tworzonego systemu nie były konieczne, gdyż wybieram tam urządzenia
partycji na podstawie etykiet, niezależnie od ścieżek w /dev.
5. Wykonywanie punktów instrukcji zawartej w dodatku „Instalacja PLD Linux za pomocą
PLD RescueCD” było zupełnie skuteczną metodą instalacji systemu. Modułem do obsługi
IDE wskazanym przez pcidev dla użytej maszyny wirtualnej jest piix. Na uwagę zasługuje
spostrzeżenie, że podczas instalacji pakietu udev w nowo tworzonym systemie, /dev
utworzone przez liveCD nie powinno być podmontowane do /dest/dev, gdyż
uniemożliwiłoby to powstanie statycznych plików urządzeń w nowym systemie. Popełniłem
ten błąd i rozwiązałem go, tworząc pliki /dev/console, /dev/null i /dev/zero za pomocą
polecenia mknod (później dopiero zrozumiałem przyczynę problemów związanych
z brakiem tych plików). Ponadto poza wymienioną w instrukcji listą pakietów do instalacji
potrzebne było zainstalowanie w nowym systemie pakietu e2fsprogs. Uciążliwy wydał mi
się także brak narzędzi man, less i wget, które zainstalowałem z pakietów
o odpowiadających im nazwach.
6. Początkowo próba ustawienia hasła użytkownika root powodowała błąd, który został
rozwiązany po wywołaniu polecenia pwconv. Hasła użytkowników (oraz hasła do kluczy
publicznych) zostały ustawione w następujący sposób:
Hasło użytkownika
Fraza do klucza publicznego
root
Nzwki,Pgwcosz
Jnrc,Ssoz,PwsT,Gnswzm
tpablo
Pnnnsnp-Szcrni
Ojw,ss,JkncL,JswpZkDwt
tytus
Nsnknptln,Inndgw
Lnnwins,CrGwkn,Jgwwtwslm
romek
Dm:Tpk,Alpwsnm
Wrcmo,PLAt-NroB,PcwEtp?
atomek
Sstjpl,Innzwnh
P?-Ctot,Zgwkmz-ZtPzsk-Ktsid
7. Dla wygody, domyślna powłoka użytkownika root została zmieniona na /bin/bash. Ponadto,
aby usprawnić przełączanie użytkowników za pomocą su, część ustawień użytkowników
root oraz tpablo została przeniesiona z ~/.bash_profile do ~/.bashrc. Dodałem też kilka
ustawień o charakterze estetycznym (kolorowe PS1, oraz domyślne kolorowanie wyników
narzędzi grep i ls).
8. Ustawienie poprawnego czasu wewnątrz maszyny wirtualnej wymagało ustawienia zegara
systemowego gościa na czas lokalny, poprzez edycję pliku /etc/sysconfig/clock.
9. Serwer ssh postawiłem zgodnie z instrukcją i bez żadnych trudności. Dla każdego konta
przygotowałem pozwalający się na nie logować klucz RSA, chroniony frazą zapisaną
w tabeli. Poza trywialną konfiguracją pliku /etc/ssh/sshd_config polegającą na
odkomentowaniu odpowiednich linijek,
należało ustawić „PermitRootLogin
without-password”. Najprostszym sposobem dowiedzenia się o istnieniu tej opcji była
dokładna lektura komentarzy w edytowanym pliku. Usługa została przetestowana poprzez
logowanie zdalne z poziomu gospodarza wirtualizacji, które było możliwe dzięki
konfiguracji przekierowania portów w ustawieniach globalnych VMPlayera. Informację
o takiej możliwości znalazłem na stronach VMware
(http://www.vmware.com/support/gsx3/doc/network_nat_advanced_gsx.html)
10. Zgodnie z instrukcją został skonfigurowany cron. Skorzystałem z pakietu z implementacją
Vixie-cron. Wymagało to napisania skryptu tworzącego odpowiednie logi, który został on
umieszczony w lokacji /usr/local/sbin/mkcorelist. Logi tworzone są w lokacji
/var/log/corelist, w plikach o intuicyjnych nazwach. Copółgodzinne wywołanie skryptu
zostało osiągnięte za pomocą linii treści:
*/30 * * * *
root /usr/local/sbin/mkcorelist
w pliku /etc/cron.d/crontab.
11. Korzystając z pakietu źródłowego most pobranego z lokacji
ftp://ftp.ics.p.lodz.pl/mirror/PLD/3.0-frozen/PLD/SRPMS/RPMS/most5.0.0a-2.src.rpm, skompilowałem program most i skonfigurowałem go do współpracy
z narzędziem man. Wymagało to instalacji pakietu rpm-build oraz budowy odpowiedniego
drzewa folderów w katalogu użytkownika budującego pakiet (był to tpablo) – można to
wyrazić za pomocą jednego polecenia:
mkdir -p ~/rpm/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
Ponadto w celu uniknięcia błędów konieczne było ustawienie zmiennej TMP przy
zalogowaniu (w szczególności, gdy dokonywano go poprzez polecenie su wywołane przez
użytkownika root) na użytkownika budującego pakiet – zastosowanym rozwiązaniem tego
problemu jest przeniesienie ustawienia tej zmiennej z .bash_profile użytkownika do jego
.bashrc. Do zbudowania pakietu potrzebne były (jako bezpośrednie zależności) pakiety
autoconf, automake i slang-devel.
Konfiguracja na potrzeby której zainstalowano program most polegała na edycji ustawienia
PAGER w pliku /etc/man.config, tak aby zamiast domyślnego less z odpowiednimi
argumentami wskazywała na /usr/bin/most -s, tak aby właśnie most służył do wyświetlania
podręczników systemowych. Skutkuje to ciekawymi estetycznie, kolorowymi
manualami :-).
12. Trzecim z wypełnionych wymagań dodatkowych jest samodzielna kompilacja programu ze
źródeł. Wykorzystane zostały oficjalne źródła stabilnej wersji porgramu gpm, pobrane
z lokacji http://unix.schottelius.org/gpm/archives/gpm-1.20.6.tar.bz2. Plik
został pobrany przez użytkownika tpablo za pomocą wget, rozpakowany
w /home/users/tpablo/src, skonfigurowany do instalacji w /usr, oraz skompilowany.
Wymagającą doinstalowania (po wykonaniu poprzedniego podpunktu, przy okazji którego
w systemie pojawiły się podstawowe narzędzia do kompilacji programów) zależnością był
tylko pakiet bison, który był potrzebny na etapie kompilacji. Następnie w katalogu
kompilacji programu root wywołał polecenie make install. Zważywszy, że tpablo jest
w grupie wheel, z poziomu jego powłoki można po prostu napisać su -c make\ install. Po
zainstalowaniu, program gpm został w prosty sposób skonfigurowany, aby prawidłowo
(z dokładnością do pliku urządzenia oraz protokołu) rozpoznawał mysz gościa i uruchamiał
się przy starcie – realizacją tego jest następująca linia w pliku /etc/rc.d/rc.local:
/usr/sbin/gpm -m /dev/input/mice -t ps2