ĆWICZENIE NR 4 KONFIGURACJA JĄDRA, USŁUGI SIECIOWE. KATEDRA ELEKTRONIKI POLITECHNIKA LUBELSKA

Transkrypt

1 ĆWICZENIE NR 4 KONFIGURACJA JĄDRA, USŁUGI SIECIOWE. KATEDRA ELEKTRONIKI POLITECHNIKA LUBELSKA

2 A. ZAGADNIENIAZ DO POWTÓRZENIA PRZED WYKONANIEM ĆWICZENIA Budowa jądra. B. ZAKRESZ ĆWICZENIA Instalacja oprogramowania. Polecenia rpm, gzip, bzip, tar. Konfiguracja bootloadera. Plik /boot/grub/grub.conf, /etc/lilo.conf. Polecenie lilo. Konfiguracja jądra systemu. Instalacja nowego jądra. Operacje na modułach jądra. Polecenia modprobe, insmod, rmmod, depmod. Plik /etc/modules.conf 1. Instalacja oprogramowania C. PRZEBIEGP ĆWICZENIA. 1. Polecenia pakujące oraz archiwizujące: tar, gzip, bzip. 2. Pakowanie plików za pomocą polecenia gzip: gzip cv plik > plik.gz gzip dvn plik.gz gzip l plik.gz 3. Pakowanie plików za pomocą polecenia tar: tar c plik > plik.tar tar xvf plik.tar tar zxvf plik.gz 4. Menedżer pakietów rpm. Podstawowe funkcje to: instalacja, usuwanie, aktualizacja i odpytywanie o zainstalowane pakiety. instalacja ivh U F (update już zainstalowanych) odpytywanie q usuwanie e nie sprawdza powiązań nodeps sprawdzenie konfliktów test 5. Chętni mogą sprawdzić funkcjonowanie graficznego menadżera pakietów, np. GNOME- RPM (bardzo kolorowy J). 6. Istnieje możliwość instalacji pakietów bezpośrednio z Midnight Commandera. W tym celu wchodzimy do pakietu i wybieramy plik o nazwie INSTALL (co oznacza * przed nazwą pliku J) lub UPGRADE. 2. Konfiguracja bootloadera. 1. Przeanalizowanie zawartości pliku konfiguracyjnego bootloadera LILO /etc/lilo.conf. Należy pamiętać dokonując modyfikacji pliku konfiguracyjnego bootloadera o

3 każdorazowym wykonaniu komendy lilo po wprowadzeniu zmian. 2. Zmiana domyślnie ładowanego systemu opcja default. 3. Zabezpieczenie LILO hasłem opcja password. 4. Ograniczenie konieczności wprowadzania hasła do sytuacji, gdy mają zostać przekazane dodatkowe parametry do jądra przy starcie systemu, opcja restricted. 5. Opisać możliwości konfiguracji poprzez zastosowanie: ether, reserve, append: append= ether=irq,mem,eth0 ether=0,0,eth0 ether=-1,0,eth0 6. Ręczne przekazywanie parametrów do jądra systemu przy starcie. Wymuszamy linię poleceń LILO. Klawiszem TAB wyświetlamy dostępne obrazy do załadowania. Jako dodatkowy parametr możemy podać np.: linux single linux ether=irq,mem,eth0 linux init=3 linux mem= Konfiguracja jądra systemu. Instalacja nowego jądra. 1. Wykorzystując klienta FTP należy ściągnąć z podanego przez prowadzącego zajęcia adresu IP wskazaną wersję jądra Linuxa (spakawane 30 MB, rozpakowane 150 MB). 2. Rozpakowane źródła nowego jądra umieszczamy w katalogu /usr/src. 3. Sprawdzamy, czy istnieje link symboliczny linux do katalogu przechowującego źródła aktualnej wersji jądra: Jeżeli podany link istnieje należy go usunąć: ls l rm linux 4. Dobrym zwyczajem jest zmiana nazwy katalogu z nowymi źródłami jądra na nazwę jednoznacznie identyfikującą wersję nowego jądra, np.: /usr/src/ Poprawne przeprowadzenie kompilacji nowego jądra wymaga stworzenia linku symbolicznego o nazwie linux wskazującego na katalog z źródłami nowego jądra, np.: ln s linux 6. Konfiguracja elementów jądra wybranych do kompilacji (wszystkie polecenia wykonujemy będąc w katalogu /usr/src/linux): - przedstawić dostępne narzędzia: make menu, make menuconfig, make xconfig (ze wskazaniem na środowisko graficzne konieczne jest wcześniejsze uruchomienie środowiska Xwindow), - omówić sposoby obsługi urządzeń przez jądro systemu (moduły, wkompilowane w jądro), - wczytanie, z wygenerowanego wcześniej pliku, stworzonej konfiguracji kompilacji jądra do make xconfig. 7. Kolejne polecenia przedstawiają proces kompilacji jądra (omawiany przez prowadzącego): - budowa zależności: make dep ( tylko w wersji jądra 2.4)

4 - czyszczenie niewykorzystywanych powiązań: make clean - kompilacja jądra (w wersji skompresowanej): make bzimage, make zimage - kompilacja wybranych modułów: make modules - przegranie skompilowanych modułów do katalogu zawierającego moduły nowej wersji jądra /lib/modules/kernel/...: make modules_install 8. Zgranie skompilowanego jądra z /usr/src/linux/arch/i386/boot/bzimage do katalogu startowego /boot. 9. Przed dodaniem nowego jądra do bootloadera dobrze jest zmienić nazwę skompilowanego jądra z bzimage na np.: vmlinuz (względy estetyczne J). NIGDY nie należy usuwać starego jądra oraz dotyczących go wpisów w bootloaderze przed dokładnym, długoterminowym (około 2 tygodnie ciągłej pracy), sprawdzeniem poprawności działania nowego jądra!!! 10. Ostatni etap to dodanie wpisu dotyczącego położenia obrazu nowego jądra w pliku konfiguracyjnym bootloadera i zainstalowanie tak zaktualizowanej wersji bootloadera na dysku twardym: - dodanie nowego wpisu image pod istniejącym, dotyczącym aktualnego jądra w pliku lilo.conf (należy pamiętać, że nie powielamy komendy append), - uruchomienie polecenia lilo zapisującego zaktualizowany menadżer startu w głównym sektorze startowym dysku twardego. 11. Można również zautomatyzować proces dodawania nowego kernel a do bootloader a, wystarczy wpisać polecenie make install. Spowoduje to automatyczne skopiowanie kernela we właściwe miejsce oraz dodanie odpowiedniego wpisu do pliu konfiguracyjnego menadżera startu. 4. Operacje na modułach jądra 1. Analiza pliku /etc/modules.conf umożliwiającego zmianę obsługi ładowalnych modułów jądra. W celu dokładniejszego poznania możliwości konfiguracji należy sięgnąć do manuala systemowego man modules.conf. W podstawowej konfiguracji plik modules.conf zawiera funkcjonujące w systemie aliasy, kojarzące nazwy interfejsów z modułami. 2. Wszystkie skompilowane moduły możliwe do zainstalowania znajdują się w katalogu: /lib/modules/2.6.{numer wersji}/kernel/drivers 3. Wyświetlenie listy załadowanych modułów : lsmod cat /proc/modules

5 4. Instalowanie modułu za pomocą polecenia insmod nie uwzględnia powiązań między modułami. Prosta składnia wymaga tylko podania nazwy modułu (oczywiście bez.o J): insmod 8139too insmod k 8139too (ustawiona opcja autoclean) 5. Bezpieczniejsze instalowanie modułów uzyskuje się poprzez wcześniejsze stworzenie pliku zawierającego powiązania między modułami: depmod Plik zależności modułów należy zawsze uaktualniać poleceniem depmod, gdy uaktualnia się jądro lub biblioteki modułów!!! 6. Teraz za pomocą polecenia modprobe, które sprawdza wygenerowany plik powiązań między modułami, można załadować moduł obsługi: modprobe 8139too 7. Usuwanie załadowanych modułów uzyskuje się poprzez wykonanie polecenia: Konfiguracja usług rmmod 8139too Serviceconf Serviceconf jest narzędziem graficznym opracowanym przez Red Hat w celu konfiguracji usług uruchamianych przy starcie systemu (poziomy pracy 3, 4, and 5) oraz usług xinetd. Możliwe jest wydanie komend start, stop, oraz restart dla usług SysV (uruchamianych za pomocą skryptów przy starcie systemu) oraz komendy restart dla xinetd. Uruchamianie Serviceconf polega na: W środowisku GNOME, Main Menu Button (na panelu) => Programs => System => Serviceconf. W środowisku KDE, Main Menu Button (na panelu ) => Red Hat => System => Serviceconf. Można również wydać polecenie serviceconf w terminalu tekstowym uruchomionym w środowisku Xwindow. Rys. 1. Wygląd aplikacji Serviceconf

6 ntsysv ntsysv umożliwia aktywowanie lub blokowanie usług i wyposażony jest w prosty interfejs semitekstowy. Aplikację tą można użyć do włączania i wyłączania usług wykorzystujących xinetd. Można również wybierać usługi uruchamiane podczas startu systemu. W tym jednak przypadku konfigurowany jest domyślnie bieżący poziom pracy (runlevel). Jeżeli modyfikacji mają podlegać inne poziomy to należy uruchomić ntsysv, np. ntsysv --levels 016. W takim przypadku modyfikacji poddane zostaną usługi z poziomu 0, 1 oraz 6. chkconfig Komenda chkconfig ma wiele znaczeń poprzez odpowiednie stosowanie argumentów dodawanych w linii komend. Może m.in. sterować aktywacją lub dezaktywacją usług na odpowiednim poziomie pracy systemu. Stosując polecenie: chkconfig --list otrzymać można podsumowanie ustawień systemu, tak jak widać to niżej (przykładowo szukamy ustawień dla usługi finger uruchamianej przez xinetd): $ chkconfig --list finger finger on W przypadku usług uruchamianych ze skryptów startowych wynik działania podobnej komendy (dla usługi anacron) wygląda jak niżej: $ chkconfig --list anacron anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off chkconfig może być do modyfikacji dostępnych usług na różnych poziomach pracy. W tym celu można wydać przykładowe polecenie (wyłączanie usługi nscd na poziomie 3,4, oraz 5): chkconfig --level 345 nscd off Konfiguracja xinetd. Plikiem konfiguracyjnym dla xinetd jest plik /etc/xinetd.conf. Zawiea on jednak tylko kilka wpisów o znaczeniu ogólnym oraz instrukcję włącznie katalogu /etc/xinetd.d. Aby udostępnić albo zabronić korzystania z danej usługi należy podać edycji odpowiednie dla tej usługi pliki w katalogu /etc/xinetd.d. Jeżyli atrybut disable w danym pliku jest ustawiony na yes, oznacza to, że dana usługa jest zablokowana. Analogicznie, jeżeli wpis ma określa wartość no, to usługa jest dostępna. Jeżeli pliki konfiguracyjne xinetd są modyfikowane za pomocą aplikacji Serviceconf, ntsysv, lub chkconfig, należy przeładować xinetd zanim zmiany będą mogły wejść w życie. Aby otzymać listę usług uruchamianych przez xinetd można wydać komendę ls /etc/xinetd.d. lub skorzystać z jednej z wymienionych wyżej aplikacji. Przykładowa zawartość pliku /etc/xinetd.conf przedstawiona jest niżej: defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST } includedir /etc/xinetd.d

7 Znaczenie poszczególnych dyrektyw jest następujące: instances określa maksymalną liczbę wywołań usługi, które mogą być obsłużone jednocześnie. log_type mówi xinetd by używał authpriv log, zawartego w /etc/syslog.conf i ustawia var/log/secure jako domyślną ścieżkę. log_on_success mówi xinetd co należy zrobić po pomyślnym uruchomiemniu usługi. Domyślnie adres IP zdalnego hosta oraz ID procesu na serwerze są rejestrowane. log_on_failure anologicznie jak wyżej Inne argumenty są używane w plikach konfiguracyjnych poszczególnych usług ale są one związane z ustawieniami globalnymi w pliku /etc/xinetd.conf. Oto najważniejsze z nich : ATTEMPT Zapisuje, że nastąpiło odrzucenie prośby o obsługę. (log_on_failure) DURATION Zapisuje czas trwania korzystania z usługi przez zdalny host (log_on_success) EXIT Zapisuje status zakończenia usługi oraz sygnał zakończenia (log_on_success) HOST Zapisuje IP adres zdalnego hosta. (log_on_failure and log_on_success) PID Zapisuje process ID serwera obsługującego wezwanie o obsługę. (log_on_success) USERID Zapisuje dane o usługach wielowątkowych zdafiniowanych wrfc 1413 (log_on_failure and log_on_success) Pliki konfiguracyjne xinetd Pliki w katalogu /etc/xinetd.d są czytane za każdym razem gdy xinetd. Pliki te naszą nazwy np. finger, ipop3, rlogin, i odpowiadają rodzajowi usługi kontrolowanej przez xinetd. Pliki w /etc/xinetd.d wykorzystują tą samą konwencję I opcje jak w pliku /etc/xinetd.conf opisanym wyżej. Przykładowy plik konfiguracyjny dla usługi ftp (wu-ftp dostępnym w każdej dystrybucji RedHata) przedstawiony jest niżej; service ftp { socket_type = stream wait = no user = root server = /usr/sbin/in.ftpd server_args = -l -a log_on_success += DURATION USERID log_on_failure += USERID nice = 10 disable = yes } E. MATERIAŁYM POMOCNICZE