Kolejne 50 popularnych pytań dotyczących systemu Linux. Pytania i odpowiedzi

Pierwsza część wpisu „50 popularnych pytań dotyczących systemu Linux zadawanych na rozmowach kwalifikacyjnych” okazała się jednym z tych materiałów, do których czytelnicy wracają nawet po latach. To dobry znak, bo Linux wciąż pozostaje jednym z najważniejszych systemów w świecie serwerów, administracji, DevOps, chmury, cyberbezpieczeństwa i środowisk developerskich.

Od czasu publikacji pierwszej części Linux stał się jeszcze bardziej obecny w codziennej pracy administratorów, programistów, testerów, inżynierów infrastruktury i osób odpowiedzialnych za bezpieczeństwo. Spotykamy go już nie tylko na klasycznych serwerach, ale także w kontenerach, środowiskach chmurowych, rozwiązaniach embedded, systemach CI/CD, komputerach developerskich, urządzeniach sieciowych i platformach do automatyzacji.

Dlatego najwyższa pora dopisać drugą część. Tym razem skupimy się na kolejnych zagadnieniach, które często pojawiają się podczas nauki, codziennej pracy administratora lub rozmów kwalifikacyjnych. Nie powtarzamy tematów z pierwszego wpisu, ale rozszerzamy wiedzę o praktyczne obszary: systemd, logi, pakiety, użytkowników, procesy, dyski, sieć, SSH, kontenery i bezpieczeństwo.

Forma pozostaje taka sama: krótkie pytanie i konkretna odpowiedź. Celem nie jest stworzenie akademickiego podręcznika, ale praktycznej ściągi, która pomoże szybko uporządkować wiedzę, przypomnieć sobie najważniejsze pojęcia i lepiej przygotować się do rozmów technicznych lub codziennej pracy z Linuxem.

51. Co to jest systemd w systemie Linux?

Systemd jest menedżerem systemu i usług, który odpowiada za uruchamianie systemu operacyjnego oraz zarządzanie usługami działającymi w tle. W wielu współczesnych dystrybucjach Linux zastąpił starsze rozwiązania typu SysVinit.

Systemd uruchamia usługi, montuje systemy plików, obsługuje logowanie zdarzeń, zarządza zależnościami między usługami i kontroluje kolejność startu poszczególnych elementów systemu. To właśnie on decyduje, które usługi mają zostać uruchomione podczas startu systemu, w jakiej kolejności i pod jakimi warunkami.

W praktyce systemd jest jednym z najważniejszych elementów współczesnego Linuxa. Administrator korzysta z niego wtedy, gdy chce sprawdzić, dlaczego usługa nie działa, włączyć automatyczne uruchamianie aplikacji po restarcie serwera albo przeanalizować logi związane z uruchamianiem systemu.

Podstawowym poleceniem do pracy z systemd jest:

systemctl

Przykład:

systemctl status ssh

Polecenie pokazuje status usługi SSH. W wyniku zobaczymy m.in. informację, czy usługa jest aktywna, kiedy została uruchomiona, jaki ma identyfikator procesu oraz ostatnie komunikaty logów.

Przykładowe przydatne polecenia:

systemctl start ssh
systemctl stop ssh
systemctl restart ssh
systemctl enable ssh
systemctl disable ssh

Dzięki nim można uruchomić, zatrzymać, zrestartować oraz ustawić automatyczne uruchamianie usługi przy starcie systemu.

52. Co to jest jednostka systemd, czyli unit?

Jednostka systemd, określana jako unit, to plik opisujący zasób zarządzany przez systemd. Najczęściej spotykanym typem jednostki jest usługa, czyli plik z rozszerzeniem .service.

Unit może opisywać nie tylko usługę, ale również punkt montowania, timer, socket, urządzenie lub grupę usług. Dzięki temu systemd może zarządzać wieloma elementami systemu w jednolity sposób.

Przykładowe typy jednostek systemd:

• .service — usługi systemowe,

• .target — grupy usług uruchamiane razem,

• .timer — zadania uruchamiane cyklicznie,

• .mount — punkty montowania,

• .socket — gniazda sieciowe lub lokalne,

• .device — urządzenia wykrywane przez system,

• .path — jednostki reagujące na zmiany w plikach lub katalogach.

Przykładowa nazwa jednostki:

sshd.service

W praktyce administrator najczęściej pracuje z usługami, sprawdzając ich status, uruchamiając je, zatrzymując lub włączając automatyczny start.

Pliki jednostek znajdują się zwykle w katalogach:

/lib/systemd/system/
/etc/systemd/system/

Pierwszy katalog zawiera pliki dostarczone przez pakiety systemowe, a drugi lokalne modyfikacje administratora. Jeżeli administrator chce nadpisać domyślne ustawienia usługi, powinien robić to ostrożnie, najlepiej przez mechanizm drop-in, a nie przez ręczną edycję oryginalnego pliku dostarczonego przez pakiet.

53. Jak sprawdzić status usługi w systemie Linux?

W systemach korzystających z systemd status usługi można sprawdzić poleceniem:

systemctl status nazwa_usługi

Przykład:

systemctl status apache2

lub w systemach Red Hat / Rocky / Fedora:

systemctl status httpd

Wynik pokaże, czy usługa działa, od kiedy jest uruchomiona, jaki ma numer PID oraz czy w ostatnim czasie wystąpiły błędy. To często pierwszy krok diagnostyczny, gdy aplikacja nie odpowiada albo serwer nie działa zgodnie z oczekiwaniami.

Najważniejsze stany usługi to:

• active (running) — usługa działa,

• inactive — usługa jest zatrzymana,

• failed — usługa zakończyła się błędem,

• enabled — usługa uruchamia się automatycznie przy starcie systemu,

• disabled — usługa nie startuje automatycznie.

Warto odróżniać status działania od statusu automatycznego startu. Usługa może być aktualnie uruchomiona, ale jednocześnie nie być włączona do startu po restarcie systemu.

Sprawdzenie, czy usługa startuje automatycznie:

systemctl is-enabled apache2

Sprawdzenie, czy usługa jest aktywna:

systemctl is-active apache2

Takie polecenia przydają się w skryptach administracyjnych, ponieważ zwracają prostą odpowiedź, którą można dalej przetwarzać.

54. Jaka jest różnica między restart a reload usługi?

Polecenie restart zatrzymuje usługę i uruchamia ją ponownie. Oznacza to krótką przerwę w jej działaniu.

systemctl restart nginx

Polecenie reload przeładowuje konfigurację usługi bez pełnego zatrzymania procesu, o ile dana usługa obsługuje taką możliwość.

systemctl reload nginx

W praktyce reload jest bezpieczniejszy dla usług produkcyjnych, ponieważ pozwala wczytać nową konfigurację bez przerywania aktualnych połączeń. Nie każda usługa obsługuje jednak reload, dlatego czasem konieczny jest restart.

Dobrym przykładem jest serwer WWW. Po zmianie konfiguracji Nginx często można wykonać reload, dzięki czemu aktywne połączenia użytkowników nie zostaną nagle zerwane. Z kolei przy zmianie wersji aplikacji, aktualizacji pakietu albo poważniejszej zmianie konfiguracji może być wymagany pełny restart.

Przed przeładowaniem konfiguracji warto sprawdzić jej poprawność. Dla Nginx można użyć:

nginx -t

Dla Apache:

apachectl configtest

To dobra praktyka, ponieważ błędna konfiguracja może spowodować, że po restarcie usługa nie wstanie.

55. Do czego służy polecenie journalctl?

journalctl służy do przeglądania logów zbieranych przez systemd-journald. Jest to bardzo przydatne narzędzie podczas diagnostyki problemów z usługami, startem systemu lub błędami aplikacji.

Dawniej administratorzy często zaczynali analizę od plików w katalogu /var/log. Nadal są one ważne, ale w systemach opartych o systemd bardzo często pierwszym miejscem do sprawdzenia problemu jest właśnie journalctl.

Przykłady użycia:

journalctl

Wyświetlenie logów systemowych.

journalctl -u ssh

Wyświetlenie logów konkretnej usługi.

journalctl -u nginx -f

Podgląd logów usługi nginx na żywo.

journalctl -b

Wyświetlenie logów od ostatniego uruchomienia systemu.

Można też sprawdzić logi z poprzedniego uruchomienia systemu:

journalctl -b -1

Jest to szczególnie przydatne, gdy system zawiesił się, został zrestartowany albo usługa nie podniosła się poprawnie po restarcie.

Logi z konkretnego zakresu czasu:

journalctl --since "2026-06-01 08:00" --until "2026-06-01 10:00"

Journalctl jest jednym z pierwszych narzędzi, po które warto sięgnąć, gdy usługa nie startuje lub działa nieprawidłowo.

56. Jaka jest różnica między su a sudo?

su służy do przełączenia się na innego użytkownika, najczęściej na konto root. Po użyciu su trzeba znać hasło użytkownika, na którego chcemy się przełączyć.

su -

sudo pozwala wykonać pojedyncze polecenie z podwyższonymi uprawnieniami, zwykle bez pełnego przełączania sesji na konto root.

sudo apt update

W nowoczesnych systemach preferuje się sudo, ponieważ pozwala lepiej kontrolować, kto i jakie polecenia może wykonywać z uprawnieniami administratora. Dodatkowo operacje wykonane przez sudo są łatwiejsze do audytowania.

W praktyce oznacza to, że administrator nie musi znać hasła roota. Użytkownik należy do odpowiedniej grupy, np. sudo w Ubuntu lub wheel w wielu systemach Red Hat/Fedora, i może wykonywać wybrane polecenia z uprawnieniami administracyjnymi.

Sprawdzenie, do jakich grup należy użytkownik:

groups

Edycja konfiguracji sudo powinna być wykonywana poleceniem:

visudo

visudo sprawdza poprawność składni przed zapisaniem zmian. To ważne, ponieważ błąd w pliku sudoers może zablokować możliwość wykonywania poleceń administracyjnych.

57. Do czego służą pliki /etc/passwd, /etc/shadow i /etc/group?

Pliki te przechowują podstawowe informacje o użytkownikach i grupach w systemie Linux.

/etc/passwd zawiera listę kont użytkowników, ich identyfikatory UID, identyfikatory grup GID, katalogi domowe oraz domyślne powłoki.

/etc/shadow przechowuje informacje o hasłach w postaci zaszyfrowanych skrótów oraz dane dotyczące ważności hasła.

/etc/group zawiera informacje o grupach systemowych oraz członkostwie użytkowników w grupach.

Przykładowy wpis w /etc/passwd:

jan:x:1001:1001:Jan Kowalski:/home/jan:/bin/bash

Poszczególne pola oznaczają nazwę użytkownika, dawniej miejsce na hasło, UID, GID, opis konta, katalog domowy oraz domyślną powłokę.

Warto zauważyć, że znak x w drugim polu nie oznacza hasła. Oznacza, że właściwy skrót hasła znajduje się w /etc/shadow, który jest dostępny tylko dla uprawnionych procesów i administratora.

Nie należy ręcznie edytować tych plików bez potrzeby. Bezpieczniej korzystać z narzędzi takich jak useradd, usermod, passwd lub groupadd.

Przykłady:

passwd jan
usermod -aG sudo jan
groupadd developers

Błąd w tych plikach może doprowadzić do problemów z logowaniem, dlatego wszelkie zmiany należy wykonywać ostrożnie.

58. Jaka jest różnica między useradd a adduser?

useradd jest niskopoziomowym poleceniem do tworzenia kont użytkowników. Działa bezpośrednio i wymaga podania większej liczby parametrów, jeżeli chcemy od razu utworzyć katalog domowy, ustawić powłokę czy dodatkowe informacje.

Przykład:

useradd -m -s /bin/bash jan

adduser jest bardziej przyjaznym narzędziem, często dostępnym w dystrybucjach Debian/Ubuntu. Prowadzi użytkownika przez proces tworzenia konta i automatycznie wykonuje część typowych czynności.

Przykład:

adduser jan

W praktyce adduser jest wygodniejszy dla początkujących administratorów, a useradd częściej wykorzystywany jest w skryptach i automatyzacji.

Różnica ta bywa ważna podczas pisania instrukcji. Polecenie, które działa w Ubuntu, nie zawsze będzie dostępne w identycznej formie w minimalnym systemie serwerowym innej dystrybucji. W środowiskach automatyzowanych często lepiej używać bardziej przewidywalnych narzędzi albo modułów Ansible, Puppet czy innych systemów zarządzania konfiguracją.

Po utworzeniu konta często wykonuje się dodatkowe czynności:

passwd jan
usermod -aG sudo jan
chage -l jan

Pierwsze polecenie ustawia hasło, drugie dodaje użytkownika do grupy sudo, a trzecie pokazuje informacje o ważności hasła.

59. Co to jest UID i GID?

UID, czyli User ID, to numeryczny identyfikator użytkownika w systemie Linux. GID, czyli Group ID, to numeryczny identyfikator grupy.

System Linux wewnętrznie rozpoznaje właścicieli plików i procesów po numerach UID i GID, a nie po samych nazwach tekstowych. Nazwy użytkowników i grup są wygodne dla człowieka, ale dla systemu kluczowe są właśnie numery.

Przykład sprawdzenia identyfikatorów użytkownika:

id

Przykładowy wynik:

uid=1000(mariusz) gid=1000(mariusz) groups=1000(mariusz),27(sudo)

UID 0 jest zarezerwowany dla konta root, czyli konta o najwyższych uprawnieniach w systemie.

W praktyce UID i GID mają duże znaczenie przy migracji danych, montowaniu udziałów sieciowych, pracy z kontenerami oraz współdzieleniu plików między systemami. Jeżeli dwa systemy mają użytkowników o tej samej nazwie, ale z innymi UID, mogą pojawić się problemy z uprawnieniami.

Sprawdzenie właścicieli plików:

ls -ln

Opcja -n pokazuje numery UID i GID zamiast nazw. Jest to przydatne podczas diagnostyki problemów z mapowaniem użytkowników.

60. Co to jest umask?

umask określa domyślne uprawnienia, które są odejmowane podczas tworzenia nowych plików i katalogów.

Przykład sprawdzenia aktualnej wartości:

umask

Typowa wartość to:

0022

Oznacza to, że nowe pliki i katalogi nie będą domyślnie zapisywalne dla grupy i innych użytkowników.

W uproszczeniu:

• pliki zwykle startują z bazowych uprawnień 666,

• katalogi zwykle startują z bazowych uprawnień 777,

• wartość umask odejmuje odpowiednie prawa.

Dla umask 022 nowy katalog otrzyma zwykle uprawnienia 755, a nowy plik 644.

Przykładowo, bardziej restrykcyjna wartość:

umask 077

spowoduje, że nowe pliki będą dostępne wyłącznie dla właściciela. Takie ustawienie bywa użyteczne dla kont technicznych, skryptów przetwarzających poufne dane albo środowisk, gdzie dostęp innych użytkowników powinien być domyślnie zablokowany.

Umask można ustawiać globalnie, dla konkretnego użytkownika albo dla konkretnej usługi systemowej. Warto o nim pamiętać, gdy nowe pliki tworzą się z „dziwnymi” albo zbyt szerokimi uprawnieniami.

61. Co to są ACL w systemie Linux?

ACL, czyli Access Control Lists, umożliwiają bardziej szczegółowe zarządzanie uprawnieniami do plików i katalogów niż klasyczny model właściciel-grupa-inni.

Dzięki ACL można nadać konkretnemu użytkownikowi lub konkretnej grupie dodatkowe prawa do pliku bez zmiany podstawowego właściciela i grupy.

Sprawdzenie ACL:

getfacl plik.txt

Nadanie użytkownikowi prawa odczytu i zapisu:

setfacl -m u:jan:rw plik.txt

Usunięcie wpisu ACL:

setfacl -x u:jan plik.txt

ACL przydają się szczególnie na serwerach plików oraz w środowiskach, gdzie kilka zespołów potrzebuje różnego poziomu dostępu do tych samych danych.

Można także ustawić domyślne ACL dla katalogu. Dzięki temu nowe pliki tworzone w tym katalogu odziedziczą określone uprawnienia:

setfacl -d -m g:developers:rwx /projekty/aplikacja

To rozwiązanie jest wygodne w katalogach projektowych, gdzie wiele osób pracuje na tych samych plikach. Trzeba jednak pamiętać, że ACL zwiększają złożoność zarządzania uprawnieniami. Jeżeli dostęp do pliku nie wynika jasno z klasycznych uprawnień, warto sprawdzić ACL, zanim uznamy, że system działa nieprawidłowo.

62. Co oznaczają uprawnienia SUID, SGID i sticky bit?

SUID, SGID i sticky bit to specjalne uprawnienia w systemie Linux.

SUID powoduje, że program uruchamia się z uprawnieniami właściciela pliku, a nie użytkownika, który go uruchomił. Klasycznym przykładem jest polecenie passwd, które musi mieć możliwość modyfikowania informacji o haśle.

SGID na pliku działa podobnie, ale dotyczy grupy. Na katalogu powoduje, że nowe pliki tworzone wewnątrz dziedziczą grupę katalogu.

Sticky bit najczęściej stosuje się na katalogach współdzielonych, takich jak /tmp. Powoduje, że użytkownik może usuwać tylko swoje pliki, nawet jeżeli katalog jest zapisywalny dla wielu użytkowników.

Przykład katalogu /tmp:

drwxrwxrwt

Litera t na końcu oznacza ustawiony sticky bit.

Specjalne uprawnienia można ustawiać numerycznie. Przykładowo:

chmod 4755 plik
chmod 2775 katalog
chmod 1777 katalog

Pierwsza cyfra oznacza odpowiednio SUID, SGID lub sticky bit. Trzeba używać ich ostrożnie, szczególnie SUID, ponieważ błędnie ustawione uprawnienie może stworzyć poważną lukę bezpieczeństwa.

W audytach bezpieczeństwa często sprawdza się pliki z ustawionym SUID:

find / -perm -4000 -type f 2>/dev/null

Dzięki temu można wykryć programy, które uruchamiają się z podwyższonymi uprawnieniami.

63. Do czego służą polecenia chown i chgrp?

chown służy do zmiany właściciela pliku lub katalogu.

Przykład:

chown jan plik.txt

Zmiana właściciela i grupy jednocześnie:

chown jan:developers plik.txt

chgrp służy do zmiany samej grupy przypisanej do pliku lub katalogu.

Przykład:

chgrp developers plik.txt

Dla katalogów często stosuje się przełącznik -R, który wykonuje zmianę rekurencyjnie:

chown -R jan:developers /dane/projekt

Należy używać go ostrożnie, ponieważ błędna rekurencyjna zmiana właścicieli może zepsuć uprawnienia w dużej części systemu.

Szczególnie niebezpieczne są pomyłki w ścieżce, np. przypadkowe wykonanie polecenia na katalogu głównym albo na zbyt szerokim zakresie danych. Przed użyciem -R warto sprawdzić polecenie dwa razy.

Przydatnym rozwiązaniem jest wcześniejsze sprawdzenie, które pliki zostaną objęte zmianą:

find /dane/projekt -maxdepth 2 -ls

W systemach produkcyjnych zmiany właścicieli plików powinny być wykonywane świadomie, ponieważ mogą wpłynąć na działanie usług, dostęp aplikacji do danych i bezpieczeństwo całego środowiska.

64. Jaka jest różnica między find a locate?

find przeszukuje system plików w czasie rzeczywistym. Jest dokładny, ale przy dużej liczbie plików może działać wolniej.

Przykład:

find /var/log -name "*.log"

locate korzysta z wcześniej zbudowanej bazy plików. Dzięki temu działa bardzo szybko, ale może nie znaleźć plików utworzonych po ostatniej aktualizacji bazy.

Przykład:

locate nginx.conf

Aktualizacja bazy dla locate:

updatedb

W praktyce find jest lepszy do precyzyjnego wyszukiwania z warunkami, a locate do szybkiego odnalezienia pliku po nazwie.

find potrafi szukać nie tylko po nazwie, ale również po typie pliku, właścicielu, rozmiarze, dacie modyfikacji czy uprawnieniach.

Przykład znalezienia plików większych niż 100 MB:

find /var -type f -size +100M

Przykład znalezienia plików modyfikowanych w ciągu ostatnich 24 godzin:

find /etc -type f -mtime -1

To jedno z najpotężniejszych narzędzi administracyjnych w Linuxie, szczególnie przy sprzątaniu systemu, audytach i diagnostyce problemów.

65. Do czego służy rsync?

rsync służy do synchronizacji plików i katalogów lokalnie lub między różnymi komputerami. Jego dużą zaletą jest to, że potrafi przesyłać tylko różnice między plikami, a nie zawsze całą zawartość od początku.

Przykład lokalnej synchronizacji:

rsync -av /dane/ /backup/dane/

Przykład synchronizacji na zdalny serwer:

rsync -av /dane/ user@server:/backup/dane/

Popularne opcje:

• -a — tryb archiwum, zachowuje uprawnienia i strukturę,

• -v — tryb szczegółowy,

• -z — kompresja danych podczas transferu,

• --delete — usuwa z celu pliki, których nie ma już w źródle.

Opcji --delete należy używać ostrożnie, szczególnie w skryptach backupowych.

Bardzo przydatna jest opcja testowa:

rsync -av --dry-run /dane/ /backup/dane/

Dzięki --dry-run można zobaczyć, co zostałoby zsynchronizowane, bez faktycznego wykonywania zmian. To szczególnie ważne przed użyciem --delete.

Warto też zwracać uwagę na ukośnik na końcu ścieżki. Polecenie:

rsync -av /dane/ /backup/dane/

kopiuje zawartość katalogu /dane, natomiast:

rsync -av /dane /backup/

może utworzyć katalog /backup/dane. Ta różnica często zaskakuje początkujących użytkowników.

66. Co to jest menedżer pakietów w systemie Linux?

Menedżer pakietów służy do instalowania, aktualizowania i usuwania oprogramowania. Dba również o zależności, czyli dodatkowe biblioteki i pakiety wymagane przez instalowany program.

Przykładowe menedżery pakietów:

• apt — Debian, Ubuntu,

• dnf — Fedora, Red Hat, Rocky Linux, AlmaLinux,

• yum — starsze systemy Red Hat/CentOS,

• zypper — openSUSE,

• pacman — Arch Linux.

Przykład instalacji pakietu w Ubuntu:

sudo apt install nginx

Przykład instalacji pakietu w systemach Red Hat/Rocky:

sudo dnf install nginx

Menedżer pakietów jest bezpieczniejszym sposobem instalacji niż ręczne pobieranie przypadkowych plików z Internetu.

Pakiety pochodzące z repozytoriów są zwykle podpisane, sprawdzone i dopasowane do konkretnej wersji systemu. Menedżer pakietów wie, jakie pliki zostały zainstalowane, do którego pakietu należą i jakie zależności są potrzebne do poprawnego działania aplikacji.

Dzięki temu można łatwo aktualizować cały system:

sudo apt update && sudo apt upgrade

albo usunąć pakiet:

sudo apt remove nginx

W środowiskach firmowych często używa się wewnętrznych mirrorów lub repozytoriów, aby mieć kontrolę nad wersjami oprogramowania, dostępnością pakietów i bezpieczeństwem aktualizacji.

67. Jaka jest różnica między apt update a apt upgrade?

apt update odświeża lokalną listę dostępnych pakietów z repozytoriów. Nie instaluje jeszcze aktualizacji.

sudo apt update

apt upgrade instaluje dostępne aktualizacje pakietów, które już są zainstalowane w systemie.

sudo apt upgrade

W uproszczeniu:

• apt update sprawdza, co jest dostępne,

• apt upgrade wykonuje aktualizację.

Często używa się ich razem:

sudo apt update && sudo apt upgrade

Jeżeli po apt update system pokazuje błędy repozytoriów, brak klucza GPG albo problem z certyfikatem, samo apt upgrade może nie zadziałać poprawnie. Dlatego przy problemach z aktualizacją najpierw należy naprawić źródła pakietów.

Przydatne polecenie do sprawdzenia dostępnych aktualizacji:

apt list --upgradable

Pozwala zobaczyć, które pakiety mają nowsze wersje. W systemach produkcyjnych taka lista bywa analizowana przed wykonaniem aktualizacji, szczególnie jeśli dotyczy usług krytycznych.

68. Czym różni się apt upgrade od apt full-upgrade?

apt upgrade aktualizuje pakiety, ale stara się nie usuwać istniejących pakietów i nie wykonywać bardziej agresywnych zmian w zależnościach.

apt full-upgrade może zainstalować nowe zależności lub usunąć pakiety, jeżeli jest to wymagane do pełnej aktualizacji systemu.

sudo apt full-upgrade

Polecenie full-upgrade bywa potrzebne przy większych aktualizacjach systemu, ale wymaga większej ostrożności. Przed zatwierdzeniem warto przeczytać, które pakiety zostaną usunięte lub zmienione.

Różnica jest szczególnie istotna przy aktualizacjach jądra, bibliotek systemowych i przejściach między większymi wersjami dystrybucji. full-upgrade może rozwiązać bardziej złożone zależności, ale jednocześnie może usunąć pakiet, który administrator uważa za ważny.

Dlatego w środowiskach serwerowych warto najpierw wykonać symulację lub bardzo dokładnie przeczytać podsumowanie zmian przed wpisaniem Y.

Pomocne polecenie:

sudo apt -s full-upgrade

Opcja -s wykonuje symulację i pokazuje, co zostałoby zmienione, bez realnej instalacji.

69. Co to jest repozytorium pakietów?

Repozytorium pakietów to miejsce, z którego system pobiera oprogramowanie i aktualizacje. Może to być oficjalny serwer dystrybucji, wewnętrzny mirror firmowy albo dodatkowe repozytorium dostawcy konkretnego oprogramowania.

W systemach Debian/Ubuntu repozytoria są definiowane m.in. w pliku:

/etc/apt/sources.list

oraz w katalogu:

/etc/apt/sources.list.d/

Repozytoria powinny być zaufane i podpisane kluczem GPG. Dzięki temu system może sprawdzić, czy pobierane pakiety pochodzą z właściwego źródła i nie zostały zmodyfikowane.

Przykładowy wpis repozytorium może zawierać adres serwera, nazwę wydania systemu oraz sekcje pakietów. W Ubuntu często spotykamy sekcje takie jak main, universe, restricted i multiverse.

W nowoczesnych konfiguracjach APT coraz częściej stosuje się osobne pliki .sources oraz wskazanie konkretnego pliku klucza przez signed-by. To lepsza praktyka niż wrzucanie wszystkich kluczy do jednego globalnego miejsca.

Po zmianie repozytoriów należy wykonać:

sudo apt update

Jeżeli pojawiają się błędy, należy sprawdzić adres repozytorium, wersję dystrybucji, dostępność sieci, proxy oraz poprawność klucza podpisującego.

70. Jaka jest różnica między pakietami .deb i .rpm?

.deb oraz .rpm to formaty pakietów używane przez różne rodziny dystrybucji Linux.

Pakiety .deb są stosowane w systemach Debian, Ubuntu oraz ich pochodnych.

Pakiety .rpm są stosowane w systemach Red Hat, Fedora, Rocky Linux, AlmaLinux, SUSE i ich pochodnych.

Przykład instalacji lokalnego pakietu .deb:

sudo apt install ./pakiet.deb

Przykład instalacji lokalnego pakietu .rpm:

sudo dnf install ./pakiet.rpm

Nie powinno się mieszać formatów pakietów między dystrybucjami, ponieważ może to prowadzić do problemów z zależnościami i stabilnością systemu.

Sam format pakietu to jednak nie wszystko. Ważne jest również to, dla jakiej wersji dystrybucji został przygotowany pakiet, jakie ma zależności i czy jest zgodny z bibliotekami dostępnymi w systemie.

Czasem można spotkać narzędzia do konwersji pakietów, ale w środowiskach produkcyjnych lepiej korzystać z pakietów przygotowanych natywnie dla danej dystrybucji. Pozwala to uniknąć problemów podczas aktualizacji i ułatwia wsparcie techniczne.

71. Jak sprawdzić, do którego pakietu należy dany plik?

W systemach Debian/Ubuntu można użyć polecenia:

dpkg -S /ścieżka/do/pliku

Przykład:

dpkg -S /bin/ls

W systemach Red Hat/Rocky/Fedora można użyć:

rpm -qf /ścieżka/do/pliku

Przykład:

rpm -qf /usr/bin/ls

Jest to przydatne, gdy chcemy ustalić, który pakiet dostarczył konkretny plik binarny, bibliotekę lub plik konfiguracyjny.

Przykładowo, jeśli jakaś biblioteka została przypadkowo usunięta albo plik konfiguracyjny został zmodyfikowany, można szybko ustalić, z jakim pakietem jest związany. To pomaga w naprawie systemu, reinstalacji pakietu albo analizie zależności.

W systemach Debian/Ubuntu można ponownie zainstalować pakiet poleceniem:

sudo apt install --reinstall nazwa_pakietu

W systemach RPM przydatne są również polecenia weryfikujące integralność pakietów, np.:

rpm -V nazwa_pakietu

72. Co oznacza load average w systemie Linux?

Load average pokazuje średnie obciążenie systemu w czasie 1, 5 i 15 minut. Można je sprawdzić poleceniem:

uptime

Przykładowy wynik:

load average: 0.42, 0.55, 0.60

Interpretacja zależy od liczby rdzeni procesora. Dla maszyny z jednym rdzeniem wartość 1.00 oznacza pełne obciążenie. Dla maszyny z czterema rdzeniami wartość 4.00 może oznaczać, że system jest mocno zajęty, ale jeszcze niekoniecznie przeciążony.

Wysoki load average nie zawsze oznacza tylko problem z CPU. Może też wynikać z oczekiwania procesów na operacje dyskowe lub inne zasoby.

To ważna różnica. System może mieć wysoki load average, a jednocześnie CPU nie musi być użyty w 100%. Procesy mogą czekać na dysk, sieć, blokady aplikacji albo odpowiedź z innego zasobu.

Do dalszej diagnostyki można użyć:

top
vmstat 1
iostat -xz 1

top pokaże procesy i obciążenie CPU, vmstat da ogólny obraz systemu, a iostat pomoże wykryć problemy z dyskiem. Load average jest więc sygnałem ostrzegawczym, ale nie mówi samodzielnie, gdzie dokładnie znajduje się problem.

73. Co to jest proces zombie?

Proces zombie to proces, który zakończył swoje działanie, ale jego wpis nadal istnieje w tablicy procesów, ponieważ proces nadrzędny nie odebrał jeszcze informacji o jego zakończeniu.

Proces zombie zwykle nie zużywa CPU ani pamięci w typowy sposób, ale duża liczba takich procesów może świadczyć o problemie z aplikacją lub procesem nadrzędnym.

Procesy zombie można zauważyć np. w ps po stanie Z.

Przykład:

ps aux | grep Z

Jeżeli zombie pojawia się pojedynczo i znika, zwykle nie ma problemu. Jeżeli ich liczba rośnie, należy sprawdzić proces nadrzędny.

Aby ustalić proces nadrzędny, można użyć:

ps -eo pid,ppid,state,cmd | grep Z

Kolumna PPID pokaże identyfikator procesu rodzica. Często rozwiązaniem nie jest „zabicie” zombie, bo taki proces już się zakończył, ale restart lub naprawa procesu nadrzędnego, który nie odbiera statusu zakończenia procesów potomnych.

Duża liczba procesów zombie może w skrajnym przypadku zapełnić tablicę procesów i utrudnić uruchamianie nowych programów.

74. Do czego służą polecenia nice i renice?

nice i renice służą do zarządzania priorytetem procesów.

nice uruchamia proces z określonym priorytetem:

nice -n 10 polecenie

renice zmienia priorytet już działającego procesu:

renice 10 -p 1234

Wartość nice może zwykle mieścić się od -20 do 19. Niższa wartość oznacza wyższy priorytet, a wyższa wartość oznacza niższy priorytet.

Zwiększanie priorytetu procesu zwykle wymaga uprawnień administratora.

W praktyce nice przydaje się, gdy chcemy uruchomić zadanie obciążające CPU, ale nie chcemy, aby przeszkadzało ważniejszym procesom. Może to być kompresja dużego katalogu, indeksowanie plików, generowanie raportu albo zadanie backupowe.

Przykład:

nice -n 15 tar -czf backup.tar.gz /duzy_katalog

Taki proces będzie miał niższy priorytet niż zwykłe procesy. Nie oznacza to, że będzie działał bardzo wolno, ale scheduler jądra będzie traktował go jako mniej pilny.

W nowoczesnych systemach do kontroli zasobów coraz częściej używa się także cgroups i mechanizmów systemd, ale nice nadal pozostaje prostym i przydatnym narzędziem.

75. Jak sprawdzić, który proces zużywa najwięcej CPU lub pamięci?

Do bieżącego monitorowania procesów można użyć poleceń:

top

lub:

htop

Można też użyć polecenia ps i posortować wyniki.

Procesy zużywające najwięcej CPU:

ps aux --sort=-%cpu | head

Procesy zużywające najwięcej pamięci:

ps aux --sort=-%mem | head

W praktyce warto patrzeć nie tylko na chwilowe zużycie CPU, ale też na czas działania procesu, zużycie pamięci, liczbę wątków i logi aplikacji.

Czasem proces zużywa dużo CPU tylko przez chwilę, co może być normalne. Problem pojawia się wtedy, gdy wysokie użycie utrzymuje się długo, wpływa na inne usługi albo jest związane z błędem aplikacji.

Dodatkowe przydatne polecenia:

pidstat 1

pokazuje statystyki procesów w odstępach czasowych.

ps -T -p PID

pokazuje wątki konkretnego procesu.

Przy diagnostyce warto połączyć kilka źródeł informacji: obciążenie CPU, pamięć, I/O, logi aplikacji i logi systemowe. Samo top często pokazuje objaw, ale nie zawsze przyczynę.

76. Co oznaczają cache i buffers w pamięci RAM?

Linux wykorzystuje wolną pamięć RAM jako cache i buffers, aby przyspieszyć działanie systemu. Dzięki temu dane odczytywane z dysku mogą być przechowywane w pamięci i szybciej dostępne przy kolejnym użyciu.

Początkujący użytkownicy często myślą, że Linux „zjada całą pamięć”, ponieważ widzą duże użycie RAM. W rzeczywistości pamięć przeznaczona na cache może zostać zwolniona, gdy aplikacje będą jej potrzebowały.

Sprawdzenie pamięci:

free -h

Najważniejsza kolumna to zwykle available, ponieważ pokazuje, ile pamięci system może realnie udostępnić aplikacjom bez intensywnego używania przestrzeni wymiany.

Przykładowo, system może pokazywać mało pamięci „free”, ale dużo pamięci „available”. W takim przypadku nie musi to oznaczać problemu. Linux po prostu efektywnie wykorzystuje RAM.

Warto natomiast zwrócić uwagę na intensywne użycie swapu, spadającą wartość available, błędy OOM killer albo komunikaty o braku pamięci w logach.

Sprawdzenie komunikatów OOM:

journalctl -k | grep -i oom

lub:

dmesg | grep -i oom

To może pomóc wykryć, czy system zabija procesy z powodu braku pamięci.

77. Do czego służy polecenie dmesg?

dmesg wyświetla komunikaty bufora jądra systemu Linux. Są tam informacje dotyczące startu systemu, wykrytego sprzętu, sterowników, błędów dysków, problemów z USB, kartami sieciowymi i innymi urządzeniami.

Przykład:

dmesg

Wyświetlenie ostatnich komunikatów:

dmesg | tail

Podgląd komunikatów na żywo:

dmesg -w

dmesg jest szczególnie przydatny po podłączeniu nowego urządzenia, awarii dysku, problemach ze sterownikiem lub podczas diagnostyki startu systemu.

Przykładowo, po podłączeniu pendrive'a można uruchomić:

dmesg -w

Następnie system pokaże, jak wykrył urządzenie i pod jaką nazwą zostało udostępnione, np. /dev/sdb.

W przypadku problemów sprzętowych warto szukać słów takich jak:

error
failed
timeout
I/O error

Dmesg pokazuje komunikaty z poziomu jądra, dlatego jest szczególnie cenny wtedy, gdy problem dotyczy sprzętu, sterowników, dysków, USB, sieci albo pamięci.

78. Czym są katalogi /proc i /sys?

/proc i /sys to specjalne wirtualne systemy plików. Nie są zwykłymi katalogami z danymi zapisanymi na dysku, ale interfejsami do informacji udostępnianych przez jądro systemu.

/proc zawiera informacje o procesach i stanie systemu, np.:

/proc/cpuinfo
/proc/meminfo
/proc/uptime

/sys zawiera informacje o urządzeniach, sterownikach, magistralach i parametrach jądra.

Dzięki tym katalogom wiele narzędzi systemowych może odczytywać informacje o sprzęcie i działaniu systemu bezpośrednio z interfejsów jądra.

Przykład:

cat /proc/cpuinfo
cat /proc/meminfo

Pierwsze polecenie pokazuje informacje o procesorze, drugie o pamięci systemowej.

W katalogu /proc każdy działający proces ma swój katalog nazwany numerem PID. Na przykład:

/proc/1234/

Można tam znaleźć informacje o otwartych plikach, zmiennych środowiskowych, używanej pamięci i parametrach uruchomienia procesu.

Niektóre pliki w /proc i /sys pozwalają nie tylko czytać informacje, ale także zmieniać parametry działania jądra. Dlatego należy zachować ostrożność, szczególnie przy poleceniach zapisujących dane do tych lokalizacji.

79. Do czego służy plik /etc/fstab?

/etc/fstab definiuje systemy plików, które mają być montowane podczas startu systemu lub po wydaniu polecenia mount -a.

Przykładowy wpis:

UUID=xxxx-xxxx /data ext4 defaults 0 2

Typowe pola w /etc/fstab określają:

• urządzenie lub UUID,

• punkt montowania,

• typ systemu plików,

• opcje montowania,

• ustawienia dump,

• kolejność sprawdzania systemu plików.

Po zmianie pliku warto przetestować konfigurację:

sudo mount -a

Błędny wpis w /etc/fstab może spowodować problemy podczas startu systemu, dlatego należy zachować ostrożność.

Zamiast nazw typu /dev/sdb1 często lepiej używać UUID, ponieważ nazwy urządzeń mogą zmieniać się po restarcie, podłączeniu nowych dysków albo zmianie kolejności wykrywania sprzętu.

Sprawdzenie UUID:

blkid

W środowiskach zdalnych szczególnie ważne jest testowanie zmian przed restartem. Błąd w /etc/fstab może spowodować, że serwer uruchomi się w trybie awaryjnym i będzie wymagał dostępu przez konsolę.

80. Jaka jest różnica między mount a umount?

mount służy do podłączania systemu plików do wskazanego katalogu, czyli punktu montowania.

Przykład:

mount /dev/sdb1 /mnt/dysk

umount odłącza wcześniej zamontowany system plików.

Przykład:

umount /mnt/dysk

Jeżeli system zgłasza, że zasób jest zajęty, oznacza to zwykle, że jakiś proces korzysta jeszcze z pliku lub katalogu w tym punkcie montowania.

W takiej sytuacji można sprawdzić procesy poleceniem:

fuser -vm /mnt/dysk

Można również użyć:

lsof +f -- /mnt/dysk

Pokazuje to procesy korzystające z danego punktu montowania. Częstą przyczyną problemu jest otwarty terminal, którego bieżący katalog znajduje się na odmontowywanym dysku.

Przed odłączeniem dysku warto upewnić się, że wszystkie dane zostały zapisane. W przypadku nośników zewnętrznych można wykonać:

sync

Polecenie wymusza zapis buforowanych danych na dysk.

81. Co to jest LVM?

LVM, czyli Logical Volume Manager, umożliwia elastyczne zarządzanie przestrzenią dyskową. Zamiast pracować wyłącznie na fizycznych partycjach, administrator tworzy woluminy logiczne, które można łatwiej rozszerzać, zmniejszać lub przenosić.

Podstawowe elementy LVM:

• PV — Physical Volume, czyli fizyczny nośnik lub partycja,

• VG — Volume Group, czyli grupa woluminów,

• LV — Logical Volume, czyli wolumin logiczny używany przez system plików.

Przykładowe polecenia:

pvs
vgs
lvs

LVM jest szczególnie przydatny na serwerach, gdzie przestrzeń dyskowa może zmieniać się w czasie.

Przykładowo, jeżeli katalog /var zaczyna się zapełniać, a system używa LVM, administrator może rozszerzyć odpowiedni wolumin logiczny, o ile w grupie woluminów jest dostępne wolne miejsce.

Typowy proces rozszerzenia może wyglądać tak:

lvextend -r -L +10G /dev/vg0/var

Opcja -r próbuje automatycznie rozszerzyć również system plików. Bez niej trzeba byłoby wykonać dodatkowe polecenie zależne od typu systemu plików.

LVM oferuje także snapshoty, ale nie należy mylić ich z pełnym backupem. Snapshot pomaga zachować chwilowy stan woluminu, lecz zwykle znajduje się na tym samym systemie storage i nie chroni przed wszystkimi typami awarii.

82. Co to jest RAID?

RAID to technologia łączenia wielu dysków w jedną logiczną całość w celu zwiększenia wydajności, odporności na awarię lub obu tych cech jednocześnie.

Przykładowe poziomy RAID:

• RAID 0 — striping, zwiększa wydajność, ale nie daje redundancji,

• RAID 1 — mirror, dane są kopiowane na drugi dysk,

• RAID 5 — dane i parzystość rozłożone na kilku dyskach,

• RAID 6 — podobny do RAID 5, ale odporny na awarię dwóch dysków,

• RAID 10 — połączenie mirroringu i stripingu.

RAID nie zastępuje backupu. Chroni przed wybranymi awariami dysków, ale nie chroni przed przypadkowym usunięciem danych, ransomware, błędem administratora lub uszkodzeniem logicznym danych.

W Linuxie można spotkać zarówno sprzętowe kontrolery RAID, jak i programowy RAID oparty o mdadm.

Sprawdzenie stanu programowego RAID:

cat /proc/mdstat

Szczegółowe informacje o macierzy:

mdadm --detail /dev/md0

W praktyce sama obecność RAID nie wystarczy. Trzeba jeszcze monitorować stan dysków i macierzy, ponieważ niezauważona awaria jednego dysku może doprowadzić do utraty danych przy kolejnej awarii.

83. Jaka jest różnica między ext4, XFS i Btrfs?

Ext4, XFS i Btrfs to popularne systemy plików używane w Linuxie.

Ext4 jest bardzo popularny, stabilny i uniwersalny. Często wybierany jest dla systemów desktopowych i serwerów.

XFS dobrze sprawdza się przy dużych plikach, dużych woluminach i obciążeniach serwerowych. Jest często używany w środowiskach enterprise.

Btrfs oferuje nowoczesne funkcje, takie jak snapshoty, checksumming, kompresja i obsługa wielu urządzeń. Jest ciekawym wyborem tam, gdzie ważne są snapshoty i elastyczne zarządzanie danymi.

Wybór systemu plików zależy od zastosowania, dystrybucji, wymagań wydajnościowych i sposobu administracji.

Ext4 jest dobrym wyborem, gdy zależy nam na prostocie i przewidywalności. XFS często sprawdza się w dużych środowiskach serwerowych, ale np. zmniejszanie systemu plików XFS nie jest tak proste jak w przypadku niektórych innych rozwiązań. Btrfs daje ciekawe możliwości, ale wymaga zrozumienia jego mechanizmów, szczególnie w kontekście snapshotów, subvolumenów i zarządzania przestrzenią.

Przy wyborze systemu plików warto brać pod uwagę nie tylko funkcje, ale także doświadczenie zespołu, narzędzia backupowe, monitoring, wymagania aplikacji i wsparcie danej dystrybucji.

84. Do czego służy fsck?

fsck służy do sprawdzania i naprawy systemu plików.

Przykład:

fsck /dev/sdb1

Nie powinno się uruchamiać fsck na zamontowanym systemie plików, ponieważ może to doprowadzić do uszkodzenia danych. Najbezpieczniej wykonywać takie operacje na odmontowanym systemie plików albo z trybu ratunkowego.

W wielu przypadkach system sam uruchamia sprawdzanie systemu plików podczas startu, jeżeli wykryje nieprawidłowe zamknięcie lub błędy.

Przed użyciem fsck należy upewnić się, że wskazujemy właściwe urządzenie. Można to sprawdzić poleceniami:

lsblk
blkid

Dla systemów plików ext stosuje się narzędzia takie jak e2fsck. Dla XFS używa się xfs_repair, a nie klasycznego fsck w tym samym sensie. Dlatego zawsze warto wiedzieć, z jakim systemem plików pracujemy.

Naprawa systemu plików to operacja potencjalnie ryzykowna. Jeśli dane są ważne, najpierw należy zabezpieczyć kopię albo skonsultować dalsze działania.

85. Co dzieje się podczas startu systemu Linux?

Proces startu systemu Linux składa się z kilku etapów.

W uproszczeniu wygląda to tak:

1. Firmware komputera, czyli BIOS lub UEFI, inicjuje sprzęt.

2. Uruchamiany jest bootloader.

3. Bootloader ładuje jądro Linux i initramfs.

4. Jądro inicjuje sprzęt i podstawowe sterowniki.

5. Uruchamiany jest proces init, najczęściej systemd.

6. Systemd startuje usługi, montuje systemy plików i doprowadza system do odpowiedniego targetu.

7. Użytkownik może zalogować się lokalnie, zdalnie lub przez interfejs graficzny.

Znajomość tego procesu pomaga diagnozować problemy z uruchamianiem systemu.

Jeżeli system zatrzymuje się bardzo wcześnie, problem może dotyczyć firmware, bootloadera, jądra albo initramfs. Jeżeli system startuje, ale nie działają usługi, bardziej prawdopodobny jest problem z systemd, konfiguracją usług, montowaniem dysków lub siecią.

Przydatne polecenia diagnostyczne:

systemd-analyze
systemd-analyze blame
journalctl -b

Pierwsze pokazuje ogólny czas startu systemu, drugie usługi, które uruchamiały się najdłużej, a trzecie logi z bieżącego uruchomienia.

To pozwala szybciej ustalić, czy problem dotyczy opóźnionej usługi, błędnego montowania dysku, konfiguracji sieci czy innego elementu startu systemu.

86. Co to jest tryb rescue lub emergency mode?

Tryb rescue lub emergency mode służy do naprawy systemu, który nie uruchamia się poprawnie albo wymaga interwencji administratora.

Rescue mode zwykle uruchamia minimalne środowisko z podstawowymi usługami i możliwością naprawy systemu.

Emergency mode jest jeszcze bardziej ograniczony i najczęściej daje dostęp do podstawowej powłoki administracyjnej.

Tryby te przydają się m.in. przy:

• błędach w /etc/fstab,

• uszkodzonych systemach plików,

• problemach z hasłem root,

• błędnej konfiguracji usług,

• awarii procesu startu systemu.

W systemach z systemd można przełączyć system do trybu rescue poleceniem:

systemctl rescue

lub do trybu emergency:

systemctl emergency

W praktyce częściej trafiamy do tych trybów automatycznie, gdy system nie może poprawnie wystartować. Przykładowo błędny wpis w /etc/fstab może spowodować zatrzymanie startu i konieczność ręcznej naprawy.

W trybie ratunkowym warto zachować szczególną ostrożność, ponieważ często pracujemy z uprawnieniami administratora i na krytycznych plikach systemowych.

87. Jak działa uwierzytelnianie SSH kluczem publicznym?

Uwierzytelnianie SSH kluczem publicznym polega na użyciu pary kluczy: prywatnego i publicznego.

Klucz prywatny zostaje na komputerze użytkownika i nie powinien być nikomu udostępniany. Klucz publiczny umieszcza się na serwerze w pliku:

~/.ssh/authorized_keys

Podczas logowania serwer sprawdza, czy użytkownik posiada pasujący klucz prywatny. Jeżeli tak, logowanie może odbyć się bez wpisywania hasła użytkownika systemowego.

Wygenerowanie klucza:

ssh-keygen

Skopiowanie klucza na serwer:

ssh-copy-id user@server

Logowanie kluczem jest wygodne i bezpieczne, szczególnie gdy klucz prywatny jest zabezpieczony hasłem.

Współcześnie warto używać silnych typów kluczy, np. Ed25519:

ssh-keygen -t ed25519

Ważne są również uprawnienia plików. Katalog .ssh i pliki kluczy nie powinny być dostępne dla wszystkich użytkowników.

Przykładowe ustawienia:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519

Jeżeli uprawnienia są zbyt szerokie, SSH może odmówić użycia klucza ze względów bezpieczeństwa.

88. Do czego służy plik ~/.ssh/config?

Plik ~/.ssh/config pozwala zapisać konfigurację połączeń SSH, dzięki czemu nie trzeba za każdym razem wpisywać pełnych parametrów połączenia.

Przykład:

Host serwer-testowy
    HostName 192.168.1.50
    User admin
    Port 22
    IdentityFile ~/.ssh/id_rsa

Po zapisaniu takiej konfiguracji można połączyć się krótszym poleceniem:

ssh serwer-testowy

Plik ten jest bardzo wygodny, gdy administrator pracuje z wieloma serwerami, różnymi użytkownikami, portami lub kluczami SSH.

Można w nim także definiować połączenia przez bastion host, czyli serwer pośredniczący:

Host serwer-wewnetrzny
    HostName 10.0.0.50
    User admin
    ProxyJump bastion

Dzięki temu codzienna praca z wieloma środowiskami staje się prostsza i mniej podatna na pomyłki.

Warto pamiętać o uprawnieniach pliku:

chmod 600 ~/.ssh/config

Zbyt szerokie uprawnienia mogą powodować ostrzeżenia albo problemy z użyciem konfiguracji.

89. Jak ograniczyć możliwość logowania root przez SSH?

Możliwość logowania root przez SSH konfiguruje się zwykle w pliku:

/etc/ssh/sshd_config

Najważniejszy parametr to:

PermitRootLogin no

Po zmianie konfiguracji należy przeładować lub zrestartować usługę SSH:

systemctl reload ssh

lub:

systemctl reload sshd

Zablokowanie bezpośredniego logowania root przez SSH zwiększa bezpieczeństwo, ponieważ administratorzy logują się na zwykłe konta, a dopiero potem używają sudo do wykonania zadań administracyjnych.

Przed zmianą warto upewnić się, że istnieje inne konto z dostępem administracyjnym. W przeciwnym razie można przypadkowo odciąć sobie dostęp do serwera.

Dodatkowe dobre praktyki SSH:

PasswordAuthentication no
PubkeyAuthentication yes
PermitEmptyPasswords no

Włączenie logowania wyłącznie kluczem publicznym może znacząco ograniczyć ryzyko ataków brute force. Trzeba jednak wcześniej upewnić się, że klucze zostały poprawnie skonfigurowane.

Przed zamknięciem aktywnej sesji SSH warto otworzyć drugą sesję testową i sprawdzić, czy nowe ustawienia działają.

90. Co to jest firewall w systemie Linux?

Firewall służy do filtrowania ruchu sieciowego. Pozwala określić, które połączenia są dozwolone, a które mają zostać zablokowane.

W Linuxie można spotkać różne narzędzia do zarządzania firewallem:

• iptables — starsze, bardzo popularne narzędzie,

• nftables — nowszy framework filtrowania pakietów,

• ufw — uproszczony firewall często używany w Ubuntu,

• firewalld — dynamiczny menedżer firewalla popularny w systemach Red Hat/Fedora.

Przykład dla UFW:

sudo ufw allow 22/tcp
sudo ufw enable

Przykład dla firewalld:

firewall-cmd --add-service=ssh --permanent
firewall-cmd --reload

Firewall powinien być konfigurowany zgodnie z zasadą minimalnych wymaganych dostępów.

Oznacza to, że otwieramy tylko te porty, które są naprawdę potrzebne. Jeżeli serwer ma udostępniać wyłącznie SSH i HTTPS, nie ma powodu, aby wystawiać inne usługi na zewnątrz.

Sprawdzenie statusu UFW:

sudo ufw status verbose

Sprawdzenie aktywnych stref firewalld:

firewall-cmd --get-active-zones

Przy pracy zdalnej należy szczególnie uważać, aby nie zablokować własnego połączenia SSH. Najpierw warto jawnie dopuścić port SSH, a dopiero później włączać lub zaostrzać reguły firewalla.

91. Co to jest Netplan?

Netplan jest narzędziem do konfiguracji sieci stosowanym w wielu współczesnych systemach Ubuntu. Konfiguracja zapisywana jest w plikach YAML, zwykle w katalogu:

/etc/netplan/

Przykładowe zastosowania Netplan:

• konfiguracja adresu IP,

• ustawienie bramy domyślnej,

• konfiguracja DNS,

• konfiguracja interfejsów przewodowych i bezprzewodowych,

• konfiguracja VLAN lub bondingu.

Po zmianie konfiguracji można ją zastosować poleceniem:

sudo netplan apply

Przed zmianami warto zachować kopię działającej konfiguracji, szczególnie na serwerach zdalnych.

Bardzo przydatne jest polecenie:

sudo netplan try

Pozwala ono przetestować konfigurację i automatycznie ją wycofać, jeśli administrator nie potwierdzi zmian. To ważne przy pracy przez SSH, ponieważ błędna konfiguracja sieci może odciąć dostęp do serwera.

Pliki Netplan używają formatu YAML, w którym wcięcia mają znaczenie. Błąd w liczbie spacji może spowodować, że konfiguracja nie zostanie poprawnie wczytana.

92. Jak sprawdzić konfigurację DNS w systemie Linux?

Konfiguracja DNS zależy od dystrybucji i używanych narzędzi. W wielu systemach można zacząć od sprawdzenia pliku:

/etc/resolv.conf

W systemach z systemd-resolved przydatne jest polecenie:

resolvectl status

Test zapytania DNS można wykonać poleceniem:

dig example.com

lub:

nslookup example.com

Problemy z DNS często objawiają się tym, że działa połączenie po adresie IP, ale nie działa po nazwie domenowej.

Przykładowo, jeżeli działa:

ping 8.8.8.8

ale nie działa:

ping example.com

można podejrzewać problem z DNS.

Warto też sprawdzić lokalne rozwiązywanie nazw:

getent hosts example.com

Polecenie getent korzysta z systemowego mechanizmu rozwiązywania nazw, a więc uwzględnia konfigurację /etc/nsswitch.conf, /etc/hosts, DNS i inne źródła nazw. Czasem daje bardziej realistyczny obraz niż samo dig.

93. Do czego służą hostnamectl, timedatectl i localectl?

Są to narzędzia systemd służące do zarządzania podstawową konfiguracją systemu.

hostnamectl służy do sprawdzania i ustawiania nazwy hosta:

hostnamectl
hostnamectl set-hostname server01

timedatectl służy do sprawdzania i ustawiania czasu, strefy czasowej oraz synchronizacji NTP:

timedatectl

localectl służy do zarządzania ustawieniami regionalnymi i układem klawiatury:

localectl

Polecenia te są przydatne po świeżej instalacji systemu lub podczas standaryzacji konfiguracji serwerów.

Przykład ustawienia strefy czasowej:

timedatectl set-timezone Europe/Warsaw

Sprawdzenie dostępnych stref:

timedatectl list-timezones

Poprawny czas w systemie jest ważny nie tylko dla wygody. Ma znaczenie dla logów, certyfikatów TLS, Kerberos, synchronizacji danych, systemów monitoringu i analizy incydentów bezpieczeństwa.

Jeżeli czas na serwerze jest błędny, logi mogą prowadzić do fałszywych wniosków, a niektóre usługi mogą przestać działać poprawnie.

94. Co to jest kontener w systemie Linux?

Kontener to odizolowane środowisko uruchamiania aplikacji, które korzysta z jądra systemu gospodarza, ale posiada własną przestrzeń procesów, sieci, systemu plików i zależności.

Kontenery są lżejsze od maszyn wirtualnych, ponieważ nie uruchamiają osobnego jądra systemu operacyjnego.

Popularne narzędzia związane z kontenerami:

• Docker,

• Podman,

• containerd,

• LXC.

Kontenery ułatwiają uruchamianie aplikacji w powtarzalnym środowisku, niezależnym od konfiguracji konkretnego serwera.

Przykładowo aplikacja może działać w kontenerze z konkretną wersją Pythona, Node.js albo Javy, bez konieczności instalowania tych wersji bezpośrednio w systemie gospodarza. Dzięki temu łatwiej utrzymać spójność między środowiskiem developerskim, testowym i produkcyjnym.

Kontener zwykle powstaje z obrazu. Obraz zawiera aplikację, biblioteki, zależności i konfigurację potrzebną do uruchomienia. Uruchomiona instancja obrazu to kontener.

Trzeba jednak pamiętać, że kontenery nie są magiczną warstwą bezpieczeństwa. Źle skonfigurowany kontener, uruchomiony z nadmiernymi uprawnieniami, może stanowić poważne ryzyko.

95. Jaka jest różnica między kontenerem a maszyną wirtualną?

Maszyna wirtualna emuluje cały komputer wraz z własnym systemem operacyjnym i jądrem. Wymaga hypervisora, takiego jak KVM, VMware, Hyper-V lub VirtualBox.

Kontener korzysta z jądra systemu gospodarza i izoluje tylko wybrane elementy środowiska, takie jak procesy, sieć, użytkownicy czy system plików.

W uproszczeniu:

• maszyna wirtualna jest cięższa, ale daje mocniejszą izolację systemową,

• kontener jest lżejszy i szybszy w uruchamianiu,

• kontenery dobrze sprawdzają się przy aplikacjach mikroserwisowych,

• maszyny wirtualne lepiej sprawdzają się, gdy trzeba uruchomić różne systemy operacyjne lub mocno odseparować środowiska.

Przykładowo, jeśli chcemy uruchomić Windows na hoście Linux, potrzebujemy maszyny wirtualnej. Jeśli chcemy uruchomić aplikację webową z własnym zestawem zależności, kontener często będzie wygodniejszy.

Maszyny wirtualne mają własne jądro, własny system operacyjny i zwykle większy narzut zasobów. Kontenery startują szybciej i zużywają mniej zasobów, ale współdzielą jądro z hostem.

W środowiskach produkcyjnych oba podejścia często się uzupełniają. Na maszynach wirtualnych uruchamia się klastry kontenerowe, a wewnątrz nich aplikacje w kontenerach.

96. Co to są namespaces i cgroups?

Namespaces i cgroups to mechanizmy jądra Linux, które są podstawą działania kontenerów.

Namespaces zapewniają izolację. Dzięki nim proces może widzieć własną listę procesów, własną sieć, własne punkty montowania lub własną nazwę hosta.

Cgroups, czyli control groups, służą do ograniczania i kontrolowania zasobów używanych przez procesy. Można za ich pomocą ograniczyć CPU, pamięć RAM, operacje wejścia/wyjścia lub liczbę procesów.

W skrócie:

• namespaces odpowiadają za to, co proces widzi,

• cgroups odpowiadają za to, ile zasobów proces może użyć.

Przykładowe typy namespaces to:

• PID namespace — izolacja procesów,

• network namespace — izolacja sieci,

• mount namespace — izolacja punktów montowania,

• user namespace — izolacja użytkowników,

• UTS namespace — izolacja nazwy hosta.

Dzięki tym mechanizmom proces w kontenerze może „myśleć”, że działa jako proces numer 1 w swoim systemie, widzieć własny interfejs sieciowy i własny system plików, mimo że fizycznie działa na wspólnym jądrze hosta.

Cgroups są bardzo ważne dla stabilności. Bez limitów jeden proces lub kontener mógłby zużyć całą pamięć albo CPU hosta i zakłócić działanie innych usług.

97. Co to jest SELinux?

SELinux, czyli Security-Enhanced Linux, jest mechanizmem bezpieczeństwa typu Mandatory Access Control. Oznacza to, że oprócz klasycznych uprawnień plików system stosuje dodatkowe polityki bezpieczeństwa.

SELinux może ograniczyć działanie procesu nawet wtedy, gdy klasyczne uprawnienia plików pozwalałyby na dostęp.

Podstawowe tryby SELinux:

• Enforcing — polityki są aktywnie egzekwowane,

• Permissive — naruszenia są logowane, ale nie blokowane,

• Disabled — SELinux jest wyłączony.

Sprawdzenie statusu:

getenforce

SELinux bywa trudny na początku, ale w środowiskach serwerowych znacząco podnosi poziom bezpieczeństwa.

Dobry przykład: serwer WWW może mieć klasyczne uprawnienia do odczytu pliku, ale SELinux może nadal zablokować dostęp, jeśli plik ma niewłaściwy kontekst bezpieczeństwa.

Sprawdzenie kontekstu:

ls -Z

Przywrócenie domyślnych kontekstów:

restorecon -Rv /var/www/html

Wielu początkujących administratorów wyłącza SELinux przy pierwszym problemie. Lepszym podejściem jest sprawdzenie logów, zrozumienie blokady i poprawienie kontekstu lub polityki.

98. Co to jest AppArmor?

AppArmor jest mechanizmem bezpieczeństwa, który ogranicza możliwości działania aplikacji na podstawie profili. Profile określają, do jakich plików i zasobów dana aplikacja może mieć dostęp.

AppArmor jest często spotykany w systemach Ubuntu i Debian.

Sprawdzenie statusu:

aa-status

W przeciwieństwie do klasycznych uprawnień plików AppArmor skupia się na ograniczaniu konkretnych programów. Dzięki temu nawet w przypadku błędu aplikacji można zmniejszyć zakres potencjalnych szkód.

Profile AppArmor mogą działać w trybie egzekwowania albo w trybie obserwacji. W trybie complain naruszenia są logowane, ale nie blokowane. Jest to przydatne podczas tworzenia lub testowania profilu.

Przykładowe polecenia:

aa-complain /etc/apparmor.d/profil
aa-enforce /etc/apparmor.d/profil

AppArmor, podobnie jak SELinux, bywa niewidoczny dla użytkownika aż do momentu, gdy coś zostanie zablokowane. Dlatego przy problemach z dostępem aplikacji do plików warto sprawdzić nie tylko uprawnienia klasyczne, ale również mechanizmy MAC.

99. Do czego służy strace?

strace służy do śledzenia wywołań systemowych wykonywanych przez proces. Jest bardzo przydatny podczas diagnostyki problemów, gdy aplikacja nie startuje, nie może otworzyć pliku, nie znajduje biblioteki lub kończy się błędem bez czytelnego komunikatu.

Przykład uruchomienia programu przez strace:

strace ./program

Podpięcie się do działającego procesu:

strace -p 1234

Zapis wyniku do pliku:

strace -o wynik.txt ./program

strace pozwala zobaczyć, co program próbuje zrobić na poziomie systemu operacyjnego.

Jednym z najczęstszych zastosowań jest szukanie brakujących plików lub problemów z uprawnieniami. Można filtrować wybrane wywołania systemowe:

strace -e openat ./program

Jeżeli aplikacja zgłasza ogólny błąd, a w logach nie ma nic konkretnego, strace może pokazać, że program próbuje otworzyć plik, którego nie ma, albo nie ma do niego dostępu.

Trzeba pamiętać, że wynik strace może być bardzo obszerny. Dlatego w praktyce często zapisuje się go do pliku i analizuje przez grep, szukając słów takich jak ENOENT, EACCES albo EPERM.

100. Do czego służy logrotate?

logrotate służy do automatycznej rotacji logów. Dzięki niemu pliki logów nie rosną bez końca i nie zapełniają dysku.

Logrotate może:

• przenosić stare logi do plików archiwalnych,

• kompresować stare logi,

• usuwać logi starsze niż określony czas,

• tworzyć nowe puste pliki logów,

• wykonać polecenie po rotacji logu.

Główna konfiguracja znajduje się zwykle w pliku:

/etc/logrotate.conf

Dodatkowe konfiguracje usług znajdują się często w katalogu:

/etc/logrotate.d/

Logrotate jest prostym, ale bardzo ważnym narzędziem administracyjnym. Bez rotacji logów nawet poprawnie działająca aplikacja może z czasem doprowadzić do zapełnienia dysku.

Przykładowa konfiguracja może określać, że log ma być rotowany codziennie, przechowywany przez 14 dni, kompresowany i tworzony od nowa po rotacji.

Przetestowanie konfiguracji bez realnych zmian:

logrotate -d /etc/logrotate.conf

Wymuszenie rotacji:

logrotate -f /etc/logrotate.conf

Przy usługach, które stale zapisują do pliku logu, po rotacji często trzeba wysłać sygnał do procesu albo wykonać reload usługi. W przeciwnym razie aplikacja może nadal pisać do starego, przeniesionego pliku.

Podsumowanie

To już kolejne 50 pytań i odpowiedzi dotyczących systemu Linux. Pierwsza część skupiała się na podstawach, klasycznych pojęciach i często spotykanych pytaniach z rozmów kwalifikacyjnych. Druga część rozwija temat w stronę codziennej administracji, diagnostyki, zarządzania usługami, użytkownikami, pakietami, dyskami, siecią, SSH, kontenerami oraz bezpieczeństwem.

W tej części pojawiło się więcej zagadnień praktycznych. To właśnie one bardzo często decydują o tym, czy ktoś tylko zna pojedyncze komendy, czy naprawdę rozumie, jak działa system. Umiejętność sprawdzenia logów, zrozumienia statusu usługi, przeanalizowania obciążenia, poprawienia konfiguracji sieci albo bezpiecznego zarządzania dostępem jest w codziennej pracy równie ważna jak znajomość podstawowych poleceń.

Linux jest ogromnym ekosystemem i nie da się poznać go w jeden wieczór. Można jednak budować wiedzę krok po kroku: od podstawowych poleceń, przez rozumienie usług i logów, aż po bardziej zaawansowane zagadnienia związane z automatyzacją, bezpieczeństwem i konteneryzacją.

Najlepszym sposobem nauki pozostaje praktyka. Warto postawić własną maszynę wirtualną, środowisko WSL, mały serwer testowy albo laboratorium kontenerowe i samodzielnie sprawdzać opisane polecenia. Linux najlepiej zapamiętuje się nie z samego czytania, ale z rozwiązywania prawdziwych problemów: usługa nie startuje, dysk się zapełnia, DNS nie działa, uprawnienia blokują dostęp, logi rosną bez końca albo aplikacja zachowuje się inaczej niż powinna.

Jeżeli nie czytałeś pierwszej części, znajdziesz ją tutaj:

https://margib.blogspot.com/2018/10/50-popularnych-pytan-dotyczacych.html