• man systemd(1)
• man systemctl(1)
• man crontab(5)
• Konfigurowanie i zastosowanie systemu Cron
• 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ć)

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.

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

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.

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:

  data godzina hostname proces: komunikat

• 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.

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:

  ifconfig if address adres netmask maska

• Włączanie, wyłącznie interfejsu:

  ifconfig if up,down

• Wyświetlanie informacji o interfejsie:

  ifconfig if

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:

  route -v -n {add|del} {-host|-net} adres gw adres netmask maska interfejs

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.

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:

1. apt-get update ; apt-get install -y at nginx mailutils
2. 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)
3. 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):
   sed -e "s/osboxes../osboxes/g" /etc/postfix/main.cf > /etc/postfix/main.cf
   i dokończyć instalację:
   apt-get install -f

1. Zamknąć system przy pomocy shutdown.
2. 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.

Zwrócić uwagę jak przebiega start systemu.
Po zalogowaniu jako root sprawdzić działanie plecenia dmesg.

• 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)

1. Sprawdzić jaki jest aktualny poziom pracy systemu za pomocą runlevel.
2. Sprawdzić jaki jest domyślny tryb pracy systemu.
3. 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.
4. Sprawdź wszystkie usługi dostępne w systemie (systemctl list-units --type=service)
5. 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)
6. 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:

     [Unit]
     Description=Moj wlasny skrypt
     [Service]
     ExecStart=/root/skrypt.sh
     KillMode=process
     [Install]
     WantedBy=multi-user.target

   • 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?
7. 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ę.

W tej sekcji rozwiniemy wiedzę z Procesy i zadania – tam pierwszy raz korzystaliśmy z ps, kill, nice

1. Jakich opcji ps należy użyć, aby obejrzeć:
   1. proces init [czy to naprawdę jest proces init z System V czy może systemd? jak to sprawdzić?],
   2. PID procesów,
   3. PPID procesów,
   4. środowisko procesów,
   5. informacje o zużyciu pamięci przez procesy.
2. Jak przy pomocy ps i innego polecenia można obejrzeć procesy wybranego użytkownika?
3. 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)?
4. Powtórzyć kilkakrotnie wcześniejsze ćwiczenie, za każdym razem usuwając proces innym sygnałem. Jakie pojawiają się komunikaty?
5. Jak można przy pomocy jednokrotnego użycia kill usunąć wszystkie procesy w danej sesji? Przetestuj
6. Jaki sygnał należy wysłać do demona systemowego by przeczytał swoją konfigurację?
   • Możesz przetestować na nginx.service (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?
7. Przy pomocy ps wyświetlić wartości nice procesów.
8. Uruchomić proces find z nice 10. Jak zmienić wartość nice tego procesu? Czy root ma większe uprawnienia? Sprawdź.
9. Zmienić wartość nice dla powłoki w której się pracuje.
10. 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.

1. Sprawdź czy w systemie działa daemon atd (sprawdzić!)
2. Przy pomocy polecenia at proszę zlecić uruchomienie:
   1. who za godzinę,
   2. ps w najbliższą niedzielę,
   3. df jutro o tej samej porze.
3. Proszę oglądnąć kolejkę zleceń (jakim poleceniem?) i zawartość skryptów zleceń.
4. 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ą?
5. W sesji administratora zabronić dostępu do at wybranemu użytkownikowi. Sprawdzić jak działa kontrola dostępu.
6. Uruchamiać przy pomocy cron wybrane polecenie:
   1. co godzinę,
   2. co pół godziny,
   3. w każdy poniedziałek o 6:00,
   4. codziennie, o 6:20, 8:20, 12:20, 18:20,
   5. co 4 godziny, ale tylko od poniedziałku do piątku,
   6. o 12:00, 13:00, 14:00, 15:00; w 1., 13., 20. dzień każdego miesiąca.
7. Jak uruchamiać program codziennie korzystając z cron, ale bez modyfikacji pliku crontab?
8. Założyć katalog /etc/cron.new i tak skonfigurować demon cron, by pliki wykonywalne w tym katalogu były uruchamiane 3 razy dziennie.

Do testowania rsyslogd można użyć polecenia logger, które wysyła wiadomości do rsyslogd:

• Wywołanie polecenia jest następujące:

  logger [-p facility.priority] wiadomosc

• Użycie parametru -p jest opcjonalne.
• Dodatkowo można etykietować wpisy przez -t.

1. Skonfigurować rsyslogd tak, aby odpowiednie komunikaty były kierowane do podanych plików.

ź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

Co należy zrobić, aby zmiany w konfiguracji odniosły skutek? Proszę przetestować wprowadzone zmiany przy pomocy polecenia logger.

1. Skonfigurować system Cron w ten sposób by programy logrotate lub savelog były uruchamiane:
   1. w każdą niedzielę o 23:00,
   2. 30. dnia miesiąca o 5:00,
   3. codziennie o 2:00.
2. Proszę skonfigurować logrotate aby dokonywał rotacji plików:
   1. /var/log/messages codziennie, kompresował je i zachowywał 8 poprzednich fragmentów,
   2. /var/log/security codziennie, bez kompresji i datę każdej rotacji zapisywał w pliku /var/log/rotate.log,
   3. /var/log/debug co tydzień, bez kompresji.

1. Sprawdzić bieżącą konfigurację interfejsu i zapisać ją.
2. Sprawdzić łączność z innymi maszynami przez ping.
3. Przeglądnąć bieżącą konfigurację routingu przez route.
4. Przetestować łączność z wybranym odległym serwerem (np. uj.edu.pl, google.com) przez traceroute.
5. Oglądnąć /etc/resolv.conf sprawdzić działanie DNS przez host, dig, nslookup.
6. Sprawdzić pola MX dla różnych domen, wskazują one na Mail eXchangery domeny (serwery poczty), np.: dig uj.edu.pl mx