WebHostPro: il web hosting sul tuo NAS QNAP

WebHostPro fa girare siti web su un NAS QNAP: siti statici, siti PHP con i loro database e proxy verso le app del NAS, ciascuno con il proprio dominio e un certificato, tutto da un unico pannello. È gratuito e si installa dal repository App Center di questo sito.

Funziona su un NAS QNAP con processore Intel o AMD (x86_64), su QTS 6.0 o QuTS hero 6.0 o versioni successive.
Si installa da App Center come (example) WebHostPro, dal repository QNAP Utilities.
Pannello: https://<NAS>:9541/; i siti rispondono sulle porte 9542 e 9543 finché non li sposti su 80 e 443.
Compilato dai sorgenti con l’App Builder di Bucket & Code Server IDE.

01Presentazione

WebHostPro fa girare siti web su un NAS QNAP. È uno stack di server web: nginx davanti a ogni sito, dietro di lui Apache httpd per i siti che lo usano, PHP da 8.1 a 8.5, MariaDB, Percona Server, PostgreSQL, memcached e Valkey, con un pannello in nove lingue che aggiunge, modifica e rimuove i siti.

02Schermate

WebHostPro: the overview of the sites and services

The list of sites with their PHP version and certificate

03Primo avvio

Il pulsante Apri di App Center porta al pannello, https://<NAS>:9541/; la porta 9540, in HTTP semplice, rimanda lì. In una nuova installazione il pannello mostra Primo accesso: una password di almeno 10 caratteri, scritta due volte. Il pacchetto non imposta nessuna password e non ne genera, e il pannello conserva solo un hash della password che imposti.

La pagina accetta la password solo da un computer della rete propria del NAS (indirizzo privato, di loopback o link-local) e per 60 minuti dopo l’avvio del pannello; finché nessuno la imposta, la sceglie la prima persona della rete che apre il pannello in quell’ora. Riavvia WebHostPro in App Center per riaprirla. Una sessione dura 8 ore e 10 accessi falliti da un indirizzo bloccano quell’indirizzo per 15 minuti.

04Siti

Un sito è un dominio con i suoi alias, un tipo (file statici, PHP, o un proxy verso un servizio sul NAS o nella rete locale, anche in un container, con websocket), un server web (nginx o Apache httpd) e, se serve, un database. La destinazione di un proxy è un indirizzo di un intervallo privato, non un nome host. Ogni sito ha un account proprio, ws-<ID>, che possiede la sua cartella ed esegue il suo PHP, così il PHP di un sito non può leggere i file di un altro. La cartella sta in una cartella condivisa di QTS o nella cartella dei dati di WebHostPro, e la sua public/ è la radice dei documenti.

Un sito PHP esegue il proprio master PHP-FPM, e la sua scheda PHP tiene la versione (da 8.1 a 8.5), il fuso orario, i limiti, gli errori, le sessioni e la sicurezza, OPcache e il JIT, APCu, le estensioni, altre righe php.ini e i worker PHP (il pool). Una riga php.ini è controllata contro le direttive che il PHP di quella versione elenca da sé; un nome che carica codice, esegue un comando, indica un file o contiene una password è rifiutato. Il pool ha il gestore dei processi (su richiesta, dinamico o statico), il numero di processi (su richiesta con 5 per impostazione predefinita), il tempo di inattività, le richieste per processo, un limite di tempo per richiesta e un registro delle richieste lente, che la scheda Registri mostra. Un crash o un PHP sovraccarico su un sito lascia girare gli altri, e un cambio delle impostazioni PHP di un sito riavvia solo il PHP di quel sito. Un master che termina viene riavviato e resta fermo dopo cinque terminazioni in un minuto; logs/php8.N-ID.log lo dice.

Ogni sito può eseguire attività pianificate come il proprio account e con il proprio PHP: un file PHP, un comando o l’indirizzo del sito stesso, ogni minuto o secondo qualsiasi pianificazione cron. La pagina del sito mostra il risultato e l’output di ogni esecuzione, e MailServerPro invia un rapporto quando un’attività inizia a fallire.

Ogni sito PHP ha un proprio Valkey (parla il protocollo di Redis) e un proprio memcached, ciascuno su un socket in una cartella che solo quel sito può aprire, quindi nessuno dei due ha bisogno di password o di una porta di rete; la scheda Cache del sito mostra i due socket. Ognuno tiene fino a 64 MB e un riavvio li svuota entrambi. Ogni versione di PHP ha imagick, con ImageMagick che legge e scrive JPEG, PNG, WebP, GIF e AVIF e legge HEIC. La sua policy rifiuta i formati che leggono altri file o avviano programmi, come SVG e MSL.

I file .htaccess dei siti Apache possono usare anche l’autenticazione Digest, i gruppi da un file di gruppi, Substitute per sostituire testo in una pagina e il filtro RATE_LIMIT per limitare la velocità di un download.

Un sito PHP può avere anche estensioni PECL proprie: la sua scheda PHP le compila con l’account del sito, senza rete, nell’ambiente di compilazione di Bucket & Code Server IDE, e le carica solo il PHP di quel sito.

WebHostPro può diventare il server web del NAS con un clic, e una nuova installazione lo chiede una volta: l’amministrazione di QTS passa dalla porta 443 alla 44443 e il server web di QTS dalla 80 alla 8880, ogni passo controllato prima del successivo, i siti di QTS finiscono dietro WebHostPro e un clic nella pagina Front-end e porte restituisce 80 e 443.

Un tour guidato porta dalle porte standard e da TurboDNS al tuo primo sito, poi, dopo aver controllato la configurazione DNS, propone di distribuire l’indirizzo del server DNS tramite il DHCP del router.

Un sito PHP o statico servito da nginx ha una scheda Cache. nginx comprime le risposte di testo con Brotli e zstd oltre che con gzip. Un sito PHP può attivare una cache delle pagine, spenta per impostazione predefinita: i visitatori con un cookie di accesso ricevono sempre una pagina fresca, l’intestazione X-Cache dice HIT, MISS, STALE, UPDATING o BYPASS, e Svuota la cache la svuota. I browser possono tenere i file statici per 1, 7, 30 o 365 giorni. nginx accetta un corpo di richiesta fino alla richiesta più grande del sito (il post_max_size della scheda PHP) e oltre risponde 413; un sito proxy non ha limite di corpo sul front.

Aggiungi sito è una procedura guidata per il dominio: Dominio, DNS, Registrar, Sito web, Database (per un sito PHP), Certificato e Riepilogo. DNS chiede chi risponde per la zona (TurboDNS su questo NAS; i server del registrar o di un fornitore DNS; oppure Cloudflare o OVHcloud, dalla zona che TurboDNS tiene su questo NAS) e quali indirizzi pubblici ha questo NAS. Registrar elenca cosa inserire dove il dominio è stato comprato, ogni valore con un pulsante di copia, e sotto gli inoltri del router e lo stato del front. La prova del Riepilogo mostra insieme il piano del sito e quello di TurboDNS, e una sola applicazione invia entrambi. Il certificato viene da Let’s Encrypt (HTTP-01, dove il front serve il file sulla porta 80, oppure DNS-01 tramite TurboDNS o Cloudflare; WebHostPro lo rinnova quando mancano 30 giorni o meno), oppure è un certificato caricato, quello del NAS stesso o uno autofirmato.

Dopo l’applicazione, la Panoramica del sito ha il riquadro Completa la configurazione di <nome>: Sito applicato, Record in TurboDNS, Presso il registrar, Controllo dal vivo, Certificato e Concludi. Controlla ora legge i name server della zona superiore, il TurboDNS di questo NAS, tre resolver pubblici e il front, e dice che non può vedere se le porte 53, 80 e 443 raggiungono il NAS da Internet; la riga Certificato chiede il certificato a Let’s Encrypt. La riga Record in TurboDNS è fatta quando il piano di TurboDNS per il dominio non trova nulla da cambiare, dopo la prova della procedura, dopo Invia i record della riga o dopo un invio ripetuto allo stesso modo, e mostra allora In TurboDNS dal <ora>; un sito i cui record sono già nella zona lo ottiene dalla sola prova.

Ogni modifica è prima una bozza. La prova scrive tutto il livello web in una cartella di lavoro, vi esegue nginx -t, httpd -t e php-fpm -t e mostra i file aggiunti, modificati e rimossi con le loro differenze. L’applicazione esegue esattamente quel piano, prima conserva uno snapshot dei file in uso, ricarica con garbo e rimette lo snapshot se un passaggio fallisce. Eliminare un sito richiede di scriverne il nome; la sua cartella e i suoi database restano.

Per un sito proxy, App su questo NAS elenca le app installate per cui WebHostPro ha un modello: Rtorrent 16 e i suoi componenti aggiuntivi, Radarr, Sonarr, Prowlarr, Lidarr, Bazarr, Seerr, Tautulli, qBittorrent, Transmission, TunerHub, Weblate, Tolgee, Bucket & Code Server IDE, Plex Media Server e Jellyfin. La scelta di un’app compila la destinazione con la porta usata dal suo pacchetto e attiva i websocket se l’app ne ha bisogno. Il front invia allora all’app X-Forwarded-Host e X-Real-IP, concede fino a un’ora per rispondere a un’app con richieste lunghe e trasmette senza buffering contenuti multimediali ed eventi delle app che li inviano. Un’impostazione che solo l’app può cambiare, come l’URL Base di un’app *arr, è indicata in una riga sotto l’elenco.

05Sito predefinito

Una richiesta per un nome che nessun sito ha, come l’indirizzo o il nome del NAS, arriva al sito predefinito: alla cartella condivisa Web di QTS quando il NAS ne ha una che WebHostPro può usare, altrimenti a una pagina iniziale nella cartella dei dati di WebHostPro. Lo serve Apache httpd, quindi i file .htaccess della cartella funzionano, tranne le righe Options, che httpd ignora. Il suo PHP gira con un account proprio. Dopo l’installazione o l’aggiornamento è attivo come bozza: la prossima prova e l’applicazione delle modifiche lo mettono in linea. Risponde sulle porte del front: sulla 80 dopo che il front è stato spostato lì nella pagina Front-end e porte, altrimenti sulla 9542. Finché il server web di QTS occupa la porta 80, la sua pagina in WebHostPro indica l’impostazione da disattivare in QTS. Non serve mai le cartelle degli altri siti che stanno nella cartella Web, i file e le cartelle il cui nome inizia con un punto (tranne .well-known), né le cartelle di QTS che iniziano con @, e non mostra elenchi delle cartelle. WebHostPro non cambia i permessi della cartella. Le cartelle della cartella condivisa Web che sono collegamenti ad altre cartelle condivise o volumi funzionano come con il server web di QTS, anche per PHP.

In HTTPS risponde con il certificato del NAS, quello che QTS usa per le proprie pagine; finché è il certificato autofirmato di QNAP, i browser mostrano un avviso. Una richiesta TLS a un sito senza TLS viene rifiutata.

WebHostPro ruota da sé i propri log: a 10 MiB o dopo una settimana, conserva cinque copie compresse con gzip, e nginx e httpd riaprono i log senza perdere richieste.

06Database

Un sito riceve un database e un utente MariaDB, Percona Server o PostgreSQL nella pagina Database o nella sua scheda Database. Percona Server 8.4 viene configurato quando si crea il primo database Percona e ascolta su 127.0.0.1:9555 e su un socket; un NAS che non lo usa mai non lo avvia mai. La pagina Database ha un riquadro per MariaDB e uno per Percona Server, con otto impostazioni (il buffer pool, le connessioni, il pacchetto più grande, il redo log, le tabelle temporanee, la cache delle tabelle, il tempo di inattività, il tempo delle query lente) e altre righe my.cnf, controllate contro l’elenco di opzioni del server stesso. Una modifica è una bozza; l’applicazione riavvia il server, così i suoi database non rispondono per qualche secondo.

07Con le altre app sul NAS

Quando TurboDNS gira sul NAS, il passaggio DNS della procedura gli propone la zona, e l’applicazione invia i record. Senza MailServerPro non portano record di posta: una zona nuova riceve i name server ns e ns1, entrambi questo NAS se non indichi un secondo name server, e i record A e AAAA dei nomi del sito, di ns e di ns1; una zona che TurboDNS serve già tiene i propri name server. Con MailServerPro installato, la zona riceve il modello di hosting di TurboDNS con gli indirizzi pubblici del NAS che confermi, i record A e AAAA dei nomi propri del sito (il modello copre il dominio, www, ns, ns1 e i nomi della posta, così un secondo sito come shop.example.com riceve i suoi) e i record DKIM, MTA-STS, TLS-RPT e TLSA di MailServerPro. Nulla viene scritto in TurboDNS prima dell’applicazione, e il Riepilogo mostra prima ogni record.

La terza risposta del passaggio DNS, Cloudflare o OVHcloud, dalla zona che TurboDNS tiene su questo NAS, invia a TurboDNS gli stessi record della prima risposta, e per il dominio risponde un fornitore DNS. TurboDNS invia la zona tramite l’API del fornitore, e solo quando glielo chiedi: apri la zona in TurboDNS, la sua scheda Cloudflare e OVH, Rivedi le modifiche, poi Invia modifica/e. Il passaggio Registrar non elenca allora né name server, né record glue, né porta 53: il registrar mantiene i name server del fornitore, e la zona non ha bisogno dell’inoltro della porta 53 sul router. Il controllo dal vivo passa allora sui resolver pubblici e sul front, con le righe Server dei nomi presso il registrar e Record glue saltate.

Con Bucket & Code Server IDE installato, la scheda File di un sito apre la sua cartella nell’editor.

08Senza un indirizzo pubblico

Un NAS dietro un CGNAT, o dietro un router che non inoltra alcuna porta, può pubblicare su Internet i siti scelti tramite un Cloudflare Tunnel. Il riquadro Rendi i siti raggiungibili da Internet tramite Cloudflare nella pagina Front-end e porte prende un token API del tuo account Cloudflare e una zona i cui name server sono quelli di Cloudflare. WebHostPro crea allora un tunnel tutto suo e avvia cloudflared, che si collega da sé a Cloudflare. Ogni sito già applicato riceve un interruttore che dà ai suoi nomi nella zona un record CNAME con proxy verso il tunnel; WebHostPro rifiuta un nome che ha già un record A, AAAA o CNAME che non ha creato lui. Disattivare il tunnel elimina i record creati da WebHostPro e il tunnel. Cloudflare termina il TLS e vede il traffico, e nel piano gratuito una richiesta può caricare al massimo 100 MB.

09Installazione

Consigliato: da App Center. Aggiungi una volta il repository di questo sito; da lì in poi questo pacchetto si installa e si aggiorna da App Center come qualsiasi altra app.

App Center → ⚙ Impostazioni → Repository app → Aggiungi.
Chiamalo QNAP Utilities, incolla https://www.qnaputilities.com/repo.xml, Aggiungi.
Apri QNAP Utilities nella colonna di sinistra e installa (example) WebHostPro.

Il pannello del repository: ogni pacchetto del feed →

10Cosa richiede

Un NAS QNAP con processore x86_64 (Intel o AMD) con QTS 6.0 o QuTS hero 6.0 o successivi.

Il pannello è sulla porta 9541 (HTTPS; la 9540 rimanda lì), il front (nginx) sulla 9542 (HTTP) e sulla 9543 (HTTPS, e UDP per HTTP/3 quando nginx lo ha), e httpd su 127.0.0.1:9544 dietro di lui. I database, le cache e i servizi opzionali ascoltano solo su 127.0.0.1. Il front passa alle porte 80 e 443 solo quando lo clicchi nella pagina Front-end e porte, che elenca i passaggi in QTS che liberano quelle porte e ciò che ognuno rompe; WebHostPro non cambia mai da solo le impostazioni di QTS.

Su QuTS hero, una cartella condivisa con le autorizzazioni avanzate delle cartelle non può contenere siti: l’applicazione si ferma, nomina la cartella e chiede di nuovo. WebHostPro 0.14.4 è stato provato su QTS 6.1.0 e su QuTS hero 6.1.0.