Komendy Linux do pracy administratora serwera

Komendy Linux dobieraj do zadania, nie z alfabetycznej listy. Pracuj w trzech krokach - odczytaj stan serwera, wykonaj jedną świadomą zmianę, sprawdź wynik osobnym poleceniem. Ta strona jest mapą tych kroków: od plików, procesów i sieci po pełne instrukcje rsync, wget, chmod i openssl s_client.

Pełne procedury znajdziesz w tekstach o synchronizacji plików przez rsync, pobieraniu plików przez wget, zmianie uprawnień przez chmod, diagnostyce TLS przez openssl s_client, sprawdzaniu osiągalności hosta przez ping, odpytywaniu serwera DNS przez nslookup i zdalnym dostępie do serwera przez SSH. Tutaj wybierasz zadanie, pierwsze polecenie i sposób sprawdzenia wyniku.

Zanim wpiszesz pierwszą komendę

Ustal, gdzie właściwie wpisujesz polecenie. Terminal na laptopie, sesja SSH na serwerze i konsola kontenera wyglądają identycznie - a odpowiadają na pytania o trzy różne maszyny.

Administrator dostaje alert o kończącym się miejscu na dysku serwera. Otwiera pierwsze okno terminala pod ręką, wpisuje df -h, widzi mnóstwo wolnego miejsca i zamyka alert jako fałszywy. Okno pokazywało jednak dysk jego laptopa, nie serwera. Niedługo potem baza danych na serwerze przestaje zapisywać cokolwiek. Polecenie było dobre - złe było miejsce jego wykonania. To fikcyjna scena, ale każdy element tej pomyłki zdarza się naprawdę.

Przed taką pomyłką chronią trzy nawyki:

1. Nazwij hosta i warstwę, zanim zinterpretujesz wynik - sprawdź, do której maszyny należy okno, w które patrzysz.
2. Zmieniaj jedną rzecz naraz, z jawnym źródłem i celem w treści polecenia.
3. Wynik sprawdzaj osobnym poleceniem, dobranym do skutku, który miał powstać.

W przykładach zobaczysz zapisy w rodzaju NAZWA_USLUGI, WZORZEC albo /sciezka/do/katalogu. To miejsca do zastąpienia wartościami z twojego środowiska, nie gotowe fragmenty do wklejenia.

Które polecenie do którego zadania?

Tabela prowadzi w kolejności pracy administratora - od orientacji, przez pliki, dysk i procesy, po sieć i transfer. Każdy wiersz rozdziela odczyt od zmiany, bo to dwie różne decyzje.

Tabela nie jest kursem powłoki. Wiersz kończy się tam, gdzie zaczyna się pełna instrukcja albo dokumentacja programu - opcji spoza dokumentacji nie dopisujemy dla wygody przykładu.

Jak poruszać się po plikach i katalogach?

pwd mówi, gdzie jesteś - wypisuje bezwzględną ścieżkę bieżącego katalogu. ls pokazuje, co leży we wskazanym katalogu, bez schodzenia w podkatalogi. Te dwa odczyty ustaw przed każdą operacją na ścieżkach, bo względna ścieżka znaczy co innego w każdym katalogu.

Do szukania służą dwa różne narzędzia. find przeszukuje drzewo katalogów i odpowiada na pytanie, gdzie leży plik o danej nazwie. grep przeszukuje zawartość i odpowiada na pytanie, która linia pasuje do wzorca. Gdy nie wiesz, w którym pliku szukać tekstu, złóż oba - najpierw find zawęża listę, potem grep czyta treść.

Zmiany wykonują cp, mv i rm. cp kopiuje, mv przenosi albo zmienia nazwę, rm usuwa. Zanim naciśniesz Enter po rm, odczytaj dokładną ścieżkę poleceniem ls - usunięty plik nie trafia do żadnego kosza i system nie przechowa go dla ciebie. Brak komunikatu po operacji potwierdza tylko tę jedną operację, nie stan reszty plików.

Jak sprawdzić miejsce na dysku?

df -h raportuje zajętość całych systemów plików w jednostkach czytelnych dla człowieka. du -sh /sciezka/do/katalogu sumuje rozmiar jednego drzewa katalogów. Pierwsze polecenie odpowiada na pytanie, który dysk się zapełnia - drugie, co go zapełnia.

Czytaj wynik dla właściwego punktu montowania. Jeden zapełniony wpis w df -h nie mówi nic o pozostałych, a wynik du dla katalogu nie zastępuje raportu o całym systemie plików.

Jak sprawdzić procesy, usługi i logi?

ps pokazuje migawkę procesów widocznych w miejscu wykonania. systemctl status NAZWA_USLUGI pokazuje stan wskazanej jednostki systemd razem z ostatnimi wpisami jej dziennika. journalctl -u NAZWA_USLUGI --since 'MOMENT_PRZED_OBJAWEM' filtruje dziennik po jednostce i po czasie - moment startu dobierz do chwili sprzed objawu, nie do okrągłej liczby linii.

To trzy odpowiedzi na trzy różne pytania: co działa w tej chwili, co systemd wie o usłudze i co wydarzyło się wcześniej. Zapisz nazwę usługi, miejsce wykonania i objaw, zanim zestawisz te odpowiedzi w diagnozę.

Jak sprawdzić, czy port nasłuchuje?

ss -ltnp wypisuje nasłuchujące gniazda TCP w przestrzeni sieciowej miejsca wykonania, bez tłumaczenia numerów portów na nazwy usług. Dane procesu przy gnieździe zobaczysz, jeśli pozwolą na to uprawnienia.

Wynik potwierdza nasłuch widziany z tego jednego miejsca. Nie dowodzi, że usługa odpowiada z internetu, że certyfikat jest poprawny ani że aplikacja zwraca sensowną treść. Gdy problem dotyczy szyfrowanego połączenia, przejdź do diagnostyki TLS przez openssl s_client - a gdy masz konkretny komunikat błędu w przeglądarce, prowadź diagnozę od tego komunikatu, nie od listy portów.

Kiedy przejść do pełnych instrukcji?

Sześć zadań ma na tej stronie tylko punkt wejścia, bo bezpieczne wykonanie wymaga całej procedury - próby, wykonania i weryfikacji w jednym ciągu:

1. Przenosisz albo synchronizujesz dane między hostami - przejdź do synchronizacji plików przez rsync, razem z próbnym uruchomieniem przed właściwym transferem.
2. Pobierasz plik na serwer i chcesz sprawdzić, czy dotarł w całości - przejdź do pobierania plików przez wget.
3. Zmieniasz prawa dostępu do pliku - przejdź do zmiany uprawnień przez chmod, zamiast wpisywać tryb liczbowy z pamięci.
4. Diagnozujesz certyfikat albo negocjację szyfrowanego połączenia - przejdź do kontroli TLS przez openssl s_client.
5. Sprawdzasz, czy host odpowiada i z jakim opóźnieniem - przejdź do pomiaru osiągalności przez ping, razem z interpretacją straty pakietów.
6. Logujesz się na zdalną maszynę albo połączenie kończy się odmową - przejdź do procedury połączenia i diagnostyki SSH, razem z weryfikacją odcisku klucza hosta.

W każdym z tych tekstów próba, wykonanie i sprawdzenie wyniku tworzą jedną procedurę - nie wyjmuj z niej pojedynczych poleceń.

Jak sprawdzić, czy polecenie zadziałało?

Widoczny komunikat i status zakończenia to dwa osobne sygnały. Powłoka trzyma status ostatniego polecenia w parametrze $? - zero oznacza powodzenie, a znaczenie pozostałych wartości opisuje dokumentacja konkretnego programu. Nie traktuj jednego statusu jako dowodu, że cały serwer działa.

Brak komunikatu też nie znaczy tego samego we wszystkich programach. Dlatego wynik sprawdzaj poleceniem dobranym do skutku i ogranicz wniosek do tego, co faktycznie zbadałeś - ls potwierdza stan wskazanej ścieżki, systemctl status stan jednostki, a ss gniazda widoczne w badanej przestrzeni.

Pytania o komendy Linux

Jakie komendy Linux musi znać administrator serwera?

Zestaw do codziennej pracy układa się według zadań: orientacja (pwd, ls), praca na plikach (cp, mv, rm), szukanie (find, grep), miejsce na dysku (df, du), procesy i usługi (ps, systemctl, journalctl) oraz sieć (ss). Zacznij od poleceń odczytu - niczego nie zmieniają, a odpowiadają na większość pytań diagnostycznych.

Co robi komenda wc?

wc liczy w danych wejściowych linie, słowa i bajty albo znaki, zależnie od użytych opcji. Wynik czytaj razem ze źródłem wejścia - liczba linii w logu mówi, ile wpisów przefiltrowałeś, ale nie mówi, czy proces, który je zapisał, działał poprawnie.

Czy plik usunięty przez rm trafia do kosza?

Nie. rm usuwa plik bez pośredniego przystanku i bez pytania o potwierdzenie w podstawowym wywołaniu. Dlatego przed wykonaniem odczytaj dokładną ścieżkę poleceniem ls i upewnij się, że wskazuje zamierzony obiekt - a po operacji sprawdź tę samą ścieżkę jeszcze raz.

Jak sprawdzić logi konkretnej usługi?

Uruchom journalctl -u NAZWA_USLUGI --since 'MOMENT_PRZED_OBJAWEM' na hoście z dziennikiem systemd, podstawiając nazwę jednostki i czas sprzed objawu. Szybszy rzut oka daje systemctl status NAZWA_USLUGI, które pokazuje stan jednostki razem z jej ostatnimi wpisami. Pełna historia wymaga journalctl, bo status pokazuje tylko końcówkę dziennika.

Jak sprawdzić, czy port jest otwarty?

Uruchom ss -ltnp na hoście albo w przestrzeni sieciowej usługi, którą diagnozujesz - polecenie wypisze nasłuchujące gniazda TCP z danymi procesów, o ile masz do nich uprawnienia. Taki wynik potwierdza nasłuch w miejscu wykonania, ale nie dostępność z innego hosta ani poprawność szyfrowania.

Źródła

Opisy poleceń pochodzą z dokumentacji ich opiekunów: POSIX dla pwd i języka powłoki, GNU Coreutils dla ls, cp, mv, rm, df, du i wc, GNU Findutils dla find, GNU Grep, procps-ng dla ps, dokumentacja systemd dla systemctl i journalctl, iproute2 dla ss oraz podręczniki rsync, GNU Wget i OpenSSL.