ISPConfig tips'n'tricks

ISPConfig è un ottimo pannello di controllo free.
Un errore comune è che la versione 3 sia un miglioramento alla 2. Non è corretto. In realtà sono praticamente due prodotti diversi.
La versione 2 è "mirata" alla gestione di un singolo server, con eventuali rivenditori e clienti ben definiti (per es. un cliente non può, in seguito, diventare rivenditore). La versione 3 è invece orientata ad una struttura più complessa, con vari server dedicati a compiti diversi ed una gestione degli utenti più flessibile. Per gestire un solo server è un tantino eccessiva e più complicata del necessario (ma ovviamente lo fa senza problemi!).

Io ho scelto di usare la 3, inizialmente pensando che fosse l'evoluzione della 2. Poi non l'ho cambiata perché mi conosco: l'appetito vien mangiando... Se per il momento mi basta un solo server, magari tra non molto vorrò suddividere il carico tra più macchine. Inoltre potrebbe tornarmi utile per la gestione di server in ufficio.

Ho però dovuto fare alcune modifiche alla configurazione standard:

• ln -s /usr/share/phpmyadmin /var/www/phpmyadmin altrimenti non funziona phpMyAdmin
• permesso l'override del php.ini (mettendolo nella home del proprietario del sito), aggiungendo "-c ~/php.ini" alla linea exec (l'ultima) in /usr/local/ispconfig/server/conf/php-fcgi-starter.master (nel caso l'utente non faccia override, dovrebbe (è da verificare!) venire usato il solo file base)
• nel template per le shell utente /usr/local/ispconfig/server/conf/bash.bashrc.master (alla linea 32) c'è un \ di troppo prima di $USER
• sulla mia rete, è necessario configurare la risoluzione statica dei nomi dei virtual host o wget non funziona (accede ad uno dei router)
• per poter accedere alle statistiche nella dir stats/ di ogni virtual server è necessario creare un file /var/www/clients/clientX/webY/.htpasswd_stats pena un "internal server error" (questo mi ci è voluto un po' per pescarlo... pensavo che Apache fosse sufficientemente furbo da negare l'accesso nel caso non trovi il file... il file viene creado dal pannello di controllo solo quando si imposta una password!). Comunque con Drupal niente statistiche -- non so perché ma la richiesta viene intercettata e gestita da index.php invece di arrivare nella cartella stats malgrado i rewritecond... Continuo ad indagare.

Altre variazioni, suggerite sul forum di supporto, saranno incluse nella prossima release. Purtroppo sono da riapplicare manualmente a tutti i siti già creati.

Rimangono da fare:

• inoltro automatico delle mail generate localmente all'indirizzo dell'owner (al momento deve prendersele dalla shell)
• Impedire l'override di alcuni parametri di php (PHP non supporta più di un -c ...) o limitare i valori max/min impostabili (non che mi serva più di tanto, essendo una cosa per amici...)
• far gestire agli utenti i propri cron (fatto da shell, manca interfaccia)

SNI, APC e Drupal

Per poter usare SNI (in pratica name-based virtualhost per siti https) è necessario installare una versione di Apache che lo supporti. In Debian purtroppo è disponibile solo in unstable, al momento. Apache si deve tirare dietro OpenSSL. Ma questa è la parte facile quindi la lascio come semplice esercizio (compresa l'installazione dei certificati... visto che nel mysite.net.vhost è tutto "chiaro").
Già che avete dovuto usare unstable per Apache, cogliete l'occasione per installare APC, che può rendere MOLTO più veloce l'esecuzione delle pagine. Drupal è piuttosto "pesante" di suo, ed APC può aiutare veramente tanto.

Poi riavviate tutto (apache2ctl -k reload). E vi accorgete che, se avete usato suPHP, APC non funziona!
Infatti APC richiede che il processo di PHP rimanga attivo in memoria, ma suPHP termina insieme allo script...
Però non è neanche una soluzione usare mod_php, dato che sarebbe necessario abbassare la sicurezza a livelli inaccettabili... Che fare?

Semplice, provate attivando suExec e la modalità FastCGI per PHP! Woa! Funzia!

Ecco il file mysite.net.vhost. Un po' lungo, ma in gran parte si tratta di ripetizioni della parte "plain" anche per la parte ssl.
Ho attivato anche i CGI, ma da una prova preliminare non funzionano insieme a suExec, poiché sono al di fuori della webroot. Se vi servono, dovete fare qualche prova. Il sistema più rapido è sicuramente spostare la cgi-bin/ all'interno di web/ .

Ah, dimenticavo: ISPConfig non supporta le opzioni necessarie ad SNI, quindi una volta impostato il vhost non dovrete più modificarlo tramite ISPConfig o perderete tutta la parte relativa all'https. Dovrebbe essere possibile lavorare sui template, ma non mi ci sono ancora messo.