Automatyczny skrypt instalacyjny

Metoda automatyczna: jeden skrypt z panelu klienta przygotowuje cały serwer (stos WWW Apache + PHP, bazę danych, narzędzia bezpieczeństwa, cron). Następnie — wdrożenie panelu, wystawienie certyfikatu SSL i wprowadzenie licencji. Działa na Ubuntu/Debian: na świeżym VPS konfiguruje wszystko od zera, a na już skonfigurowanym serwerze — wyłącznie addytywnie (profil „Skonfigurowany serwer”, krok 01). Wszystkie poniższe polecenia są uporządkowane, wystarczy przewijać od góry do dołu. Na świeżym VPS pasuje każdy krok po kolei; jeśli serwer jest już skonfigurowany lub działa na nim panel hostingowy, część pracy skrypt celowo pozostawia Panu/Pani — co dokładnie, wypisuje na końcu swojego działania (omówienie wyniku — w kroku 01).

Wybór metody Instalacja ręczna Poradnik FAQ

Wartości zastępcze w poleceniach zastąp własnymi: monitor.example.com — Pana/Pani domena; 203.0.113.10 — rzeczywisty adres IP serwera; /var/www/monitor — katalog główny panelu (gdzie znajdują się public/, assets/, config.php); hasło do bazy danych wymyśl własne.

Pełny zestaw („Pełna ochrona”) jest przeznaczony dla świeżego VPS. Na czystym Ubuntu/Debian konfiguruje system bezpieczeństwa od zera — Fail2ban (jail.local), root-crontab, reguły UFW, konfigurację Apache. Jeśli serwer jest już skonfigurowany (działający panel, strony, poczta, własne jaile) — wybierz profil „Skonfigurowany serwer”: wprowadza on tylko zmiany addytywne i nie narusza Pana/Pani zapory, Fail2ban, poczty, SSH ani sysctl. Po wykryciu panelu hostingowego skrypt sam przełącza się na ten tryb. Przed pierwszym uruchomieniem można włączyć przebieg próbny (opcja w panelu) — pokaże, co zostanie wykonane, nie zmieniając niczego. Na działającym serwerze na wszelki wypadek wykonaj migawkę (snapshot).

01. Polecenie automatycznej konfiguracji z panelu

Polecenie pobiera Pan/Pani we własnym panelu klienta my.arciveo.com → sekcja „Konfiguracja serwera” (dostępna po wykupieniu Arcivéo Security Monitor). Jest ono powiązane z Pana/Pani kontem i zawiera osobisty token.

Skrypt przygotowuje cały serwer: stos WWW (Apache + PHP), bazę danych, narzędzia do SSL, pełny zestaw środków ochrony oraz zadania cron (Lynis, SMART, debsums, Logwatch, codzienny raport, aktualizacja ipsum).

1) Wybierz poziom ochrony (w panelu, przed skopiowaniem polecenia):

Pełna ochrona (zalecana) — UFW (zapora), Fail2ban, CrowdSec + bouncer, ipsum (lista blokowanych IP), Suricata (IDS/IPS), Falco, ModSecurity + OWASP CRS (WAF), PSAD, mod_evasive (anty-DoS), AIDE (integralność plików), debsums, ClamAV + maldet (antywirus), Auditd, AppArmor, Monit, Lynis (audyt), Logwatch, automatyczne aktualizacje zabezpieczeń.
Odchudzona — dla VPS z małą ilością RAM: podstawowy zestaw bez ciężkich komponentów.
Skonfigurowany serwer (panel hostingowy) — dla już działającego serwera z panelem (HestiaCP itp.), witrynami i pocztą: tylko zmiany addytywne (doinstalowanie narzędzi, cron, reguły sudo), a zapora, Fail2ban, poczta, SSH i sysctl pozostają bez zmian. Na serwerze z panelem skrypt wybiera ten tryb samodzielnie.

Uruchomienie próbne. W panelu można zaznaczyć opcję „Uruchomienie próbne” — wtedy polecenie tylko pokaże, co skrypt zainstaluje i zmieni, i zakończy się, niczego nie naruszając. Przydatne na już skonfigurowanym serwerze: najpierw próbne uruchomienie, potem właściwe bez zaznaczonej opcji.

2) Wykonaj na serwerze jako root polecenie z panelu — wygląda ono tak:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN" | sudo bash

Polecenie proszę zachować w tajemnicy — jest powiązane z Pana/Pani kontem. Odnośnik ma ograniczony okres ważności; jeśli wygasł, proszę kliknąć w panelu „Pobierz nowy odnośnik”.

Po automatycznej konfiguracji serwerem WWW jest Apache + PHP-FPM, a narzędzia bezpieczeństwa oraz zadania cron są już zainstalowane i działają „od razu”.

3) Proszę przeczytać wynik na końcu — tam napisano, co pozostaje po Pana/Pani stronie. Skrypt kończy pracę blokiem kontrolnym i listą „Dalej — instalacja panelu”. Części kroków celowo nie wykonuje: co dokładnie, zależy od wybranego profilu i od tego, co znalazł na serwerze. Proszę porównać z poniższą listą — wykonać należy tylko te punkty, których wiersze pojawiły się w Pana/Pani wyniku.

Control panel detected (…) — witryna tworzona jest środkami samego panelu hostingowego, skrypt nie zakłada vhosta. Krok 03, gałąź „Serwer z panelem hostingowym”.
No vhost created (no domain given) — profil „Skonfigurowany serwer” bez domeny: vhost bez nazwy stałby się witryną domyślną i przechwytywałby Pana/Pani własne witryny, dlatego nie został utworzony. Krok 03, gałąź „Utworzyć vhost ręcznie”.
sudo rules NOT written — skrypt nie zdołał ustalić, na jakim koncie działa panel. To zwykła sytuacja: pliki panelu wgrywa się dopiero po automatycznej konfiguracji, więc nie było jeszcze na czym się oprzeć. Bez tych reguł moduły nie zobaczą danych systemowych. Krok 04, blok „sudo dla serwera WWW”.
! Nginx does not read .htaccess — przed Apache stoi Nginx, a wpisanie zakazu do jego konfiguracji nie powiodło się automatycznie. Proszę koniecznie to zrobić: inaczej data/, keys/, database/ i config.php są wydawane na zewnątrz z pominięciem .htaccess. Krok 03, blok „Jeśli przed Apache stoi Nginx”.
UFW installed but inactive — zapora jest zainstalowana, ale wyłączona: na skonfigurowanym serwerze skrypt nie włącza jej sam, aby nie odciąć Panu/Pani dostępu. Proszę włączyć ją samodzielnie, koniecznie zezwalając na własny port SSH:
sudo ufw allow OpenSSH # niestandardowy port SSH: sudo ufw allow 2222/tcp sudo ufw allow 80,443/tcp sudo ufw enable
Fail2ban installed but not running — proszę uruchomić: sudo systemctl enable --now fail2ban.
Database server present … but not running — proszę uruchomić serwer bazy przed krokiem 04: sudo systemctl enable --now mariadb (lub mysql — zależnie od tego, co jest zainstalowane).
Certbot skipped — issue SSL in … — certyfikat wydaje się przełącznikiem Let's Encrypt w panelu hostingowym; krok 06 nie jest Panu/Pani potrzebny.

Jeśli w bloku kontrolnym wszystko jest w porządku, ostatni wiersz to All checks passed. Punkty ze znakiem ! wymagają uwagi; szczegóły trafiają do logu, którego ścieżkę skrypt wypisuje na samym końcu (Log: …).

02. Domena i DNS

Aby otwierać panel pod adresem takim jak monitor.example.com i uzyskać darmowy SSL, domena musi wskazywać na serwer. W panelu zarządzania DNS (u rejestratora lub hostingodawcy) utwórz rekord A:

Typ: A Nazwa: monitor (subdomena → monitor.example.com) lub @ (domena główna → example.com) Wartość: 203.0.113.10 ← IP Pana serwera TTL: 3600

Po kilku minutach (czasem do godziny) sprawdź, czy domena wskazuje na serwer:

dig +short monitor.example.com # powinien zwrócić Pana IP # lub, jeśli nie ma dig: getent hosts monitor.example.com

Certyfikat SSL (krok 06) jest wydawany wyłącznie dla domeny — dlatego DNS musi wskazywać na serwer przed wydaniem certyfikatu.

03. Wgraj pliki panelu

Zwykły przypadek (świeży VPS). Autokonfiguracja utworzyła już katalog panelu /var/www/monitor i skonfigurowała witrynę Apache (DocumentRoot na katalog główny panelu, PHP-FPM, AllowOverride dla .htaccess). W wyniku skryptu jest to wiersz vhost … → DocumentRoot …. Nie trzeba osobno tworzyć katalogu ani vhosta — wystarczy wgrać pliki i ustawić uprawnienia.

Dwa przypadki, w których vhost NIE został utworzony — skrypt wprost informuje o tym na końcu pracy. Wtedy proszę najpierw wykonać właściwą gałąź poniżej, a dopiero potem wgrywać pliki.

Gałąź „Serwer z panelem hostingowym” (w wyniku: Control panel detected (…)). Witrynami na takim serwerze zarządza panel, więc własnego vhosta skrypt celowo nie tworzy — zostałby nadpisany przy pierwszej przebudowie konfiguracji przez panel. Kolejność jest następująca:

Proszę założyć domenę WWW w panelu hostingowym (HestiaCP itp.) — jej DocumentRoot pozostaje bez zmian.
Proszę wgrać dystrybucję w całości do public_html tej domeny: obok index.php, api/, assets/ muszą znaleźć się także służbowe config.php, includes/, data/, tmp/, logs/, keys/, cron/, database/. Niczego nie trzeba wynosić powyżej katalogu głównego witryny: katalogi służbowe zamyka plik .htaccess z dystrybucji, a pod Nginx — zakaz, który skrypt wpisał do konfiguracji domeny.
SSL wydaje się przełącznikiem Let's Encrypt w samym panelu — krok 06 proszę pominąć.
Dalej — uprawnienia (niżej w tym kroku), baza (krok 04) i config.php (krok 05). Ścieżki w poleceniach proszę zastąpić przez /home/konto/web/domena/public_html, a właściciela — użytkownikiem tej domeny zamiast www-data.

Gałąź „Utworzyć vhost ręcznie” (w wyniku: No vhost created (no domain given)). Zdarza się to tylko przy profilu „Skonfigurowany serwer”, gdy domena nie została przekazana. Najprościej jest po prostu uruchomić ponownie polecenie z panelu, podając domenę:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo bash -s -- monitor.example.com

Ponowne uruchomienie jest bezpieczne: to, co już zrobiono, nie zostanie zdublowane. Jeśli jednak vhost trzeba utworzyć ręcznie — oto ta sama konfiguracja, którą zapisuje instalator:

sudo mkdir -p /var/www/monitor # Gniazdo PHP-FPM wykrywamy automatycznie — wersja PHP bywa różna na różnych serwerach. PHPSOCK=$(ls -1 /run/php/php*-fpm.sock 2>/dev/null | head -1) sudo tee /etc/apache2/sites-available/arciveo-monitor.conf > /dev/null <<'EOF' <VirtualHost *:80> ServerName monitor.example.com DocumentRoot /var/www/monitor <Directory /var/www/monitor> Options -Indexes +FollowSymLinks AllowOverride All Require all granted </Directory> <FilesMatch "\.php$"> SetHandler "proxy:unix:__PHPSOCK__|fcgi://localhost" </FilesMatch> ErrorLog ${APACHE_LOG_DIR}/arciveo-monitor_error.log CustomLog ${APACHE_LOG_DIR}/arciveo-monitor_requests.log combined </VirtualHost> EOF sudo sed -i "s#__PHPSOCK__#${PHPSOCK}#" /etc/apache2/sites-available/arciveo-monitor.conf sudo a2ensite arciveo-monitor.conf sudo apache2ctl configtest sudo systemctl reload apache2

ServerName jest tutaj obowiązkowy. Vhost bez nazwy staje się domyślną witryną Apache i zaczyna odpowiadać za cudze domeny na tym samym serwerze. Z tego samego powodu proszę nie wyłączać 000-default.conf na skonfigurowanym serwerze: ta witryna mogła zostać przerobiona na czyjąś produkcyjną — na świeżym VPS instalator usuwa ją sam, tutaj nie trzeba tego robić.

Jeśli przed Apache stoi Nginx (w wyniku: ! Nginx does not read .htaccess). Nginx wydaje pliki statyczne wprost z dysku i nie czyta .htaccess — katalogi służbowe będą otwarte na zewnątrz, choć Apache zamyka je poprawnie. Skrypt przygotował z wyprzedzeniem plik z zakazami; trzeba go dołączyć w bloku server{} Pana/Pani witryny i przeładować Nginx:

include /etc/nginx/snippets/arciveo-deny.conf;

sudo nginx -t && sudo systemctl reload nginx # Sprawdzenie: powinno zwrócić 403, a nie zawartość pliku curl -sI https://monitor.example.com/config.php | head -1

Pliki panelu (archiwum dystrybucyjne) pobiera się po zakupie w panelu klienta my.arciveo.com → „Pobrania”. Rozpakuj archiwum przed wgraniem na serwer.

Wgraj zawartość dystrybucji do /var/www/monitor (aby w środku znalazły się public/, assets/, config.php itd.) — przez SFTP/SCP (FileZilla / WinSCP) lub poleceniem scp z komputera lokalnego:

scp -r ./monitor/* deploy@203.0.113.10:/var/www/monitor/

Aby w vhoście od razu zapisał się Pana domena (ServerName), przekazuje się ją do polecenia autokonfiguracji już w kroku 01: … | sudo bash -s -- monitor.example.com (lub podaje domenę w polu „Domena panelu” w panelu klienta). Jeśli domena nie została przekazana — panel odpowiada na dowolny host oraz po IP, a ServerName zapisze certbot przy wydawaniu SSL (krok 06); nie trzeba niczego przeinstalowywać.

Ustaw uprawnienia plików — to krok obowiązkowy. Jeśli wgrywano pliki jako root lub przez SFTP, należą one do root, a serwer WWW (www-data) nie będzie mógł ich odczytać — panel otworzy się pusty lub z błędem 403 (w logu: .htaccess unreadable / directory not executable). Poniższe polecenie to naprawia:

# Normalizujemy uprawnienia całego webroota: katalog utworzony przez root jest niedostępny # dla serwera WWW (www-data) — bez tego panel oddaje pustą stronę lub 403. cd /var/www/monitor # Katalogi robocze tworzymy PRZED chown — inaczej nowe katalogi pozostaną root:root # i przy chmod 750 serwer WWW (www-data) nie będzie mógł w nich zapisywać. sudo mkdir -p data/lynis data/logwatch tmp logs sudo chown -R www-data:www-data /var/www/monitor sudo find /var/www/monitor -type d -exec chmod 755 {} \; sudo find /var/www/monitor -type f -exec chmod 644 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 750 data tmp logs

Proszę otworzyć sobie wgrywanie plików przez SFTP. Po powyższym poleceniu wszystkie pliki należą do www-data, a FileZilla / WinSCP łączą się na własnym użytkowniku — wgrywanie zakończy się wtedy błędem SSH_FX_PERMISSION_DENIED (Permission denied). Proszę wybrać jeden z dwóch wariantów.

Wariant A — ACL tylko dla własnego użytkownika (zalecany). Prawo zapisu otrzymuje wyłącznie użytkownik; serwer WWW nadal nie może nadpisać kodu panelu:

sudo apt install -y acl # Prawo zapisu dla własnego użytkownika do całego katalogu panelu: sudo setfacl -R -m u:deploy:rwX /var/www/monitor # Ta sama reguła domyślnie — dla plików i katalogów utworzonych później: sudo setfacl -R -d -m u:deploy:rwX /var/www/monitor

Wariant B — przez grupę www-data. Prostszy, ale prawo zapisu do plików panelu dostaje również serwer WWW: przy podatności w PHP kod dałoby się podmienić. Kolejność poleceń ma znaczenie — config.php i katalogi robocze zamyka się na końcu:

sudo usermod -aG www-data deploy # Zapis dla grupy + setgid (bit 2): pliki wgrane przez SFTP pozostają # w grupie www-data — inaczej panel nie będzie mógł ich nadpisać. sudo find /var/www/monitor -type d -exec chmod 2775 {} \; sudo find /var/www/monitor -type f -exec chmod 664 {} \; sudo chmod 640 /var/www/monitor/config.php sudo chmod 2750 /var/www/monitor/data /var/www/monitor/tmp /var/www/monitor/logs

Po wariancie B proszę połączyć się ponownie w FileZilli (Serwer → Rozłącz, następnie zalogować się na nowo) — nowa grupa działa dopiero przy nowym logowaniu, wcześniej uprawnień nadal nie będzie. Sprawdzenie: id deploy — na liście grup musi pojawić się www-data; ls -ld /var/www/monitor — uprawnienia drwxrwsr-x, litera s zamiast x oznacza, że setgid jest ustawiony.

04. Baza danych

Proszę utworzyć bazę i użytkownika, a następnie zaimportować schemat. Blok z bazą danych wkleja się do terminala w całości (sudo mysql loguje root przez gniazdo unix — hasło root nie jest potrzebne). monitor_db i monitor_user to nazwy przykładowe, można ustawić własne; proszę zapamiętać nazwę bazy, użytkownika i hasło — trzeba je będzie wpisać w config.php w następnym kroku:

# 1. Baza danych. Nazwa bazy, użytkownik i hasło ustawiane są RAZ poniżej i podstawiane do wszystkich linii. # Blok wkleja się do terminala W CAŁOŚCI; sudo mysql loguje root przez gniazdo unix # (hasło root nie jest potrzebne). NIE używaj interaktywnego `sudo mysql -u root -p` # z wklejaniem — przy wklejaniu linie SQL trafią do zapytania o hasło i przepadną. DBNAME='monitor_db' # ← nazwa bazy, można zostawić DBUSER='monitor_user' # ← użytkownik bazy, można zostawić DBPASS='CHOOSE_A_PASSWORD' # ← hasło, ustaw własne sudo mysql <<SQL CREATE DATABASE IF NOT EXISTS $DBNAME CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS '$DBUSER'@'localhost' IDENTIFIED BY '$DBPASS'; GRANT ALL ON $DBNAME.* TO '$DBUSER'@'localhost'; FLUSH PRIVILEGES; SQL # Sprawdzenie (powinno pokazać $DBNAME): mysql -u "$DBUSER" -p"$DBPASS" -e "SHOW DATABASES;" # Te same trzy wartości wpisz w config.php → DB_NAME, DB_USER, DB_PASS.

Zwykle schematu nie trzeba importować — panel sam tworzy tabele i konto admin przy pierwszym wejściu w przeglądarce (z database/db.sql), jeśli baza jest pusta.

Jeśli tabele nie powstały (panel pokazuje błąd połączenia z bazą lub pusty ekran zamiast formularza logowania) — proszę zaimportować schemat ręcznie. Polecenie wykonuje się w katalogu głównym panelu, wartości pochodzą z bloku powyżej:

# Import schematu: cd /var/www/monitor && mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" < database/db.sql # Sprawdzenie — powinna pojawić się lista tabel: mysql -u "$DBUSER" -p"$DBPASS" "$DBNAME" -e "SHOW TABLES;"

Jeśli zmienne $DBNAME / $DBUSER / $DBPASS zostały już „zapomniane” (nowa sesja terminala) — proszę wstawić wartości do polecenia ręcznie albo ustawić je ponownie tymi samymi trzema wierszami z bloku powyżej.

sudo dla serwera WWW. Zwykle reguły są już zapisane przez automatyczną konfigurację i moduły od razu widzą dane systemowe. Jeśli jednak w wyniku skryptu pojawił się wiersz sudo rules NOT written — nie było na czym ustalić konta panelu (pliki nie były jeszcze wgrane) i reguły nie zostały utworzone. Bez nich sekcje takie jak zapora, Fail2ban czy CrowdSec pozostaną puste. Teraz, gdy pliki są na miejscu, proszę uruchomić polecenie z panelu jeszcze raz, wskazując konto wprost:

curl -fsSL "https://my.arciveo.com/install.php?token=YOUR_TOKEN&profile=existing" | sudo ARCIVEO_USER=www-data bash -s -- monitor.example.com

www-data proszę zastąpić użytkownikiem, na którym działa PHP Pana/Pani witryny (w panelu hostingowym jest to zwykle właściciel domeny). Można go sprawdzić tak:

ps -o user= -C php-fpm8.3 | sort -u # wersję proszę podstawić własną # lub: ps aux | grep -m3 '[p]hp-fpm'

Sprawdzenie po ponownym uruchomieniu: plik /etc/sudoers.d/monitor istnieje i zawiera wiersze z Pana/Pani użytkownikiem.

05. Konfiguracja config.php

config.php w katalogu głównym panelu (/var/www/monitor/config.php) to jedyny plik, który trzeba edytować ręcznie. Wszystkie ustawienia panelu są w nim zapisane jako stałe define(). Proszę otworzyć go w edytorze:

sudo nano /var/www/monitor/config.php

Proszę wstawić własne wartości w podświetlonych miejscach; resztę zostawić bez zmian:

// --- Baza danych (z kroku 04) --- define('DB_HOST', 'localhost'); // zostawić define('DB_NAME', 'db_name'); // co utworzono w kroku 04 define('DB_USER', 'user'); // co utworzono w kroku 04 define('DB_PASS', 'db_password'); // co ustawiono w kroku 04 define('DB_CHARSET', 'utf8mb4'); // zostawić // --- Aplikacja --- define('APP_URL', 'https://monitor.example.com'); // adres panelu, bez ukośnika na końcu define('TIMEZONE', 'Europe/Warsaw'); // Pana/Pani strefa czasowa // --- Czas sesji --- define('SESSION_LIFETIME', 28800); // bezczynność do ponownego logowania, s (28800 = 8 h)

Co zmienić:

DB_NAME, DB_USER, DB_PASS — dokładnie te same nazwa bazy, użytkownik i hasło, które ustawiono podczas tworzenia bazy w kroku 04 (jeśli pozostawiono przykłady — monitor_db / monitor_user). DB_HOST i DB_CHARSET proszę pozostawić.
APP_URL — pełny adres panelu z https://, bez ukośnika na końcu i bez www. Musi być zgodny z domeną, na której aktywuje się licencję (krok 07), inaczej klucz zostanie odrzucony.
TIMEZONE — Pana/Pani strefa czasowa (lista — timedatectl list-timezones). Wpływa tylko na to, jak panel wyświetla daty; na czas uruchamiania zadań cron nie wpływa (tam obowiązuje strefa systemowa).
SESSION_LIFETIME — po ilu sekundach bezczynności panel poprosi o ponowne logowanie (domyślnie 8 godzin). Np. 3600 = 1 godzina, 86400 = doba.
Blok logowania błędów (display_errors, log_errors, error_log) — proszę zostawić domyślnie.

Proszę zapisać plik (Ctrl+O, Enter, następnie Ctrl+X) i zrestartować PHP-FPM — inaczej z powodu OPcache zmiany nie zostaną zastosowane:

sudo systemctl restart php*-fpm

config.php to plik tajny (zawiera hasło bazy danych). Znajduje się w katalogu głównym panelu, który jest zarazem katalogiem głównym witryny, ale jest zabezpieczony: prawa 640 (ustawione w kroku 03) i jawny zakaz w głównym .htaccess. Proszę nie publikować go w publicznych repozytoriach ani nie przesyłać do wsparcia z prawdziwym hasłem.

Szczegółowe omówienie wszystkich parametrów — w FAQ: „Plik config.php — wszystkie ustawienia panelu”.

06. Wystaw certyfikat SSL (HTTPS)

Panel działa wyłącznie po HTTPS. Sesja logowania korzysta z zabezpieczonego pliku cookie, a WebAuthn (2FA) zgodnie ze standardem działa tylko po HTTPS. Po http:// nie uda się Panu zalogować.

Na serwerze z panelem hostingowym ten krok nie jest potrzebny (w wyniku skryptu: Certbot skipped — issue SSL in …). Certyfikat wydaje się przełącznikiem Let's Encrypt na domenie WWW w samym panelu — dzięki temu panel zajmuje się też jego odnawianiem.

certbot oraz wtyczka dla Apache są już zainstalowane przez autokonfigurację. DNS domeny powinien już wskazywać na serwer (krok 02). Wystawienie jedną komendą:

sudo certbot --apache -d monitor.example.com

Jeśli panel ma otwierać się także z przedrostkiem www. — proszę wymienić obie nazwy w jednym poleceniu, inaczej pod drugim adresem przeglądarka pokaże ostrzeżenie o certyfikacie:

sudo certbot --apache -d monitor.example.com -d www.monitor.example.com

Drugą nazwę proszę dodawać tylko wtedy, gdy również dla niej istnieje rekord A wskazujący na ten serwer (krok 02). W przeciwnym razie Let's Encrypt nie zdoła jej zweryfikować i nie wyda certyfikatu w całości — łącznie z domeną główną.

O co zapyta certbot:

Enter email address — Pana e-mail (tam przyjdą powiadomienia o wygaśnięciu certyfikatu).
Terms of Service … (Y)es/(N)o — Y.
Share email with the EFF … (Y)es/(N)o — według uznania.

Dalej certbot sam wystawi certyfikat, wpisze <VirtualHost *:443>, skonfiguruje przekierowanie http→https i automatyczne odnawianie. Na końcu — Successfully enabled HTTPS.

Jeśli wystawienie się nie powiedzie — proszę sprawdzić, czy dig +short monitor.example.com zwraca IP serwera i czy porty 80/443 są otwarte (sudo ufw allow 80,443/tcp).

Po wystawieniu: https://monitor.example.com otwiera się z kłódką, a http:// przekierowuje na https://.

07. Logowanie i konfiguracja początkowa

Proszę otworzyć https://monitor.example.com, zalogować się jako admin / useradmin i przejść przez listę kontrolną:

Zmienić hasło admin — sekcja „Użytkownicy” w menu.
Włączyć WebAuthn (2FA) — „Klucze WebAuthn” → zarejestrować klucz/passkey (wymaga HTTPS). Proszę od razu zarejestrować dwa: w razie utraty jedynego klucza logowanie za jego pomocą będzie niemożliwe. Więcej.
Ograniczyć dostęp według IP — „Ustawienia” → „Ograniczenie dostępu według IP” (proszę wpisać swój IP przed włączeniem, inaczej zablokuje Pan sobie dostęp).
Wprowadzić licencję — kod aktywacyjny ARCIVEO-… z panelu klienta proszę aktywować na swoją domenę i wkleić klucz w „Ustawienia” → „Licencja”. Więcej.
Skonfigurować powiadomienia — Telegram i/lub Email w „Ustawieniach”. Więcej.
Usunąć instalator public/start_db.php, jeśli pozostał: pozwala on bez autoryzacji odtworzyć bazę. Dopóki plik znajduje się w katalogu głównym panelu lub w public/, panel ostrzega o nim czerwonym banerem.
Uruchomić pierwsze kontrole ręcznie — inaczej część sekcji pozostanie pusta do nocy (patrz blok poniżej).

Dlaczego „Audyt Lynis” i „Logwatch” są od razu puste. Autokonfiguracja zainstalowała narzędzia i założyła zadania cron, ale nie uruchamiała samych kontroli — pójdą one zgodnie z harmonogramem: Lynis o 03:00, Logwatch o 06:00, debsums o 04:30, ClamAV o 01:30. Do tego momentu sekcje uczciwie pokazują, że raportów jeszcze nie ma. Aby nie czekać doby, proszę przepuścić je raz ręcznie:

# Audyt Lynis — pierwszy raport (kilka minut): sudo /usr/local/bin/lynis-scan.sh # Raport Logwatch za dobę: sudo /usr/local/bin/logwatch_daily.sh # Integralność pakietów (debsums) — na dużym serwerze trwa długo: sudo /usr/local/bin/debsums-scan.sh

Lynis można uruchomić także wprost z panelu — przycisk „Uruchom audyt” na stronie „Audyt Lynis”: wykonuje on ten sam skrypt w tle i sam odświeża raport. Dalej wszystko idzie zgodnie z harmonogramem, ręcznie nie trzeba już nic uruchamiać.

Pierwsze skanowanie antywirusowe (sudo /usr/local/bin/clamav-scan.sh) mocno obciąża dysk i procesor i może trwać godzinę lub dłużej — na działającym serwerze lepiej poczekać na nocne uruchomienie o 01:30. Sekcje „Dyski (SMART)”, „Wydajność” i „Aktualizacje zabezpieczeń” zapełniają się same: odpowiednio co 30 minut, co 5 minut i raz na godzinę.

Gotowe. Informacje o każdym narzędziu znajdują się w FAQ.

Jeśli na tym serwerze potrzebna jest jeszcze jedna witryna z własną domeną — patrz FAQ: „Druga witryna na tym serwerze (kolejna domena)”.

Wybór metody Przewodnik FAQ