Ubuntu Server po instalacji: lista rzeczy do zrobienia przed produkcją

Świeżo zainstalowany Ubuntu Server zwykle działa od razu, ale to nie znaczy, że jest gotowy do produkcji. W praktyce najwięcej problemów pojawia się później: brak aktualizacji, nieczytelny hostname, otwarty SSH, brak monitoringu, brak backupu albo nikt nie wie, co właściwie jest na tym serwerze uruchomione.

Ten wpis to prosta lista rzeczy, które warto sprawdzić po instalacji Ubuntu Server, zanim postawisz na nim usługę dla firmy.

Dla kogo jest ten wpis

Dla administratora, który stawia nowy serwer VPS, maszynę wirtualną albo fizyczny serwer w małej firmie. Nie jest to opis instalatora krok po kroku. To lista czynności po pierwszym logowaniu.

1. Zaktualizuj system

Od tego warto zacząć. Nawet świeży obraz systemu może mieć paczki, które wymagają aktualizacji.

sudo apt update
sudo apt upgrade

Jeśli aktualizacja podmienia kernel albo ważne biblioteki, zaplanuj restart:

sudo reboot

Po restarcie sprawdź, czy system wstał normalnie:

uptime
systemctl --failed

2. Ustaw sensowny hostname

Nazwa typu ubuntu-s-1vcpu-1gb-fra1-01 szybko przestaje być czytelna. Lepiej od razu ustawić nazwę, która mówi, do czego służy maszyna.

sudo hostnamectl set-hostname srv-www-01

Potem sprawdź:

hostnamectl

Jeśli w firmie masz kilka serwerów, trzymaj jeden schemat nazw. Przy awarii oszczędza to czas.

3. Utwórz użytkownika administracyjnego

Nie warto pracować cały czas bezpośrednio na koncie root. Lepiej mieć osobnego użytkownika i używać sudo.

sudo adduser admin
sudo usermod -aG sudo admin

Po dodaniu użytkownika zaloguj się na niego w drugiej sesji SSH i sprawdź, czy sudo działa:

sudo whoami

Dopiero po takim sprawdzeniu zmieniaj ustawienia dostępu SSH.

4. Uporządkuj SSH

SSH to najczęstsza droga administracji serwerem, więc warto zrobić porządek od razu.

Wgraj klucz publiczny na konto użytkownika:

ssh-copy-id admin@adres-serwera

Potem sprawdź logowanie kluczem. Jeśli działa, można rozważyć wyłączenie logowania hasłem w konfiguracji SSH.

sudo nano /etc/ssh/sshd_config

Typowe ustawienia do sprawdzenia:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Uwaga: przed restartem SSH zostaw otwartą drugą sesję. Jeśli pomylisz konfigurację, możesz sam sobie odciąć dostęp.

sudo sshd -t
sudo systemctl restart ssh

5. Włącz podstawowy firewall

Na Ubuntu najprostszym wyborem jest często UFW. Zanim go włączysz, upewnij się, że dopuszczasz port SSH.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Jeśli serwer ma obsługiwać WWW:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Nie otwieraj portów „na zapas”. Każdy otwarty port powinien mieć powód.

6. Sprawdź czas i strefę czasową

Zła godzina na serwerze potrafi utrudnić analizę logów, certyfikatów i problemów z aplikacjami.

timedatectl

Jeśli trzeba ustawić strefę czasową dla Polski:

sudo timedatectl set-timezone Europe/Warsaw

7. Sprawdź usługi i błędy po starcie

Po instalacji i aktualizacji warto sprawdzić, czy system nie ma nieudanych usług.

systemctl --failed

Do szybkiego przeglądu logów po ostatnim uruchomieniu:

journalctl -p warning -b

Nie każdy warning oznacza awarię, ale warto wiedzieć, z czym startuje serwer.

8. Zainstaluj podstawowe narzędzia

Na czystym serwerze często brakuje narzędzi, których później i tak będziesz potrzebować przy diagnostyce.

sudo apt install curl wget vim htop ncdu net-tools dnsutils traceroute

Dobór pakietów zależy od środowiska. Nie ma sensu instalować wszystkiego, ale podstawowy zestaw diagnostyczny zwykle się przydaje.

9. Przygotuj backup zanim postawisz usługę

Backup ustawiony po awarii nie pomaga. Jeśli serwer ma przechowywać dane, przygotuj kopię zanim uruchomisz produkcję.

Minimum do ustalenia:

• co backupujesz,
• jak często,
• gdzie trafia kopia,
• jak długo trzymasz stare kopie,
• jak sprawdzasz, czy backup się wykonał,
• czy umiesz odtworzyć dane.

Backup na tym samym serwerze jest tylko częściowym zabezpieczeniem. Przy poważniejszej awarii może zniknąć razem z maszyną.

10. Podłącz monitoring

Nawet prosty monitoring jest lepszy niż czekanie, aż użytkownik zadzwoni, że coś nie działa.

Na start warto monitorować:

• dostępność serwera,
• miejsce na dysku,
• obciążenie CPU,
• RAM,
• status ważnych usług,
• wygasanie certyfikatów SSL.

Może to być Zabbix, gotowa usługa SaaS albo prostszy skrypt. Ważne, żeby alert trafiał do kogoś, kto faktycznie może zareagować.

11. Zapisz podstawową dokumentację

Dokumentacja nie musi być rozbudowana. Na początek wystarczy krótka notatka:

• nazwa serwera,
• adres IP,
• rola serwera,
• kto ma dostęp,
• gdzie jest backup,
• jakie usługi działają,
• gdzie są pliki konfiguracyjne,
• jak odtworzyć usługę po awarii.

Przy jednym serwerze łatwo to lekceważyć. Przy trzech albo pięciu zaczyna się szukanie po historii terminala i starych wiadomościach.

Przykład z praktyki

Typowy scenariusz: powstaje nowy VPS pod stronę albo małą aplikację. Administrator instaluje Nginx, PHP, bazę danych i oddaje temat. Po kilku miesiącach kończy się miejsce na dysku, bo logi albo backupy lokalne rosną bez kontroli. Nie ma monitoringu, więc problem wychodzi dopiero wtedy, gdy aplikacja przestaje działać.

Większości takich sytuacji da się uniknąć prostą checklistą po instalacji: monitoring dysku, backup poza serwerem, firewall, aktualizacje i zapisanie, co właściwie działa na maszynie.

Na co uważać

• Nie wyłączaj logowania hasłem w SSH, zanim nie sprawdzisz logowania kluczem.
• Nie włączaj firewalla bez dopuszczenia portu SSH.
• Nie zostawiaj usług testowych wystawionych publicznie.
• Nie trzymaj jedynego backupu na tym samym serwerze.
• Nie zakładaj, że monitoring działa, jeśli nigdy nie dostałeś testowego alertu.

Podsumowanie

Ubuntu Server po instalacji jest dopiero punktem startowym. Zanim uruchomisz na nim usługę produkcyjną, warto uporządkować dostęp, aktualizacje, firewall, czas, backup, monitoring i podstawową dokumentację.

To nie są rzeczy efektowne, ale właśnie one decydują, czy przy awarii masz procedurę, czy tylko nerwowe logowanie na serwer i zgadywanie, co się stało.