Show pageOld revisionsBacklinksBack to top This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. ===== Podstawy administrowania 2: zarządzanie usługami i monitorowanie systemu ===== ==== Przygotuj się do laboratorium ==== * ''man systemd(1)'' * ''man systemctl(1)'' * ''man crontab(5)'' * {{gjn-cron.pdf|Konfigurowanie i zastosowanie systemu Cron}} * {{gjn-syslog.pdf|Monitorowanie systemu GNU/Linux przy pomocy Syslog}} (duet syslogd+klogd został już zastąpiony przez rsyslogd, ale ogólna idea działania pozostała bez zmian, dlatego warto się zapoznać) ==== Wiedza ==== === 1. Uruchamianie i zatrzymywanie systemu === Uruchamianie systemu można podzielić na pewne ogólne etapy: * start programu ładującego jądro (bootstrapu), np. //grub//, * ładowanie i dekompresja jądra, * inicjalizacja podstawowych urządzeń, których obsługa jest wkompilowana w jądro, * sprawdzenie i podmontowanie głównego systemu plików, * stworzenie pierwszego procesu przez jądro (z PID=1): //init// (w System V; większość dystrybucji od niego odchodzi) albo //systemd// (w nowszych systemach, w tym Ubuntu), * proces o PID=1 uruchamia wszystkie inne procesy, działając z uprawnieniami administratora, zmienia poziomy pracy systemu (runlevels), w tym uruchamia i zatrzymuje system, * zezwolenie na logowanie się użytkowników. Zatrzymanie systemu składa się z etapów: * wydanie polecenia **shutdown**, * system powiadamia użytkowników o zatrzymaniu, * wszystkie procesy użytkowników są zatrzymywane, * system przechodzi na poziom 0 lub 6 (zob. niżej), * zatrzymanie odpowiednich usług, * odmontowanie systemów plików, * zatrzymanie lub restart systemu. === 2. Poziomy pracy systemu i systemd === Koncepcja poziomów pracy pochodzi z System V i oznacza różne tryby pracy systemu: * poziom 0 oznacza zatrzymanie (halt), * poziom 1 jest trybem dla jednego użytkownika (single) - administratora, * poziomy 2 - 5 są różnymi trybami pracy dla wielu użytkowników, * 6 - oznacza zatrzymanie i restart (reboot). Z każdym poziomem pracy związane były odpowiednie katalogi: ///etc/rcN.d//, w których znajdowały się skrypty uruchamiające/zatrzymujące usługi odpowiednio dla zadanego poziomu pracy. Nazwa usługi (skryptu) w tych katalogach ma postać: //K##nazwa// lub //S##nazwa// (gdzie ## to numer wyznaczający kolejność uruchamiania skryptów). Te katalogi ciągle są dostępne, ale jest to związane tylko z kompatybilnością wsteczną z System V -> systemd z nich nie korzysta. Aktualnie większość dystrybucji Linuxa (w tym Ubuntu) przeszła na systemd, który jest bardziej elastyczny, umożliwia wykonywanie zadań równolegle i zarządza większą ilością aspektów systemu niż init z System V: * usługi nie są grupowane w runlevels ale w targets; każdy target może wymagać uruchomienia wybranych usług + może wymagać uruchomienia innych targets * poziomy pracy systemu z System V są 'symulowane' przez odpowiednie targety: restart.target / halt.target / graphical.target (zob. ''man runlevel'') * domyślny poziom pracy systemu jest zdefiniowany przez łącze symboliczne ''default.target''. Aktualny domyślny poziom można sprawdzić za pomocą ''systemctl get-default''. Zmiana następuje za pomocą ''systemctl set-default'' (albo ręczną zmianę odpowiedniego łącza symbolicznego) * jeżeli chcemy uruchomić jakiś skrypt przy wchodzeniu na określony ''runlevel'' to nie definiujemy go w ///etc/rcN.d// (tzn. możemy i to zadziała, ale tylko przez kompatybilność wsteczną z System V). Aby zrobić to zgodnie z systemd, definiujemy stosowny plik ''moj_skrypt.service'', w którym w sekcji ''[Install]'' zaznaczamy ''WantedBy='' i wskazujemy target przy którym powinien uruchomić się skrypt * zarządzanie usługami odbywa się poprzez ''systemctl [start|stop|status|reload|restart] usluga'' === 3. Korzystanie z Cron === Automatyzacja niektórych prac systemu jest niezwykle pomocna, używa się do niej programów: * **at** umożliwia jednorazowe uruchomienie programu o zadanym czasie, * **cron** umożliwia cykliczne uruchamianie programów, * obydwa systemy mogą być używane przez wszystkich użytkowników, * składają się z części serwera (demona) i klienta - uruchamianego przez użytkownika, * serwer **atd** kolejkuje zadania każdego użytkownika, * w przypadku cron każdy użytkownik ma jeden plik //crontab//, w którym zapisuje wszystkie zadania, * cron udostępnia dodatkową funkcjonalność administratorowi, * cron jest jednym z podstawowych narzędzi automatyzujących pracę administratora. Do komunikacji z demonem crond służy polecenie **crontab**: * **crontab** umożliwia edycję i pokazywanie pliku //crontab//, * każdy użytkownik ma jeden taki plik, * w pliku może się znajdować wiele zadań, każde w osobnej linii, * polecenie **crontab** korzysta z zewnętrznego edytora do edycji pliku. Składnia pliku //crontab//: * linia składa się z sześciu pól, ostatnie to nazwa polecenia do wykonania, * pola w każdej linii oznaczają kolejno: minutę, godzinę, dz. mies., miesiąc, dz. tyg., * gwiazdka w miejscu wartości oznacza: "dla każdej wartości pola", np.: co godzinę, * kilka wartości rozdziela się przecinkami, * znak "-" pozwala na podanie zakresu wartości, * połączenie go ze znakiem "/" umożliwia podanie kroku w obrębie zakresu. Zamiast pierwszych 5 pól specyfikujących termin wykonania, można użyć również jednego ze specjalnych ciągów znaków, jak ''@daily'', ''@reboot'', ... (szczegóły w manualu do ''crontab(5)''). Plik ///etc/crontab// zawiera centralną konfigurację demona cron, ma możliwość podania przed poleceniem nazwy użytkownika z prawami którego będzie wykonywane polecenie. //Cron// jest m.in. przydatny w cyklicznym archiwizowaniu i analizowaniu plików //Sysloga//. === 4. Monitorowanie pracy === Linux (podobnie jak systemy Unix) ma mechanizmy rejestrujące każde zdarzenie w systemie. * rejestrowanie (logowanie; log - dziennik) oznacza systematyczne zapisywanie odpowiednich informacji do plików, * pliki rejestrów określa się po ang. //log files//, * logowanie jest wykonywane przez pracujący bez przerwy system //rsyslogd// (obsługujący funkcjonalność demonów //klogd// i //syslogd// z poprzednich wersji systemu). Rsyslog: * system zapisuje (loguje) informacje do plików rejestrów/"logów" systemowych, w katalogu ///var/log// * pliki rejestrów są plikami tekstowymi o jednolitej składni, * pliki rejestrów są cyklicznie porządkowane przy pomocy specjalnych programów wywoływanych przez //Cron//. * rsyslogd jest jednym z najważniejszych demonów systemowych, * rsyslogd rejestruje wszystkie informacje o pracy systemu, * jest uruchamiany jako jeden z pierwszych procesów i zamykany jako jeden z ostatnich, * konfiguracja rsyslogd znajduje się w pliku ///etc/rsyslog.conf// oraz w plikach w folderze ///etc/rsyslog.d// Konfiguracja rsyslogd: * plik //rsyslog.conf(5)// zawiera reguły według których rsyslogd sortuje informacje i zapisuje je do różnych plików rejestrowych, * reguła to dwa pola: ''selector action'', * ''selector'' ma 2 części ''facility.priority'', * ''facility'' określa system z którego pochodzi wiadomość np.: ''auth, kern, mail, rsyslog'', * ''priority'' mówi o stopniu ważności wiadomości, np.: ''debug, warn, err, emerg''. * w polu action może być wpisany plik, urządzenie sterujące terminalem, urządzenie drukarki. Pliki rejestrowe systemu: * nazwy i zawartość zależą od konfiguracji syslogd, * pliki rejestrów są plikami tekstowymi, * składają się z linii o określonym formacie, przeważnie jest to:<code>data godzina hostname proces: komunikat</code> * umieszczane są w katalogu ///var/log//, * niektóre duże programy jak nginx czy Apache mogą zakładać w ///var/log// własne katalogi z logami. === 5. Konfigurowanie interfejsów sieciowych === Konfigurowanie interfejsu sieciowego można podzielić na kilka etapów. * określenie parametrów (IP, maska, itp.), * konfigurownie przy pomocy ifconfig, * testowanie przy pomocy ping, * zapis konfiguracji w plikach dystrybucji systemu. Przed przystąpieniem do konfigurowania interfejsu trzeba ustalić jego podstawowe parametry. Są to: * adres IP, * maska sieci IP, * broadcast IP, * adres MAC, jeżli wykorzystuje się DHCP. **ifconfig** służy do konfigurowanie interfejsu sieciowego. * Podstawowy sposób wywołania to: <code>ifconfig if address adres netmask maska</code> * Włączanie, wyłącznie interfejsu: <code>ifconfig if up,down</code> * Wyświetlanie informacji o interfejsie: <code>ifconfig if</code> **ping** jest uniwersalnym programem będącym częścią narzędzi dla sieci TCP/IP. Program służy do testowania połączeń w sieci IP, wykorzystuje protokół ICMP (pakiety echo replay/requst). Interfejs loopback jest to wewnętrzny interfejs sieciowy, pełni rolę interfejsu zwrotnego, ma zawsze adres 127.0.0.1 i jest niezbędny do poprawnego działania aplikacji opartych o sieć TCP/IP. Dystrybucje mogą dostarczać: * programów typu **ifup**, **ifdown**, * plików opisujących konfigurację interfejsów ///etc/network//, ///etc/sysconfig/network//, * dodatkowych narzędzi konfiguracyjnych typu NetworkManager. Systemd posiada własny daemon ''systemd-networkd.service'', który wykorzystuje pliki konfiguracyjne zapisane w ///etc/systemd/network/// Przed przystąpieniem do konfigurowania tablicy routingu należy określić podstawowe parametry sieci do której włącza się interfejsy. Są to: * adresy interfejsów, * adresy sieci IP, * ewentualnie inne sieci do których określa się bezpośrednio dostęp, * adres routera przekazującego pakiety poza sieć, default route. Podstawowym programem do konfigurowania routingu jest program **route**. Program służy do: * zarządzania tablicą routingu, * tablica określa sposób przekazywania pakietów przez stos TCP/IP, * sposób użycia to:<code>route -v -n {add|del} {-host|-net} adres gw adres netmask maska interfejs</code> Do testowania routingu można użyć programu **traceroute**. Program służy do testowania routingu w sieci IP, wykorzystuje pole TTL pakietów IP i protokół UDP lub protokół ICMP. Resolver jest biblioteką będącą częścią biblioteki systemowej. Zajmuje się odnajdywaniem nazw maszyn pracujących w sieci. Jego konfiguracja składa się z kilku plików. Nazwę maszyny w sieci IP ustawia się przy pomocy polecenia hostname. Nazwę najczęściej zapisuje się na stałę w pliku ///etc/hostname// czytanym w trakcie startu systemu. Plik //host.conf// jest jednym z podstawowych elementów konfiguracji: zawiera część konfiguracji resolvera, opcje to: * ''order {hosts,bind,nis}'' - porządek odwoływania się do DNS i hosts, * ''trim on/off'' - usuwanie nazw domen * ''multi on/off'' - wielokrotne nazwy * ''nospoof,spoofalert,reorder on/off'' W pliku //resolv.conf// zapisuje się: * adresy serwerów DNS: nameserver addr, * nazwę lokalnej domeny: domain, * sposób przeszukiwania domen: search. Plik ///etc/hosts// zawiera istotne dla funkcjonowania resolvera informacje. Znajdują się w nim między innymi: * adresy IP lokalnych interfejsów (w tym musi być loopback), * nazwa FQDN maszyny, * adresy sieci podłączonych do interfejsów lokalnych, * adresy innych maszyn i sieci. Do testowania resolvera można użyć: * ping wraz z nazwą symboliczną (domenową), * narzędzi do pracy z DNS: **host**, **nslookup**, * powyższe dwa programy działają tylko w przypadku połączenia z serwerem DNS. ==== Ćwiczenia ==== UWAGA! W poniższych ćwiczeniach należy zwracać baczną uwagę na to, które z nich wymagają dostępu administratora. Warto sprawdzić które czynności mogą być wykonane z poziomu użytkownika! __Przed rozpoczęciem realizacji zadań, zainstaluj w systemie **nginx**, **at** i **mailutils**__: - ''apt-get update ; apt-get install -y at nginx mailutils'' - Podczas instalacji Postfix (serwera poczty) pojawi się ekran wyboru "General type of mail configuration" -- zostaw domyślną opcję "Internet Site"; w następnym ekranie możesz zostawić domyślną opcję (jako nazwę serwera) - Jeżeli pojawi się błąd podczas instalacji (''newaliases: fatal: file /etc/postfix/main.cf: parameter myhostname: bad parameter value: osboxes..'') trzeba usunąć dwie kropki z końca tej linii (aby myhostname miało wartość osboxes): \\ ''<nowiki>sed -e "s/osboxes../osboxes/g" /etc/postfix/main.cf > /etc/postfix/main.cf</nowiki>'' \\ i dokończyć instalację: \\ ''apt-get install -f'' === I. Zamykanie === - Zamknąć system przy pomocy **shutdown**. - Zamknąć system przy pomocy **shutdown** z opóźnieniem 3 minutowym, wysyłając przy tym stosowną informację do użytkowników. Sprawdzić jak wygląda ta informacja w konsoli innego użytkownika. === II. Start systemu === Zwrócić uwagę jak przebiega start systemu. \\ Po zalogowaniu jako root sprawdzić działanie plecenia **dmesg**. === III. Systemd === * Na początku zajęć zainstalowaliśmy **nginx** -- jest to popularny serwer www, ale co ważniejsze dla aktualnych zajęć - bardzo przyjazny do ćwiczeń z usługami i sygnałami (w kolejnej sekcji) - Sprawdzić jaki jest aktualny poziom pracy systemu za pomocą ''runlevel''. - Sprawdzić jaki jest domyślny tryb pracy systemu. - Przeczytać manual do ''runlevel''. Zmienić domyślny tryb pracy systemu (po każdej zmianie zrestartować system, aby sprawdzić wynik modyfikacji): * ''multi-user.target'' * ''rescue.target'' * ''reboot.target'' * ''graphical.target'' (to jako ostatnie, aby przywrócić do domyślnego trybu działania) * W przypadku problemów: w //GRUB// (przed załadowaniem systemu) do wyboru są Ubuntu i "Advanced options for Ubuntu" -> po wybraniu drugiej opcji można wybrać pozycję "... (recovery mode)" -> a później z listy można wybrać "root", aby dostać się do shella i naprawić system. - Sprawdź wszystkie usługi dostępne w systemie (''<nowiki>systemctl list-units --type=service</nowiki>'') - Wybierz jedną z dostępnych usług (punkt poprzedni; np. ''nginx.service'' albo ''cron.service'') -- jakie argumenty można przekazać do ''systemctl'', aby modyfikować jej stan? (uruchomić, zatrzymać, wymusić przeczytanie plików konfiguracyjnych, uruchomić ponownie, pokazać aktualny stan) - Przygotuj własną usługę. Aby to uczynić przygotuj odpowiedni plik ''*.service'', np. ''moj_skrypt.service'' w folderze ''/lib/systemd/system/'' * przejrzyj inne pliki *.service znajdujące się w folderze - jaką mają strukturę? * zawartość pliku może wyglądać np. tak: <code>[Unit] Description=Moj wlasny skrypt [Service] ExecStart=/root/skrypt.sh KillMode=process [Install] WantedBy=multi-user.target</code> * Przygotuj odpowiedni skrypt (wskazany w ExecStart), który robi coś (np. wypisuje coś na ekran) * Aktywuj usługę ''systemctl enable moj_skrypt.service'' (bez tego nie będzie brana pod uwagę) * Uruchom ponownie system * Sprawdź status ''moj_skrypt.service'' * Uruchom usługę ręcznie * Sprawdź jej status * Najczęściej w linii ''WantedBy='' pojawia się ''multi-user.target'' - dlaczego? - Obsługa klawiszy <Ctrl-Alt-Del> jest zależna od celu ''/lib/systemd/system/ctrl-alt-del.target'' -- domyślnie jest to ''reboot.target'', ale można to zmienić (np. na ''poweroff.target'' albo na brak reakcji) -- pobaw się tym chwilę. === IV. Procesy i sygnały === //W tej sekcji rozwiniemy wiedzę z [[lab_processes|Procesy i zadania]] -- tam pierwszy raz korzystaliśmy z ps, kill, nice// - Jakich opcji ps należy użyć, aby obejrzeć: - proces ''init'' [czy to naprawdę jest proces init z System V czy może systemd? jak to sprawdzić?], - PID procesów, - PPID procesów, - środowisko procesów, - informacje o zużyciu pamięci przez procesy. - Jak przy pomocy **ps** i innego polecenia można obejrzeć procesy wybranego użytkownika? - Jako zwykły użytkownik uruchomić proces **find** (albo dowolny inny proces, który długo trwa - np. **nano**, **vim**). Jako root odnaleźć jego PID i usunąć proces. Czy da się tak zrobić w drugą stronę (zwykły użytkownik usuwa proces roota)? - Powtórzyć kilkakrotnie wcześniejsze ćwiczenie, za każdym razem usuwając proces innym sygnałem. Jakie pojawiają się komunikaty? - Jak można przy pomocy jednokrotnego użycia kill usunąć **wszystkie** procesy w danej sesji? Przetestuj ;-) - Jaki sygnał należy wysłać do demona systemowego by przeczytał swoją konfigurację? * Możesz przetestować na nginx.service ([[http://nginx.org/en/docs/control.html|przydatna ściągawka obsługiwanych sygnałów]]). * Uwaga: w przypadku nginx przeczytanie konfiguracji jest równoznaczne z zakończeniem działania "worker processes" i uruchomieniem nowych "workerów", więc oczekiwany efekt to zmiana PIDów procesów w sekcji ''CGroup'' po wykonaniu ''systemctl status nginx'' (master process się nie zmienia, ale powinny zmienić się worker processes) * Jaka komenda ''systemctl'' pozwala osiągnąć taki sam efekt? - Przy pomocy **ps** wyświetlić wartości nice procesów. - Uruchomić proces **find** z nice 10. Jak zmienić wartość nice tego procesu? Czy root ma większe uprawnienia? Sprawdź. - Zmienić wartość nice dla powłoki w której się pracuje. - Uruchomić w tle 3 procesy find, z nice odpowiednio -5, 0 i 19. Który z nich zakończy się pierwszy? Zmierzyć czas ich działania przy pomocy **time**. === V. Polecenia at i cron === - Sprawdź czy w systemie działa daemon **atd** (sprawdzić!) - Przy pomocy polecenia **at** proszę zlecić uruchomienie: - **who** za godzinę, - **ps** w najbliższą niedzielę, - **df** jutro o tej samej porze. - Proszę oglądnąć kolejkę zleceń (jakim poleceniem?) i zawartość skryptów zleceń. - Powtórzyć ćwiczenie 1. dla poleceń, które nie wypisują informacji na wyjściu. Czy został wysłany list z raportem (sprawdzić przez **mail**)? Jeżeli nie, to jak wymusić wysłanie raportu pocztą elektroniczną? - W sesji administratora zabronić dostępu do **at** wybranemu użytkownikowi. Sprawdzić jak działa kontrola dostępu. - Uruchamiać przy pomocy **cron** wybrane polecenie: - co godzinę, - co pół godziny, - w każdy poniedziałek o 6:00, - codziennie, o 6:20, 8:20, 12:20, 18:20, - co 4 godziny, ale tylko od poniedziałku do piątku, - o 12:00, 13:00, 14:00, 15:00; w 1., 13., 20. dzień każdego miesiąca. - Jak uruchamiać program codziennie korzystając z cron, ale bez modyfikacji pliku crontab? - Założyć katalog ///etc/cron.new// i tak skonfigurować demon cron, by pliki wykonywalne w tym katalogu były uruchamiane 3 razy dziennie. === VI. Konfiguracja rsyslogd === Do testowania rsyslogd można użyć polecenia **logger**, które wysyła wiadomości do **rsyslogd**: * Wywołanie polecenia jest następujące: <code>logger [-p facility.priority] wiadomosc</code> * //Użycie parametru ''-p'' jest opcjonalne.// * Dodatkowo można etykietować wpisy przez ''-t''. - Skonfigurować rsyslogd tak, aby odpowiednie komunikaty były kierowane do podanych plików. <code> źródło priorytet plik ------- ---------- ----- user wszystkie user.log user warning user_warn.log daemon wszystkie daemon.log local7 info local.log local7 niższe od err local_err.log mail i uucp wszystkie mail.log security i auth wszystkie security.log wszystkie emerg emerg.log wszystkie wszystkie all_messages.log </code> Co należy zrobić, aby zmiany w konfiguracji odniosły skutek? Proszę przetestować wprowadzone zmiany przy pomocy polecenia **logger**. === VII. Rotacja plików rejestrowych === - Skonfigurować system Cron w ten sposób by programy **logrotate** lub **savelog** były uruchamiane: - w każdą niedzielę o 23:00, - 30. dnia miesiąca o 5:00, - codziennie o 2:00. - Proszę skonfigurować logrotate aby dokonywał rotacji plików: - ///var/log/messages// codziennie, kompresował je i zachowywał 8 poprzednich fragmentów, - ///var/log/security// codziennie, bez kompresji i datę każdej rotacji zapisywał w pliku ///var/log/rotate.log//, - ///var/log/debug// co tydzień, bez kompresji. === VIII. Podstawy konfigurowania interfejsów sieciowych === - Sprawdzić bieżącą konfigurację interfejsu i zapisać ją. - Sprawdzić łączność z innymi maszynami przez **ping**. - Przeglądnąć bieżącą konfigurację routingu przez **route**. - Przetestować łączność z wybranym odległym serwerem (np. uj.edu.pl, google.com) przez **traceroute**. - Oglądnąć ///etc/resolv.conf// sprawdzić działanie DNS przez **host**, **dig**, **nslookup**. - Sprawdzić pola MX dla różnych domen, wskazują one na Mail eXchangery domeny (serwery poczty), np.: ''dig uj.edu.pl mx'' courses/unix/lab_admin2.txt Last modified: 23 months agoby kkt