Automatisk metode: ett skript fra kontoen din klargjør hele serveren (webstakk Apache + PHP, database, sikkerhetsverktøy, cron). Deretter — sett opp dashbordet, utsted SSL og legg inn lisensen. Fungerer på Ubuntu/Debian: på en fersk VPS settes alt opp fra bunnen av, på en allerede konfigurert server — kun additivt (profilen «Konfigurert server», trinn 01). Alle kommandoene nedenfor er i rekkefølge, bare bla ovenfra og ned. På en fersk VPS passer hvert trinn på rad; er serveren allerede konfigurert, eller står det et hostingpanel på den, lar skriptet bevisst en del av arbeidet stå igjen til deg — hva det gjelder, skriver det til slutt i kjøringen (gjennomgang av utskriften finner du i trinn 01).
monitor.example.com — ditt domene; 203.0.113.10 — serverens faktiske IP; /var/www/monitor — dashbordets rot (der public/, assets/, config.php ligger); finn på ditt eget DB-passord.
jail.local), root-crontab, UFW-regler, Apache-konfig. Hvis serveren allerede er konfigurert (fungerende dashbord, nettsteder, e-post, egne jail-er) — velg profilen «Konfigurert server»: den gjør kun additive endringer og rører ikke brannmuren, Fail2ban, e-posten, SSH eller sysctl. Oppdager skriptet en hostingpanel, bytter det til denne modusen selv. Før første kjøring kan du slå på tørrkjøring (avkryssing på kontoen) — den viser hva som vil bli gjort, uten å endre noe. På en produksjonsserver bør du for sikkerhets skyld ta et øyeblikksbilde (snapshot).
my.arciveo.com → seksjonen «Serveroppsett» (tilgjengelig etter at Arcivéo Security Monitor er tegnet). Den er knyttet til kontoen din og inneholder et personlig token.
Skriptet klargjør hele serveren: web-stack (Apache + PHP), database, verktøy for SSL, hele settet med sikkerhetsverktøy og cron-jobber (Lynis, SMART, debsums, Logwatch, daglig rapport, oppdatering av ipsum).
1) Velg beskyttelsesnivå (på kontoen, før du kopierer kommandoen):
2) Kjør på serveren som root kommandoen fra kontoen — den ser slik ut:
3) Les utskriften til slutt — der står det hva som gjenstår for deg. Skriptet avslutter kjøringen med en blokk med kontroller og en liste «Videre — installasjon av panelet». En del trinn gjør det bevisst ikke: hva det gjelder, avhenger av valgt profil og av hva det fant på serveren. Sjekk mot listen nedenfor — du trenger bare å utføre de punktene hvis linjer dukket opp i din utskrift.
Control panel detected (…) — nettstedet opprettes med hostingpanelets egne verktøy, skriptet lager ikke vhost. Trinn 03, grenen «Server med hostingpanel».No vhost created (no domain given) — profilen «Konfigurert server» uten domene: en vhost uten navn ville blitt standardnettstedet og fanget opp dine egne nettsteder, derfor er den ikke opprettet. Trinn 03, grenen «Opprette vhost manuelt».sudo rules NOT written — skriptet klarte ikke å avgjøre hvilken konto panelet kjører under. Dette er en helt vanlig situasjon: panelets filer lastes opp først etter det automatiske oppsettet, og det var ennå ikke noe å avgjøre det ut fra. Uten disse reglene ser ikke modulene systemdataene. Trinn 04, blokken «sudo for webserveren».! Nginx does not read .htaccess — det står en Nginx foran Apache, og forbudet lot seg ikke skrive inn i konfigurasjonen dens automatisk. Gjør dette absolutt: ellers leveres data/, keys/, database/ og config.php ut utenfra, utenom .htaccess. Trinn 03, blokken «Hvis det står en Nginx foran Apache».UFW installed but inactive — brannmuren er installert, men avslått: på en konfigurert server slår skriptet den ikke på selv, for ikke å stenge deg ute. Slå den på selv, og pass på å åpne din egen SSH-port:
Fail2ban installed but not running — start den: sudo systemctl enable --now fail2ban.Database server present … but not running — start databaseserveren før trinn 04: sudo systemctl enable --now mariadb (eller mysql — alt etter hva som er installert).Certbot skipped — issue SSL in … — sertifikatet utstedes med Let's Encrypt-bryteren i hostingpanelet; trinn 06 trenger du ikke.All checks passed. Punkter med ! krever oppmerksomhet; detaljene skrives til loggen, og stien til den skriver skriptet helt til slutt (Log: …).
For å åpne dashbordet på en adresse som monitor.example.com og få gratis SSL, må domenet peke til serveren. I DNS-kontrollpanelet (hos registraren eller webverten) oppretter du en A-oppføring:
Etter noen minutter (av og til opptil en time) sjekker du at domenet peker til serveren:
/var/www/monitor og satt opp Apache-nettstedet (DocumentRoot til panelroten, PHP-FPM, AllowOverride for .htaccess). I utskriften fra skriptet er dette linjen vhost … → DocumentRoot …. Du trenger ikke opprette katalog og vhost separat — bare last opp filene og sett rettighetene.
Grenen «Server med hostingpanel» (i utskriften: Control panel detected (…)). Nettstedene på en slik server styres av panelet, og skriptet oppretter bevisst ikke sin egen vhost — den ville blitt overskrevet ved den første beste gjenoppbyggingen av konfigurasjonene fra panelet. Fremgangsmåten er slik:
public_html for dette domenet: ved siden av index.php, api/, assets/ skal også de interne config.php, includes/, data/, tmp/, logs/, keys/, cron/, database/ ligge. Ingenting trenger å flyttes over webroten: de interne mappene er stengt av .htaccess-filen fra distribusjonen, og under Nginx av forbudet skriptet skrev inn i domenets konfigurasjon.config.php (trinn 05). Stiene i kommandoene bytter du ut med /home/konto/web/domene/public_html, og eieren med brukeren til dette domenet i stedet for www-data.Grenen «Opprette vhost manuelt» (i utskriften: No vhost created (no domain given)). Dette skjer bare på profilen «Konfigurert server», når domenet ikke ble oppgitt. Enklest er rett og slett å kjøre kommandoen fra kontoen på nytt, med domenet oppgitt:
Ny kjøring er trygg: det som allerede er gjort, dupliseres ikke. Må vhost likevel opprettes for hånd — her er den samme konfigurasjonen som installasjonsprogrammet skriver:
ServerName er obligatorisk her. En vhost uten navn blir Apaches standardnettsted og begynner å svare for andres domener på samme server. Av samme grunn skal du ikke slå av 000-default.conf på en konfigurert server: dette nettstedet kan være bygget om til noens produksjonssted — på en fersk VPS fjerner installasjonsprogrammet det selv, her trenger du ikke gjøre det.
! Nginx does not read .htaccess). Nginx leverer statiske filer rett fra disken og leser ikke .htaccess — de interne mappene blir da åpne utad, selv om Apache stenger dem korrekt. Skriptet har på forhånd laget en fil med forbud; den må inkluderes i server{}-blokken til nettstedet ditt, og Nginx må lastes på nytt:
my.arciveo.com → «Nedlastinger». Pakk ut arkivet før du laster det opp til serveren.
Last opp innholdet i distribusjonen til /var/www/monitor (slik at public/, assets/, config.php osv. havner inni) — via SFTP/SCP (FileZilla / WinSCP) eller med kommandoen scp fra den lokale maskinen:
ServerName) skal skrives inn i vhost med en gang, oppgir du det i autokonfigurasjonskommandoen allerede i trinn 01: … | sudo bash -s -- monitor.example.com (eller angir domenet i feltet «Paneldomene» på kontoen). Hvis domenet ikke ble oppgitt, svarer panelet på hvilken som helst host og på IP, og ServerName skrives inn av certbot når SSL utstedes (trinn 06); ingenting trenger å installeres på nytt.
root eller via SFTP, eies filene av root, og nettserveren (www-data) kan ikke lese dem — panelet åpnes tomt eller med feil 403 (i loggen: .htaccess unreadable / directory not executable). Kommandoen nedenfor fikser dette:
Åpne opplasting via SFTP for deg selv. Etter kommandoen over eies alle filene av www-data, mens FileZilla / WinSCP kobler til som din egen bruker – opplastingen feiler da med SSH_FX_PERMISSION_DENIED (Permission denied). Velg ett av de to alternativene.
Alternativ A – en ACL kun for din bruker (anbefalt). Bare du får skriverettigheter; nettserveren kan fortsatt ikke overskrive panelets kode:
Alternativ B – via gruppen www-data. Enklere, men nettserveren får også skriverettighet til panelets filer: ved en sårbarhet i PHP kan koden byttes ut. Rekkefølgen på kommandoene betyr noe – config.php og arbeidsmappene lukkes til slutt:
id deploy – i gruppelisten skal www-data dukke opp; ls -ld /var/www/monitor – rettigheter drwxrwsr-x, bokstaven s i stedet for x betyr at setgid er satt.
Opprett en database og en bruker, og importer deretter skjemaet. Databaseblokken limes inn i terminalen i sin helhet (sudo mysql logger inn som root via unix-socket — root-passord er ikke nødvendig). monitor_db og monitor_user er eksempelnavn, du kan velge dine egne; husk navnet på databasen, brukeren og passordet — du skriver dem inn i config.php i neste steg:
admin-kontoen ved første innlogging i nettleseren (fra database/db.sql), hvis databasen er tom.
Hvis tabellene ikke ble opprettet (panelet viser en tilkoblingsfeil mot databasen eller en tom skjerm i stedet for innloggingsskjemaet) — importer skjemaet manuelt. Kommandoen kjøres i panelroten, verdiene hentes fra blokken over:
$DBNAME / $DBUSER / $DBPASS allerede «gått i glemmeboken» (ny terminaløkt) — sett verdiene inn i kommandoen for hånd, eller sett dem på nytt med de samme tre linjene fra blokken over.
sudo rules NOT written sto i utskriften fra skriptet — da var det ikke noe å avgjøre panelkontoen ut fra (filene var ennå ikke lastet opp), og reglene er ikke opprettet. Uten dem forblir seksjoner som brannmur, Fail2ban og CrowdSec tomme. Nå som filene er på plass, kjører du kommandoen fra kontoen én gang til, med kontoen navngitt eksplisitt:
www-data bytter du ut med brukeren PHP på nettstedet ditt kjører under (på et hostingpanel er dette som regel eieren av domenet). Du kan finne den slik:
/etc/sudoers.d/monitor finnes, og den inneholder linjer med brukeren din.
config.php i roten av panelet (/var/www/monitor/config.php) er den eneste filen du må redigere manuelt. Alle panelinnstillingene er angitt i den som define()-konstanter. Åpne den i en editor:
Sett inn dine egne verdier på de uthevede stedene; la resten stå som det er:
Hva du skal endre:
DB_NAME, DB_USER, DB_PASS — nøyaktig samme databasenavn, bruker og passord som du satte da du opprettet databasen i trinn 04 (hvis du beholdt eksemplene — monitor_db / monitor_user). Ikke rør DB_HOST og DB_CHARSET.APP_URL — full paneladresse med https://, uten skråstrek til slutt og uten www. Må stemme med domenet du aktiverer lisensen på (trinn 07), ellers blir nøkkelen avvist.TIMEZONE — din tidssone (liste — timedatectl list-timezones). Påvirker bare hvordan panelet viser datoer; det påvirker ikke når cron-jobber kjøres (der gjelder systemets tidssone).SESSION_LIFETIME — etter hvor mange sekunder med inaktivitet panelet ber om ny innlogging (standard er 8 timer). F.eks. 3600 = 1 time, 86400 = ett døgn.display_errors, log_errors, error_log) — la stå som standard.Lagre filen (Ctrl+O, Enter, deretter Ctrl+X) og start PHP-FPM på nytt — ellers blir ikke endringene tatt i bruk på grunn av OPcache:
640 (satt i trinn 03) og et eksplisitt forbud i rot-.htaccess. Ikke legg den ut i offentlige repositorier og ikke send den til support med det faktiske passordet.
http:// kan du ikke logge inn.
Certbot skipped — issue SSL in …). Sertifikatet utstedes med Let's Encrypt-bryteren på webdomenet i selve panelet — da tar panelet seg av fornyelsen også.
certbot og Apache-programtillegget er allerede installert av autooppsettet. Domenets DNS bør allerede peke til serveren (steg 02). Utstedelse med én kommando:
Skal panelet også kunne åpnes med www. — list opp begge navnene i én kommando, ellers viser nettleseren en sertifikatadvarsel på den andre adressen:
Y.<VirtualHost *:443>, setter opp omdirigering http→https og automatisk fornyelse. Til slutt: Successfully enabled HTTPS.
dig +short monitor.example.com returnerer serverens IP og at portene 80/443 er åpne (sudo ufw allow 80,443/tcp).
Etter utstedelse: https://monitor.example.com åpnes med hengelås, http:// omdirigerer til https://.
Åpne https://monitor.example.com, logg inn med admin / useradmin og gå gjennom sjekklisten:
ARCIVEO-… fra kontoen på ditt domene og lim inn nøkkelen i «Innstillinger» → «Lisens». Mer info.public/start_db.php hvis det ligger igjen: det lar hvem som helst gjenopprette databasen uten innlogging. Så lenge filen ligger i rotmappen til panelet eller i public/, varsler panelet om det med et rødt banner.sudo /usr/local/bin/clamav-scan.sh) belaster disk og prosessor kraftig og kan ta en time eller mer — på en produksjonsserver er det bedre å vente på nattkjøringen kl. 01:30. Seksjonene «Disker (SMART)», «Ytelse» og «Sikkerhetsoppdateringer» fylles av seg selv: henholdsvis hvert 30. minutt, hvert 5. minutt og én gang i timen.