Installare Plesk su Ubuntu 20.04 non è complicato, ma va fatto con metodo: il punto non è lanciare uno script e sperare che tutto resti pulito, bensì arrivare a un host coerente, aggiornato e con una baseline chiara prima di esporre pannelli, servizi web e mail. Su una macchina destinata a produzione, la sequenza corretta è semplice: controlli preliminari, installazione, verifica dell’integrazione con il sistema, hardening minimo e test dei servizi che Plesk andrà a gestire.
Ubuntu 20.04 è ancora una base comune per molti ambienti legacy o consolidati. Plesk funziona bene su questa release, ma i problemi tipici nascono quasi sempre prima dell’installer: hostname errato, DNS non coerente, pacchetti di sistema obsoleti, conflitti con stack già presenti, oppure una VM sottodimensionata. Se il nodo è già in uso per altro, va deciso subito cosa deve restare e cosa deve essere sostituito da Plesk, perché il pannello tende a prendere il controllo di Apache, Nginx, PHP, mail e DNS.
Scelta architetturale: cosa deve gestire Plesk
Prima di installare, chiarisci il perimetro. Plesk può diventare il centro operativo per hosting web, mail, DNS, database e certificati, ma non è una “pezza” sopra un server già configurato in modo creativo. Se il nodo ospita già un reverse proxy custom, un’istanza Docker con porte esposte, un mail server manuale o una configurazione Apache/Nginx molto ritoccata, l’installer può sovrascrivere componenti o introdurre dipendenze inattese.
La domanda pratica è questa: vuoi un server gestito da Plesk o un server su cui Plesk sia ospitato? Nel primo caso il pannello deve essere il riferimento principale. Nel secondo, il rischio di conflitti aumenta e conviene valutare una VM dedicata. In produzione, separare i ruoli riduce quasi sempre il tempo speso in diagnosi successive.
Prerequisiti minimi prima di toccare il sistema
Su Ubuntu 20.04, il nodo deve partire da un sistema aggiornato e con accesso root o sudo. Il controllo preliminare essenziale è questo:
hostnamectlIl nome host deve essere un FQDN valido, ad esempio server01.example.com, non un nome corto o temporaneo. Plesk usa il nome host in più punti, dai certificati ai servizi interni. Se il valore è sbagliato, correggilo prima di installare:
sudo hostnamectl set-hostname server01.example.comVerifica anche la risoluzione locale:
getent hosts server01.example.comSe il comando non restituisce l’IP atteso, controlla /etc/hosts e la zona DNS. Un mismatch qui non blocca sempre l’installer, ma genera problemi dopo: mail, certificati, accesso al pannello e servizi che si aspettano un nome coerente.
Controlla anche lo stato degli aggiornamenti e la connettività verso i repository. L’installer di Plesk scarica componenti durante il setup, quindi il nodo deve raggiungere Internet o almeno i mirror necessari:
sudo apt updateSe apt update fallisce, non ha senso andare avanti: prima risolvi DNS, routing, proxy o policy firewall in uscita.
Controlli di base su porte, risorse e conflitti
Plesk occupa porte ben precise, soprattutto per il pannello e i servizi web. Prima dell’installazione verifica che non siano già in uso da processi non controllati:
sudo ss -lntp | egrep ':(80|443|8443|25|53|110|143|465|587|993|995)'Se trovi servizi sconosciuti in ascolto su 80, 443 o 8443, valuta se disattivarli o spostarli. Il pannello Plesk, per accesso iniziale, usa normalmente la porta 8443. Se quella porta è già bloccata, l’accesso iniziale diventa più complicato e il troubleshooting si allunga inutilmente.
Controlla anche le risorse minime. Per un’installazione base, 2 GB di RAM sono il limite operativo, ma 4 GB o più sono una scelta più sensata appena si aggiungono mail, antivirus, più domini o PHP multipli. Il disco deve avere margine reale, non solo nominale: tra pacchetti, log e cache, un nodo stretto va in sofferenza in fretta.
Una verifica rapida del filesystem aiuta a evitare installazioni interrotte a metà:
df -hTSe lo spazio libero è scarso, libera prima il necessario oppure espandi il volume. Far partire l’installer con meno di qualche gigabyte disponibili è un invito a problemi durante il download dei componenti.
Installazione di Plesk su Ubuntu 20.04
Il metodo standard e più pulito è usare l’installer ufficiale. Scarica lo script e avvialo con privilegi elevati. In un contesto operativo normale, questo è il percorso più lineare:
wget https://autoinstall.plesk.com/plesk-installerchmod +x plesk-installersudo ./plesk-installerSe preferisci una modalità non interattiva, utile per automazione o provisioning ripetibile, puoi usare l’installazione in unattended. In quel caso devi però sapere già quali componenti vuoi includere. Non è il momento di improvvisare: il rischio è installare più del necessario o, peggio, un profilo che non corrisponde al tuo servizio.
Durante il wizard scegli il tipo di installazione in base all’uso previsto. Per un server hosting classico, il preset completo con stack web, PHP e database è il più comune. Se invece il nodo ospita solo alcuni siti e il resto è esternalizzato, conviene ridurre il set iniziale e aggiungere solo ciò che serve davvero.
In fase di setup, osserva con attenzione eventuali avvisi su pacchetti già installati. Plesk può sostituire o integrare componenti come Apache, Nginx, PHP, MariaDB e Postfix. Se il sistema aveva già versioni custom o repository terzi, fermati e valuta l’impatto. Il punto non è “si può fare”, ma “quanto costa rimettere in ordine se qualcosa si rompe”.
Verifica dell’accesso al pannello dopo il setup
Al termine dell’installazione, il pannello è normalmente raggiungibile su HTTPS alla porta 8443. La verifica più semplice è da shell:
curl -kI https://IP_DEL_SERVER:8443Ti aspetti un HTTP/1.1 200, un 302 verso la pagina di login o comunque una risposta TLS valida. Se ricevi timeout, controlla firewall locale, security group del provider e stato del servizio Plesk. Se invece il certificato risulta non attendibile, è normale nelle prime fasi: poi sostituirai il certificato di default con uno valido per il dominio corretto.
Dal lato sistema, verifica che i servizi principali siano attivi:
sudo systemctl status psaIn base al layout installato, possono esserci anche servizi separati per Apache, Nginx, MariaDB, Postfix e Dovecot. Non basta che il pannello risponda: bisogna controllare che la macchina sia operativa come host applicativo, non solo come interfaccia web.
Accesso iniziale e hardening minimo del pannello
Al primo accesso, completa la configurazione iniziale con credenziali amministrative robuste e con un indirizzo email gestito davvero. Evita caselle temporanee o indirizzi non presidiati: Plesk invia notifiche, allarmi e messaggi operativi che servono per la manutenzione. Se li perdi, perdi anche la capacità di reagire in tempo.
La prima correzione utile è sostituire il certificato auto-firmato del pannello con uno valido. Questo riduce gli avvisi lato browser e impedisce che gli utenti amministrativi ignorino i warning TLS. Se il pannello è esposto su Internet, il certificato non è un dettaglio estetico: è parte dell’igiene operativa.
Controlla anche la policy degli accessi. Se il server è amministrato da un team, limita gli account con privilegi elevati e usa ruoli separati per attività diverse. Un solo account condiviso è comodo fino al primo incidente, poi diventa un buco nero nei log e nella responsabilità operativa.
Configurazione dei servizi web: Apache, Nginx e PHP
Una delle ragioni per cui Plesk è usato spesso in hosting è la gestione integrata di Apache e Nginx. In molti scenari Nginx lavora come reverse proxy davanti ad Apache, ma la scelta dipende dal profilo del sito. Per applicazioni leggere e statiche, Nginx può fare gran parte del lavoro; per stack legacy o CMS storici, la compatibilità con Apache resta utile.
Il punto operativo è che Plesk rende la gestione dei virtual host più coerente, ma non elimina la necessità di capire cosa sta succedendo sotto. Se una pagina risponde lentamente, devi sapere se il collo di bottiglia è PHP-FPM, il database, il disco o la cache. Il pannello semplifica il cambio di configurazione, non la diagnosi.
Per controllare i pool PHP attivi e le versioni disponibili, il percorso in GUI è spesso più comodo, ma da shell puoi vedere quali processi stanno girando e con quali parametri. La verifica base è questa:
ps aux | grep php-fpmSe usi più versioni PHP, fai attenzione alla compatibilità dei siti importati. Un sito che girava su PHP 7.4 può rompersi su PHP 8.x per funzioni deprecate o estensioni mancanti. Il passaggio va testato dominio per dominio, non imposto in blocco.
DNS, mail e certificati: tre punti che generano problemi reali
Con Plesk, DNS e mail spesso finiscono nello stesso perimetro operativo, ma vanno trattati con attenzione diversa. Se il server gestisce anche i record DNS autorevoli, la zona deve essere coerente con l’IP pubblico e con l’hostname del nodo. Un record A sbagliato o un MX incoerente può sembrare un problema minore, ma si traduce subito in mail non recapitate o in certificati che non si allineano ai nomi reali.
Per la mail, la parte critica non è “installare il servizio”, ma farlo parlare bene con il resto del mondo. SPF, DKIM e DMARC non sono optional se il server invia posta per domini reali. Plesk semplifica la configurazione, ma non sostituisce la verifica delle policy esterne e del reverse DNS del provider.
Un controllo rapido sul reverse DNS e sulla risoluzione pubblica evita molte ore perse dopo:
dig +short server01.example.com Adig +short -x IP_PUBBLICOSe i due valori non sono coerenti con il ruolo del server, apri il ticket presso il provider o correggi la delega DNS. Per i certificati, usa Let’s Encrypt quando il dominio è già pubblicamente risolvibile e raggiungibile sulla porta 80/443. Se il DNS non è stabile, il rinnovo automatico fallirà prima o poi.
Installazione pulita vs migrazione da server esistente
Una migrazione su un nodo nuovo è sempre preferibile a una sovrascrittura su un server già pieno di servizi. Se devi importare siti da un ambiente precedente, prima fai un inventario: domini, versioni PHP, database, cron, certificati, mailboxes, record DNS e eventuali rewrite custom. Senza questa lista, il passaggio diventa un tentativo cieco.
Quando il vecchio server ha configurazioni manuali, non copiare a mano i file “a sentimento”. Verifica quali elementi sono realmente necessari e quali erano solo workaround del passato. In molti casi conviene ricreare il sito in Plesk e migrare solo contenuti, database e parametri indispensabili, lasciando fuori il debito tecnico accumulato nel tempo.
Se l’ambiente è critico, pianifica un rollback semplice: snapshot della VM prima del setup o backup completo del server. Questo è il tuo punto di ritorno se l’installazione interferisce con stack esistenti o se una parte del servizio non si riallinea come previsto.
Verifiche post-installazione da non saltare
Dopo il setup, valida almeno questi punti:
https://IP:8443 e il login funziona.In pratica, non fermarti al “si apre il pannello”. Un’installazione completa ma fragile è peggio di un’installazione incompleta, perché ti dà una falsa sensazione di stabilità. I problemi si presentano di solito al primo rinnovo certificato, al primo aggiornamento PHP o al primo dominio importato.
Manutenzione dopo l’installazione
Plesk non va trattato come un sistema che “una volta installato e finito”. Il pannello, i componenti web e le estensioni richiedono aggiornamenti regolari. La manutenzione minima include patch di sistema, aggiornamenti del pannello, controllo dei log e pulizia dei componenti non usati. Se non governi questa routine, il nodo si appesantisce e la diagnostica diventa più lenta nel tempo.
Per tenere sotto controllo lo stato del sistema, usa log e metriche prima di modificare qualcosa. Alcuni check utili sono i log di sistema, i log del pannello e i log dei servizi web. A livello pratico, se un sito risponde male, guarda prima gli errori dell’applicazione e i tempi di risposta reali, non soltanto la pagina di stato del pannello.
Un approccio sano è questo: aggiornamenti pianificati, backup verificati, monitoraggio attivo del disco e alert sui servizi essenziali. Se il server ospita più domini, la saturazione di un singolo sito non deve trascinare giù il resto. Qui entrano in gioco limiti PHP, pool separati e una configurazione sensata delle risorse.
Errore tipico: il pannello non si apre dopo l’installazione
Se dopo il setup non riesci ad aprire Plesk, la diagnosi più rapida segue tre strade: porta bloccata, servizio fermo, oppure DNS/hostname incoerente. Il controllo base è:
sudo systemctl status psaSe il servizio è attivo ma il browser non raggiunge la pagina, verifica il firewall locale e quello del provider. Se il servizio non parte, controlla i log di installazione e lo stato dei componenti. In caso di hostname errato, correggilo e riavvia i servizi interessati. Evita di fare “restart a caso” su tutto il sistema: prima identifica il layer che sta fallendo.
Se il problema è un certificato o un redirect anomalo, prova l’accesso diretto via IP sulla porta 8443 e poi sostituisci il certificato del pannello con uno valido. Se il problema è più profondo, un backup della VM o uno snapshot ti consente di tornare indietro senza perdere ore in tentativi casuali.
Quando conviene non installare Plesk su quel nodo
Ci sono casi in cui la risposta corretta è “no, non qui”. Se il server è già un nodo di produzione con stack personalizzati, se gestisce applicazioni containerizzate complesse, se funge da reverse proxy centralizzato o se ospita servizi critici non web, aggiungere Plesk può aumentare la superficie di manutenzione invece di ridurla. In quei casi la scelta migliore è una macchina dedicata o una VM separata, con ruoli più chiari.
Lo stesso vale per ambienti in cui il team vuole controllo granulare su ogni componente e preferisce gestire tutto da IaC o da configurazioni versionate. Plesk è utile quando vuoi accelerare la gestione operativa e ridurre gli errori manuali su hosting standard. Non è il sostituto universale di una piattaforma progettata su misura.
Sequenza pratica riassunta
hostnamectl e getent hosts.apt update e correggi eventuali problemi di rete o repository.ss e df -hT.https://IP:8443 e lo stato dei servizi con systemctl.Se tieni questo ordine, l’installazione resta prevedibile. Saltare i controlli iniziali, al contrario, porta quasi sempre agli stessi problemi: pannello non raggiungibile, mail mal configurata, certificati incoerenti o servizi web che sembrano funzionare solo finché non arriva il primo cambio reale.
In un’installazione Plesk fatta bene, il valore non sta nello script lanciato, ma nella qualità del nodo che lo ospita. Ubuntu 20.04 è una buona base, ma va preparata con disciplina. Se il server è coerente prima dell’installer, il resto è quasi sempre una questione di configurazione, non di fortuna.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.