Sprawozdanie z przygotowywania maszyny wirtualnej ze
Transkrypt
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