Automatikus módszer: a fiókból elérhető egyetlen szkript előkészíti az egész szervert (Apache + PHP webes réteg, adatbázis, biztonsági eszközök, cron). Ezután már csak telepíteni kell a panelt, kiállítani az SSL-t és megadni a licencet. Működik Ubuntu/Debian alatt: friss VPS-en mindent a nulláról állít be, egy már beállított szerveren pedig csak kiegészítő módon (a „Beállított szerver” profil, 01. lépés). Az alábbi parancsok sorrendben követik egymást, csak lapozzon fentről lefelé. Friss VPS-en minden lépés sorban alkalmazható; ha a szerver már be van állítva, vagy hosztingpanel van rajta, a munka egy részét a szkript szándékosan Önre hagyja — hogy pontosan mit, azt a futása végén kiírja (a kimenet értelmezése a 01. lépésben található).
monitor.example.com — az Ön domainje; 203.0.113.10 — a szerver valódi IP-címe; /var/www/monitor — a panel gyökere (ahol a public/, assets/, config.php található); az adatbázis jelszavát találja ki saját maga.
jail.local), root-crontab, UFW-szabályok, Apache-konfiguráció. Ha a szerver már be van állítva (működő panel, weboldalak, levelezés, saját jailek) — válassza a „Beállított szerver” profilt: ez csak kiegészítő módosításokat végez, és nem nyúl az Ön tűzfalához, a Fail2banhez, a levelezéshez, az SSH-hoz és a sysctl-hez. Hosztingpanel észlelése esetén a szkript magától erre a módra vált. Az első futtatás előtt bekapcsolhatja a szárazpróbát (jelölőnégyzet a fiókban) — ez megmutatja, mi történne, anélkül hogy bármit megváltoztatna. Éles szerveren a biztonság kedvéért készítsen pillanatképet (snapshot).
my.arciveo.com → „Szerver beállítása” szakasz (az Arcivéo Security Monitor megrendelése után érhető el). A fiókjához van kötve, és személyes tokent tartalmaz.
A szkript az egész szervert előkészíti: webes réteg (Apache + PHP), adatbázis, SSL-eszközök, a teljes védelmi eszközkészlet és a cron-feladatok (Lynis, SMART, debsums, Logwatch, napi jelentés, ipsum frissítése).
1) Válassza ki a védelmi szintet (a fiókban, a parancs másolása előtt):
2) Futtassa a szerveren root alatt a fiókból származó parancsot — így néz ki:
3) Olvassa el a kimenetet a végén — ott áll, mi maradt Önre. A szkript egy ellenőrzési blokkal és a „Következő lépés — a panel telepítése” listával zárja a munkát. Egyes lépéseket szándékosan nem végez el: hogy pontosan melyeket, az a választott profiltól és attól függ, mit talált a szerveren. Vesse össze az alábbi listával — csak azokat a pontokat kell elvégeznie, amelyek sorai megjelentek az Ön kimenetében.
Control panel detected (…) — a webhely magának a hosztingpanelnek az eszközeivel jön létre, vhostot a szkript nem hoz létre. 03. lépés, „Hosztingpanellel rendelkező szerver” ág.No vhost created (no domain given) — a „Beállított szerver” profil domain nélkül: a név nélküli vhost alapértelmezett webhellyé válna, és elfogná az Ön saját webhelyeit, ezért nem jött létre. 03. lépés, „Vhost létrehozása kézzel” ág.sudo rules NOT written — a szkript nem tudta megállapítani, melyik fiók alatt fut a panel. Ez szokásos helyzet: a panel fájljai már az automatikus beállítás után kerülnek fel, így még nem volt miből meghatározni. E szabályok nélkül a modulok nem látják a rendszeradatokat. 04. lépés, „A webszerver sudo-ja” blokk.! Nginx does not read .htaccess — az Apache előtt Nginx áll, és a tiltás beírása annak konfigurációjába automatikusan nem sikerült. Ezt mindenképpen végezze el: különben a data/, keys/, database/ és a config.php a .htaccess megkerülésével kifelé is elérhető lesz. 03. lépés, „Ha az Apache előtt Nginx áll” blokk.UFW installed but inactive — a tűzfal telepítve van, de ki van kapcsolva: beállított szerveren a szkript nem kapcsolja be magától, nehogy elvágja Öntől a hozzáférést. Kapcsolja be saját maga, mindenképpen engedélyezve a saját SSH-portját:
Fail2ban installed but not running — indítsa el: sudo systemctl enable --now fail2ban.Database server present … but not running — indítsa el az adatbázis-kiszolgálót a 04. lépés előtt: sudo systemctl enable --now mariadb (vagy mysql — attól függően, melyik van telepítve).Certbot skipped — issue SSL in … — a tanúsítványt a hosztingpanel Let's Encrypt kapcsolója állítja ki; a 06. lépésre nincs szüksége.All checks passed. A ! jellel megjelölt pontok figyelmet igényelnek; a részletek a naplóba kerülnek, amelynek elérési útját a szkript a legvégén kiírja (Log: …).
Ahhoz, hogy a dashboardot egy monitor.example.com típusú címen nyithassa meg, és ingyenes SSL-t kapjon, a domainnek a szerverre kell mutatnia. A DNS vezérlőpultján (a regisztrátornál vagy a tárhelyszolgáltatónál) hozzon létre egy A-rekordot:
Néhány perc múlva (néha akár egy óra is lehet) ellenőrizze, hogy a domain a szerverre mutat-e:
/var/www/monitor könyvtárát, és beállította az Apache-oldalt (DocumentRoot a panel gyökerén, PHP-FPM, AllowOverride a .htaccess számára). A szkript kimenetében ez a vhost … → DocumentRoot … sor. Külön nem kell könyvtárat és vhostot létrehozni — csak töltse fel a fájlokat és állítsa be a jogosultságokat.
„Hosztingpanellel rendelkező szerver” ág (a kimenetben: Control panel detected (…)). Ilyen szerveren a webhelyekkel a panel rendelkezik, és a szkript szándékosan nem hoz létre saját vhostot — azt a panel az első konfigurációújragenerálásnál felülírná. A sorrend a következő:
public_html könyvtárába: az index.php, api/, assets/ mellett ott kell lennie a szolgáltatási config.php, includes/, data/, tmp/, logs/, keys/, cron/, database/ elemeknek is. Semmit sem kell a webgyökér fölé kiemelni: a szolgáltatási mappákat a disztribúció .htaccess fájlja zárja le, Nginx alatt pedig az a tiltás, amelyet a szkript beírt a domain konfigurációjába.config.php (05. lépés). A parancsokban az útvonalakat cserélje erre: /home/fiók/web/domain/public_html, a tulajdonost pedig www-data helyett ennek a domainnek a felhasználójára.„Vhost létrehozása kézzel” ág (a kimenetben: No vhost created (no domain given)). Ez csak a „Beállított szerver” profilnál fordul elő, amikor a domaint nem adták át. A legegyszerűbb megoldás: futtassa újra a fiókból származó parancsot, immár a domaint megadva:
Az ismételt futtatás biztonságos: a már elvégzett munka nem duplázódik. Ha viszont a vhostot kézzel kell létrehozni — itt van ugyanaz a konfiguráció, amelyet a telepítő ír ki:
ServerName itt kötelező. A név nélküli vhost az Apache alapértelmezett webhelyévé válik, és elkezd válaszolni az ugyanezen a szerveren lévő idegen domainek helyett is. Ugyanezért ne kapcsolja ki a 000-default.conf fájlt beállított szerveren: ezt a webhelyet átalakíthatták valaki éles oldalává — friss VPS-en a telepítő magától eltávolítja, itt viszont ezt nem kell megtennie.
! Nginx does not read .htaccess). Az Nginx a statikus fájlokat közvetlenül a lemezről adja ki, és a .htaccess fájlt nem olvassa — így a szolgáltatási mappák kifelé nyitva maradnak, jóllehet az Apache helyesen lezárja őket. A szkript előre elkészítette a tiltásokat tartalmazó fájlt; ezt az Ön webhelyének server{} blokkjában kell beilleszteni, majd újra kell tölteni az Nginxet:
my.arciveo.com → „Letöltések”. Csomagolja ki az archívumot, mielőtt feltöltené a szerverre.
Töltse fel a disztribúció tartalmát ide: /var/www/monitor (hogy belül legyen a public/, assets/, config.php stb.) — SFTP/SCP-n keresztül (FileZilla / WinSCP), vagy a helyi gépről a scp paranccsal:
ServerName), azt már a 01. lépésben átadják az automatikus beállítás parancsának: … | sudo bash -s -- monitor.example.com (vagy megadják a domaint a fiókban a „Panel domainje” mezőben). Ha nem adta át a domaint — a panel bármely hoszton és IP-címen válaszol, a ServerName értéket pedig a certbot írja be az SSL kiállításakor (06. lépés); semmit sem kell újratelepíteni.
root alatt vagy SFTP-n keresztül töltötte fel, a fájlok a root tulajdonában vannak, és a webszerver (www-data) nem tudja olvasni őket — a panel üresen vagy 403-as hibával nyílik meg (a logban: .htaccess unreadable / directory not executable). Az alábbi parancs ezt javítja:
Nyissa meg magának a fájlfeltöltést SFTP-n. A fenti parancs után minden fájl a www-data tulajdonában van, miközben a FileZilla / WinSCP a saját felhasználójával csatlakozik — a feltöltés ekkor SSH_FX_PERMISSION_DENIED (Permission denied) hibával áll le. Válasszon a két változat közül.
A változat — ACL csak a saját felhasználójának (ajánlott). Írási jogot csak Ön kap; a webszerver továbbra sem tudja felülírni a panel kódját:
B változat — a www-data csoporton keresztül. Egyszerűbb, de a panel fájljaira a webszerver is írási jogot kap: PHP-sebezhetőség esetén a kód lecserélhető lenne. A parancsok sorrendje számít — a config.php és a munkamappák zárása marad a végére:
id deploy — a csoportok listájában meg kell jelennie a www-data csoportnak; ls -ld /var/www/monitor — jogok drwxrwsr-x, az x helyén álló s betű azt jelenti, hogy a setgid be van állítva.
Hozzon létre egy adatbázist és egy felhasználót, majd importálja a sémát. Az adatbázis-blokkot egészben illessze be a terminálba (a sudo mysql root felhasználóként lép be unix-socketen keresztül — a root jelszava nem szükséges). A monitor_db és a monitor_user csak példaértékek, tetszőleges nevet megadhat; jegyezze meg az adatbázis nevét, a felhasználót és a jelszót — ezeket a következő lépésben beírja a config.php fájlba:
admin fiókot (a database/db.sql alapján), ha az adatbázis üres.
Ha a táblák mégsem jöttek létre (a panel adatbázis-kapcsolati hibát vagy üres képernyőt mutat a bejelentkezési űrlap helyett) — importálja a sémát kézzel. A parancsot a panel gyökerében kell futtatni, az értékek a fenti blokkból származnak:
$DBNAME / $DBUSER / $DBPASS változók már „elfelejtődtek” (új terminál-munkamenet) — írja be az értékeket kézzel a parancsba, vagy adja meg őket újra a fenti blokk ugyanazon három sorával.
sudo rules NOT written sor — a panel fiókját nem volt miből meghatározni (a fájlok még nem voltak feltöltve), és a szabályok nem jöttek létre. Nélkülük az olyan szakaszok, mint a tűzfal, a Fail2ban és a CrowdSec, üresek maradnak. Most, hogy a fájlok a helyükön vannak, futtassa újra a fiókból származó parancsot, a fiókot kifejezetten megnevezve:
www-data helyére azt a felhasználót írja, amely alatt az Ön webhelyének PHP-ja fut (hosztingpanelen ez rendszerint a domain tulajdonosa). Így nézheti meg:
/etc/sudoers.d/monitor fájl létezik, és vannak benne az Ön felhasználóját tartalmazó sorok.
A panel gyökerében lévő config.php (/var/www/monitor/config.php) az egyetlen fájl, amelyet kézzel kell szerkeszteni. A panel minden beállítása define() konstansként szerepel benne. Nyissa meg egy szerkesztőben:
Írja be a saját értékeit a kiemelt helyekre; a többit hagyja változatlanul:
Mit kell módosítani:
DB_NAME, DB_USER, DB_PASS — pontosan ugyanaz az adatbázisnév, felhasználó és jelszó, amelyet az adatbázis létrehozásakor a 04. lépésben megadott (ha a példákat hagyta: monitor_db / monitor_user). A DB_HOST és DB_CHARSET értékét ne módosítsa.APP_URL — a panel teljes címe https:// előtaggal, záró perjel nélkül és www nélkül. Egyeznie kell azzal a domainnel, amelyre a licencet aktiválja (07. lépés), különben a kulcsot elutasítja a rendszer.TIMEZONE — az Ön időzónája (a lista: timedatectl list-timezones). Csak azt befolyásolja, hogyan jeleníti meg a panel a dátumokat; a cron-feladatok indítási idejét nem befolyásolja (ott a rendszer időzónája érvényes).SESSION_LIFETIME — hány másodperc tétlenség után kéri a panel az újbóli belépést (alapértelmezetten 8 óra). Pl. 3600 = 1 óra, 86400 = egy nap.display_errors, log_errors, error_log) hagyja az alapértelmezetten.Mentse el a fájlt (Ctrl+O, Enter, majd Ctrl+X), és indítsa újra a PHP-FPM-et — különben az OPcache miatt a módosítások nem lépnek életbe:
640 jogosultság (a 03. lépésben beállítva) és explicit tiltás a gyökér .htaccess fájljában. Ne töltse fel nyilvános tárolókba, és ne küldje el a támogatásnak valós jelszóval.
http:// protokollon nem tud bejelentkezni.
Certbot skipped — issue SSL in …). A tanúsítványt magának a panelnek a webdomainjén a Let's Encrypt kapcsoló állítja ki — így a megújításáról is a panel gondoskodik.
A certbot és az Apache-bővítmény már telepítve van az automatikus beállítás során. A domain DNS-ének már a szerverre kell mutatnia (02. lépés). Kiállítás egyetlen paranccsal:
Ha a panelnek a www. előtaggal is meg kell nyílnia — sorolja fel mindkét nevet egyetlen parancsban, különben a második címen a böngésző tanúsítvány-figyelmeztetést jelenít meg:
Y.<VirtualHost *:443> bejegyzést, beállítja a http→https átirányítást és az automatikus megújítást. A végén: Successfully enabled HTTPS.
dig +short monitor.example.com visszaadja-e a szerver IP-címét, és nyitva vannak-e a 80/443 portok (sudo ufw allow 80,443/tcp).
A kiállítás után: a https://monitor.example.com lakat ikonnal nyílik meg, a http:// pedig https://-re irányít át.
Nyissa meg a https://monitor.example.com címet, jelentkezzen be a admin / useradmin adatokkal, és haladjon végig az ellenőrzőlistán:
ARCIVEO-… aktiválási kódot aktiválja a saját domainjére, majd illessze be a kulcsot a „Beállítások” → „Licenc” menüpontba. Részletek.public/start_db.php, ha megmaradt: ez engedélyezés nélkül újra tudja hozni az adatbázist. Amíg a fájl a panel gyökerében vagy a public/ mappában van, a panel piros szalaggal figyelmeztet rá.sudo /usr/local/bin/clamav-scan.sh) erősen terheli a lemezt és a processzort, és akár egy óránál is tovább tarthat — éles szerveren érdemes megvárni az éjszakai, 01:30-as indítást. A „Lemezek (SMART)”, a „Teljesítmény” és a „Biztonsági frissítések” szakasz magától töltődik fel: 30 percenként, 5 percenként, illetve óránként.