Linux dla administratora – najważniejsze polecenia, które warto znać

Linux może na początku sprawiać wrażenie systemu składającego się z setek tajemniczych poleceń, plików konfiguracyjnych i usług działających gdzieś w tle. W praktyce administracja Linuksem wygląda znacznie prościej.

Nie trzeba znać wszystkich poleceń na pamięć.

Znacznie ważniejsze jest zrozumienie jak działa system, gdzie szukać informacji i jak krok po kroku diagnozować problemy.

Administrator najczęściej odpowiada sobie na kilka podstawowych pytań:

• Czy system działa?
• Czy działa konkretna usługa?
• Co mówią logi?
• Czy serwer ma wolne zasoby?
• Czy działa komunikacja sieciowa?
• Czy odpowiedni port nasłuchuje?
• Czy użytkownik ma właściwe uprawnienia?
• Czy problem pojawił się po aktualizacji lub zmianie konfiguracji?

Jeżeli nauczysz się sprawnie odpowiadać na te pytania, znajomość Linuksa zaczyna być naprawdę praktyczna.

W tym poradniku przejdziemy od podstawowych poleceń aż do diagnostyki usług, sieci, procesów, logów i miejsca na dyskach.

---

1. Terminal – podstawowe narzędzie administratora Linux

W środowisku serwerowym bardzo często nie mamy graficznego interfejsu użytkownika. Administracja odbywa się poprzez terminal – lokalnie albo zdalnie przez SSH.

Po zalogowaniu możemy zobaczyć przykładowo:

admin@server:~$

Znak $ zazwyczaj oznacza zwykłego użytkownika, natomiast konto root często przedstawiane jest jako:

root@server:~#

Pierwsze polecenie, które warto poznać, to:

whoami

Otrzymamy nazwę aktualnego użytkownika:

admin

Więcej informacji dostarczy:

id

Przykładowo:

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

Od razu możemy zobaczyć identyfikator użytkownika oraz grupy, do których należy.

Jest to szczególnie przydatne podczas diagnozowania problemów z uprawnieniami.

---

# 2. Poruszanie się po systemie plików

Jedną z najważniejszych umiejętności jest sprawne poruszanie się po strukturze katalogów.

Aktualną lokalizację sprawdzimy poleceniem:

pwd

Przykład:

/home/admin

Listę plików wyświetlimy poprzez:

ls

Znacznie częściej używam jednak:

ls -lah

Dlaczego?

Parametry oznaczają:

• -l – szczegółowy widok,
• -a – również pliki ukryte,
• -h – rozmiary w czytelnej formie.

Możemy otrzymać:

drwxr-xr-x  4 admin admin 4.0K Sep 11 08:20 .
drwxr-xr-x  3 root  root  4.0K Sep 10 15:10 ..
-rw-r--r--  1 admin admin 2.3K Sep 11 08:18 config.txt

Już z jednej linijki możemy odczytać typ obiektu, uprawnienia, właściciela, grupę, rozmiar i datę modyfikacji.

Zmiana katalogu

Do przechodzenia pomiędzy katalogami służy:

cd

Przykładowo:

cd /var/log

Powrót poziom wyżej:

cd ..

Katalog domowy:

cd ~

Powrót do poprzedniej lokalizacji:

cd -

Ten ostatni wariant jest bardzo wygodny podczas pracy pomiędzy dwoma katalogami.

---

# 3. Tworzenie, kopiowanie i usuwanie plików

Nowy katalog utworzymy poleceniem:

mkdir test

Kilka poziomów katalogów jednocześnie:

mkdir -p projekty/linux/test

Pusty plik:

touch test.txt

Kopiowanie:

cp test.txt kopia.txt

Kopiowanie całego katalogu:

cp -r katalog katalog-kopia

Przenoszenie lub zmiana nazwy:

mv stara-nazwa.txt nowa-nazwa.txt

Usuwanie:

rm plik.txt

Katalog wraz z zawartością:

rm -r katalog

I tutaj pojawia się jedna z najważniejszych zasad administracji Linuksem:

Zanim wykonasz rm, szczególnie jako root, sprawdź dwa razy, co dokładnie usuwasz.

Polecenie:

rm -rf

jest niezwykle skuteczne, ale właśnie dlatego powinno być używane świadomie.

Linux zazwyczaj zakłada, że administrator wie, co robi.

---

# 4. Jak znaleźć plik w systemie?

Na serwerach szybko pojawia się ogromna liczba plików.

Do wyszukiwania możemy użyć:

find

Przykład:

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

Znajdziemy wszystkie pliki kończące się rozszerzeniem .log.

Możemy szukać katalogów:

find / -type d -name "backup"

albo plików zmodyfikowanych w ciągu ostatnich siedmiu dni:

find /var/log -type f -mtime -7

Bardzo przydatne jest również wyszukiwanie dużych plików:

find / -type f -size +1G 2>/dev/null

Polecenie znajdzie pliki większe niż 1 GB.

2>/dev/null ukrywa w tym przypadku komunikaty błędów wysyłane na standardowe wyjście błędów.

---

# 5. grep – jedno z najważniejszych narzędzi administratora

grep pozwala wyszukiwać tekst.

Przykład:

grep "error" application.log

Ignorowanie wielkości liter:

grep -i "error" application.log

Przeszukiwanie katalogu:

grep -R "database" /etc/

Możemy też połączyć grep z innym poleceniem.

Na przykład:

ps aux | grep nginx

Znak:

|

to pipe, czyli potok.

Wynik pierwszego polecenia staje się wejściem kolejnego.

To jedna z najważniejszych koncepcji terminala Linux.

Przykładowo:

ip a | grep inet

albo:

journalctl | grep -i error

Dzięki potokom możemy budować bardzo potężne zestawy poleceń z prostych narzędzi.

---

# 6. Sprawdzanie miejsca na dyskach

Jeden z klasycznych problemów serwerowych:

„Usługa przestała działać.”

Administrator sprawdza konfigurację, restartuje usługę, analizuje sieć...

A przyczyną okazuje się:

/dev/mapper/... 100%

Dlatego jednym z pierwszych poleceń diagnostycznych powinno być:

df -h

Przykład:

Filesystem      Size  Used Avail Use%
/dev/sda2       100G   82G   18G  82%

Parametr -h oznacza human-readable.

Jeżeli partycja jest pełna, kolejnym krokiem może być:

du -sh /*

W konkretnym katalogu:

du -sh /var/*

Możemy również posortować wynik:

du -h /var | sort -h

Albo znaleźć największe elementy:

du -ah /var | sort -rh | head -20

To niezwykle przydatna kombinacja podczas poszukiwania katalogu lub pliku, który „zjadł” przestrzeń dyskową.

---

# 7. Dyski i urządzenia blokowe

Informacje o dyskach możemy wyświetlić poleceniem:

lsblk

Przykład:

NAME   SIZE TYPE MOUNTPOINT
sda    100G disk
├─sda1   1G part /boot
└─sda2  99G part /

Więcej informacji:

lsblk -f

Możemy wtedy zobaczyć między innymi system plików oraz UUID.

Przydatne są również:

blkid

oraz:

fdisk -l

W środowiskach serwerowych możemy dodatkowo spotkać LVM, RAID, storage sieciowy czy systemy plików takie jak ext4, XFS lub ZFS.

Wtedy diagnostyka storage staje się osobnym, bardzo dużym zagadnieniem.

---

# 8. Procesy – co właściwie działa na serwerze?

Lista procesów:

ps aux

Wynik może być ogromny, dlatego często łączymy polecenie z grep:

ps aux | grep nginx

Do obserwowania systemu w czasie rzeczywistym możemy użyć:

top

Jeszcze wygodniejszy jest często:

htop

Jeżeli nie jest zainstalowany:

sudo apt install htop

Możemy obserwować wykorzystanie CPU, pamięci RAM, procesy oraz ich identyfikatory PID.

PID procesu możemy również znaleźć poprzez:

pgrep nginx

lub:

pidof nginx

---

# 9. Kończenie procesów

Standardowe zakończenie procesu:

kill PID

Na przykład:

kill 1234

Domyślnie wysyłany jest sygnał SIGTERM, który daje procesowi możliwość poprawnego zakończenia pracy.

Dopiero kiedy proces nie reaguje, można rozważyć:

kill -9 1234

czyli SIGKILL.

Nie powinno się automatycznie zaczynać od kill -9.

Proces nie ma wtedy możliwości wykonania normalnej procedury zamknięcia.

---

# 10. Pamięć RAM i obciążenie systemu

Podstawowe informacje o pamięci:

free -h

Możemy zobaczyć między innymi pamięć:

• całkowitą,
• używaną,
• wolną,
• cache,
• dostępną,
• swap.

W Linuksie mała wartość free nie oznacza automatycznie braku pamięci.

System wykorzystuje nieużywany RAM między innymi jako cache. Dlatego znacznie bardziej interesująca jest wartość available.

Obciążenie systemu sprawdzimy poprzez:

uptime

Przykładowo:

12:05:31 up 31 days, 4:22, 2 users, load average: 0.18, 0.25, 0.22

Oprócz czasu działania otrzymujemy load average dla ostatnich 1, 5 i 15 minut.

Interpretując load average, warto znać liczbę dostępnych CPU/logicznych rdzeni:

nproc

---

# 11. Linux i sieć – absolutna podstawa administratora

Przechodzimy do jednego z najważniejszych obszarów administracji.

Adresy IP:

ip a

Trasy:

ip r

Możemy otrzymać:

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel

To mówi nam, którędy system będzie wysyłał ruch.

Test komunikacji:

ping 8.8.8.8

Jeżeli IP odpowiada, ale:

ping google.com

nie działa, warto zacząć podejrzewać problem z DNS.

Sprawdzamy więc:

dig google.com

lub:

nslookup google.com

---

# 12. Diagnostyka trasy

Jeżeli host nie odpowiada, chcemy czasami wiedzieć, gdzie kończy się komunikacja.

Możemy wykorzystać:

traceroute 10.10.1.3

lub:

tracepath 10.10.1.3

To szczególnie użyteczne w bardziej złożonych środowiskach zawierających routery, VLAN-y, VPN-y czy tunele IPsec.

Sam fakt, że host nie odpowiada na ping, nie oznacza jednak jeszcze, że jest niedostępny.

ICMP może być blokowane.

Dlatego warto testować konkretną usługę.

---

# 13. Czy port rzeczywiście działa?

Załóżmy, że mamy serwer Zabbix Agent:

10.10.1.3:10050

Możemy przetestować:

nc -zv -w3 10.10.1.3 10050

Jeżeli zobaczymy:

Connection timed out

wiemy już znacznie więcej niż po samym ping.

Problem może dotyczyć:

• firewalla,
• routingu,
• usługi,
• ACL,
• VPN/IPsec,
• konfiguracji aplikacji,
• albo braku nasłuchiwania na danym porcie.

Sprawdzenie lokalnych portów:

ss -tulnp

Przykład:

LISTEN 0 4096 0.0.0.0:22
LISTEN 0 4096 0.0.0.0:10050

Możemy sprawdzić konkretny port:

ss -tulnp | grep 10050

I już wiemy, czy usługa faktycznie nasłuchuje.

---

# 14. curl – nie tylko pobieranie stron

curl jest niezwykle przydatnym narzędziem diagnostycznym.

Podstawowy test:

curl https://example.com

Same nagłówki:

curl -I https://example.com

Więcej informacji o połączeniu:

curl -v https://example.com

Przy problemach z serwerem WWW możemy dzięki temu diagnozować między innymi:

• DNS,
• TCP,
• TLS,
• HTTP,
• przekierowania,
• odpowiedź aplikacji.

Jeżeli administrujesz serwerami WWW, curl bardzo szybko staje się jednym z podstawowych narzędzi.

---

# 15. Uprawnienia – rwx

Linux wykorzystuje trzy podstawowe prawa:

r – read
w – write
x – execute

oraz trzy grupy:

user
group
others

Przykład:

-rwxr-xr--

Możemy również używać zapisu numerycznego:

r = 4
w = 2
x = 1

Dlatego:

7 = rwx
6 = rw-
5 = r-x
4 = r--

Polecenie:

chmod 755 skrypt.sh

oznacza:

właściciel: rwx
grupa:      r-x
inni:       r-x

Zmiana właściciela:

chown admin plik

Właściciel i grupa:

chown admin:www-data plik

Rekurencyjnie:

chown -R admin:www-data /var/www/projekt

Z opcją -R należy uważać. Jedno nieprzemyślane polecenie może zmienić uprawnienia tysięcy plików.

---

# 16. Użytkownicy i grupy

Informacje o aktualnym użytkowniku:

whoami

oraz:

id

Dodanie użytkownika w Debianie/Ubuntu:

sudo adduser jarek

Dodanie użytkownika do grupy:

sudo usermod -aG sudo jarek

Sprawdzenie grup:

groups jarek

Zmiana hasła:

passwd

lub dla konkretnego użytkownika:

sudo passwd jarek

W środowisku serwerowym warto stosować zasadę najmniejszych wymaganych uprawnień.

Nie każdy użytkownik powinien być rootem.

Nie każda aplikacja powinna działać jako root.

---

# 17. sudo zamiast ciągłej pracy jako root

Zamiast logować się cały czas jako root, lepiej korzystać z:

sudo polecenie

Na przykład:

sudo systemctl restart nginx

To ogranicza ryzyko przypadkowego wykonania niebezpiecznej operacji.

Administrator z uprawnieniami roota praktycznie nie ma zabezpieczenia przed własnym błędem.

---

# 18. systemctl – zarządzanie usługami

W dystrybucjach wykorzystujących systemd jednym z najważniejszych poleceń jest:

systemctl

Sprawdzenie usługi:

systemctl status nginx

Uruchomienie:

sudo systemctl start nginx

Zatrzymanie:

sudo systemctl stop nginx

Restart:

sudo systemctl restart nginx

Automatyczne uruchamianie podczas startu:

sudo systemctl enable nginx

Wyłączenie autostartu:

sudo systemctl disable nginx

Można również wykonać:

systemctl is-active nginx

oraz:

systemctl is-enabled nginx

Są to świetne polecenia do skryptów diagnostycznych.

---

# 19. journalctl – administrator powinien czytać logi

Jeżeli usługa nie działa, nie warto jej restartować dziesięć razy z nadzieją, że „może ruszy”.

Najpierw:

systemctl status nazwa-usługi

Następnie:

journalctl -u nazwa-usługi

Ostatnie wpisy:

journalctl -u nginx -n 50

Obserwowanie logów na żywo:

journalctl -u nginx -f

Logi z aktualnego bootowania:

journalctl -b

Błędy:

journalctl -p err

Błędy aktualnego bootowania:

journalctl -p err -b

To często w ciągu kilkunastu sekund prowadzi administratora bezpośrednio do źródła problemu.

---

# 20. dmesg – gdy problem jest bliżej kernela

Nie wszystkie problemy dotyczą aplikacji.

Czasami interesują nas informacje pochodzące z jądra:

dmesg

Ostatnie wpisy:

dmesg | tail

Wyszukiwanie błędów:

dmesg | grep -i error

Możemy znaleźć informacje dotyczące między innymi:

• dysków,
• interfejsów sieciowych,
• sterowników,
• pamięci,
• USB,
• błędów I/O,
• urządzeń.

Jeżeli system nagle przestaje widzieć urządzenie albo pojawiają się błędy dysku, dmesg powinien znaleźć się wysoko na liście narzędzi diagnostycznych.

---

# 21. Zarządzanie pakietami – Debian i Ubuntu

Aktualizacja informacji o pakietach:

sudo apt update

Aktualizacja:

sudo apt upgrade

Instalacja:

sudo apt install nginx

Usunięcie:

sudo apt remove nginx

Wyszukiwanie:

apt search nginx

Informacje:

apt show nginx

Lista zainstalowanych pakietów:

apt list --installed

Warto rozróżniać:

apt update

od:

apt upgrade

Pierwsze aktualizuje informacje o dostępnych pakietach. Drugie aktualizuje zainstalowane pakiety zgodnie z dostępnymi wersjami.

Na serwerach produkcyjnych aktualizacji nie powinno się wykonywać bezrefleksyjnie.

Backup → sprawdzenie zmian → aktualizacja → kontrola usług → kontrola logów.

---

# 22. SSH – zdalna administracja

Większością serwerów będziemy zarządzać poprzez SSH:

ssh user@192.168.1.100

Na przykład:

ssh admin@10.10.1.3

Możemy również używać kluczy SSH zamiast haseł.

Generowanie klucza:

ssh-keygen

Kopiowanie klucza na serwer:

ssh-copy-id admin@10.10.1.3

Po odpowiednim skonfigurowaniu możemy logować się bez podawania hasła użytkownika.

W środowisku produkcyjnym warto również rozważyć:

• wyłączenie logowania roota przez SSH,
• logowanie kluczami,
• ograniczenie dostępu firewallem,
• ochronę przed próbami brute-force,
• monitoring logowań.

---

# 23. Historia poleceń

Administrator nie musi wpisywać wszystkiego ponownie.

Historia:

history

Wyszukiwanie:

history | grep systemctl

Jeszcze wygodniejsze jest:

Ctrl + R

Naciskamy Ctrl + R i zaczynamy wpisywać fragment poprzedniego polecenia.

Terminal przeszukuje historię.

To jeden z tych skrótów, który po poznaniu zaczyna być używany bez przerwy.

---

# 24. Najważniejsze skróty terminala

Kilka skrótów znacząco przyspiesza pracę:

Dodatkowo:

!!

wykonuje poprzednie polecenie.

Przykładowo wpisaliśmy:

apt update

i zapomnieliśmy sudo.

Możemy wykonać:

sudo !!

Shell rozwinie to do poprzedniego polecenia.

---

# 25. man i --help – nie próbuj wszystkiego zapamiętać

Jeżeli nie pamiętamy składni:

man find

albo:

find --help

Wyszukiwanie w man:

/

Następny wynik:

n

Wyjście:

q

Dobry administrator nie jest człowiekiem, który zna każdą opcję find, rsync, tar czy journalctl.

Dobry administrator wie, jak znaleźć właściwą opcję, kiedy jej potrzebuje.

---

# 26. Jak naprawdę diagnozować awarię Linux?

I tutaj dochodzimy do najważniejszej części.

Znajomość poleceń jest przydatna, ale sama lista komend nie robi jeszcze z nikogo administratora.

Załóżmy, że otrzymujemy zgłoszenie:

„Aplikacja nie działa.”

Nie zaczynamy od restartowania wszystkiego.

Najpierw ustalamy fakty.

Krok 1 – czy serwer działa?

ping IP

Jeżeli mamy SSH:

ssh admin@IP

Krok 2 – jak wygląda stan systemu?

uptime
free -h
df -h

Sprawdzamy CPU/load, RAM oraz dyski.

Krok 3 – czy działa usługa?

systemctl status aplikacja

Krok 4 – co mówią logi?

journalctl -u aplikacja -n 100

Krok 5 – czy aplikacja nasłuchuje?

ss -tulnp

lub:

ss -tulnp | grep PORT

Krok 6 – test lokalny

Jeżeli jest to HTTP:

curl -v http://127.0.0.1:PORT

Jeżeli lokalnie działa, ale z innego komputera nie – problem prawdopodobnie znajduje się gdzie indziej.

Krok 7 – sieć

ip a
ip r
ping BRAMA

Następnie sprawdzamy firewall, routing, NAT, ACL, VLAN, VPN itd.

To właśnie metodyczne zawężanie problemu jest podstawą skutecznego troubleshooting'u.

---

# 27. Przykład: serwer WWW nie odpowiada

Załóżmy:

https://moja-strona.pl

nie działa.

Sprawdzamy DNS:

dig moja-strona.pl

Następnie serwer:

ping IP

SSH:

ssh admin@IP

Status Nginx:

systemctl status nginx

Porty:

ss -tulnp | grep -E ':80|:443'

Test lokalny:

curl -I http://127.0.0.1

Logi:

journalctl -u nginx -n 100

Miejsce:

df -h

Pamięć:

free -h

Konfiguracja Nginx:

nginx -t

W ten sposób zamiast zgadywać, warstwa po warstwie ustalamy, gdzie kończy się prawidłowe działanie systemu.

---

# 28. Przykład: dysk ma 100%

Załóżmy:

df -h

pokazuje:

/dev/mapper/system-root  100%

Nie zaczynamy od przypadkowego kasowania plików.

Najpierw:

du -xhd1 / | sort -h

Załóżmy, że największy jest /var.

Schodzimy niżej:

du -xhd1 /var | sort -h

Okazuje się, że problemem jest:

/var/log

Więc:

du -xhd1 /var/log | sort -h

W ten sposób zawężamy problem.

To znacznie bezpieczniejsze niż:

„Dysk pełny? To usuńmy coś dużego.”

---

# 29. Automatyzacja – następny etap

Kiedy podstawowe polecenia przestają być problemem, warto rozpocząć naukę Bash.

Prosty przykład:

#!/bin/bash

echo "=== HOST ==="
hostname

echo "=== UPTIME ==="
uptime

echo "=== RAM ==="
free -h

echo "=== DISK ==="
df -h

echo "=== IP ==="
ip a

Uruchamiamy:

chmod +x check.sh
./check.sh

I właśnie tutaj Linux zaczyna pokazywać swoją prawdziwą siłę.

Polecenia, które wcześniej wykonywaliśmy ręcznie, możemy połączyć w skrypt.

Potem dochodzą:

• zmienne,
• instrukcje if,
• pętle,
• funkcje,
• cron,
• API,
• Ansible,
• monitoring,
• CI/CD.

Wtedy przechodzimy od zwykłej administracji do automatyzacji infrastruktury i DevOps.

---

# 30. Linux to nie nauka komend – to nauka sposobu myślenia

Na początku naturalne jest szukanie:

„Jakie komendy Linux muszę znać?”

Po pewnym czasie pytanie zmienia się na:

„Jak mogę sprawdzić, co się tutaj dzieje?”

I to jest bardzo ważna różnica.

Administrator widzący niedziałającą usługę zaczyna budować sobie model problemu:

Proces → usługa → logi → port → firewall → routing → DNS → klient.

Przy problemie z wydajnością:

load → CPU → RAM → swap → I/O → proces → aplikacja.

Przy pełnym dysku:

filesystem → katalog → podkatalog → plik → proces generujący dane.

Nie zgadujemy.

Zbieramy informacje i eliminujemy kolejne możliwości.

---

# Ściąga administratora Linux

Jeżeli miałbym wybrać zestaw poleceń, które początkujący administrator powinien znać jako pierwsze, byłby to:

pwd
ls -lah
cd
cp
mv
rm
find
grep

cat
less
tail
head

df -h
du -sh
lsblk
free -h
uptime

ps aux
top
htop
kill

ip a
ip r
ping
traceroute
dig
ss -tulnp
curl
nc

chmod
chown
id
sudo

systemctl
journalctl
dmesg

apt update
apt upgrade
apt install

ssh
scp
rsync

history
man

Nie trzeba nauczyć się tej listy jednego dnia.

Najlepiej uruchomić własną maszynę wirtualną z Debianem lub Ubuntu i po prostu zacząć eksperymentować.

---

# Co dalej?

Jeżeli podstawy masz już opanowane, kolejnymi naturalnymi etapami są:

Linux → sieci → Bash → SSH → firewall → systemd → monitoring → wirtualizacja → Docker → Ansible → Git → CI/CD.

Potem można wejść jeszcze głębiej w:

• Proxmox,
• Zabbix,
• Wazuh,
• Nginx/Apache,
• MariaDB/PostgreSQL,
• Docker i Docker Compose,
• Kubernetes,
• backup i disaster recovery,
• VPN/IPsec,
• hardening serwerów,
• automatyzację Ansible,
• centralne logowanie,
• monitoring infrastruktury.

I tutaj zaczyna się naprawdę ciekawa część administracji systemami.

---

Podsumowanie

Linux nie wymaga zapamiętania setek komend.

Wymaga przede wszystkim zrozumienia co sprawdzić, kiedy coś przestaje działać.

Zamiast przypadkowo restartować usługi, sprawdź ich status.

Zamiast zgadywać, dlaczego aplikacja nie odpowiada, sprawdź port.

Zamiast zakładać, że „sieć nie działa”, sprawdź adresację, routing i DNS.

Zamiast kasować przypadkowe pliki, kiedy kończy się miejsce, znajdź katalog odpowiedzialny za jego zużycie.

I przede wszystkim – czytaj logi.

W praktycznej administracji bardzo dobrze sprawdza się prosta zasada:

Najpierw sprawdź stan. Potem logi. Następnie sieć i zasoby. Dopiero później zmieniaj konfigurację.

Im więcej rzeczy diagnozujesz samodzielnie, tym mniej potrzebujesz gotowych recept.

I właśnie wtedy Linux przestaje być systemem pełnym tajemniczych komend, a zaczyna być bardzo logicznym i przewidywalnym narzędziem pracy.

Małe komendy. Duże możliwości.

piek-dev.pl Linux • Sieci • Administracja • DevOps