Categoria: Linuxlandia

Per isolare un VirtualHost su apache ed impedire che si possa accedere agli altri VirtualHost, è sufficiente aggiungere la direttiva riguardante il PHP php_admin_value open_basedir /var/www/torregatti.it/

In questo caso l’unica cartella accessibile è la /var/www/torregatti.it/

Se si vogliono aggiungere più cartelle per quel VirtualHost si può scrivere /var/www/torregatti.it/:/altra/cartella/

Nel file di configurazione del VirtualHost avremo qualcosa del genere:

Usando chmod o-rw su /var/www possiamo isolare la cartella dall’accesso esterno degli utenti.

In Plesk purtroppo non è possibile, tramite l’interfaccia grafica, aggiungere manualmente IP alla blacklist di fail2ban.

Lo si può fare esclusivamente, al momento attuale, tramite terminale, interagendo direttamente con fail2ban.

Per bloccare manualmente un IP con fail2ban si può utilizzare il seguente comando:

Dove al posto di nome-jail si inserirà una delle jail configurate su fail2ban e al posto di xx.xx.xx.xx l’indirizzo IP che si intende bloccare.

Vediamo come installare ownCloud su un Ubuntu Server 20.04.1. In aggiunta configureremo anche un VirtualHost con un certificato autofirmato, aggiungendo infine un disco in LVM che ospiti i dati di ownCloud.

1. Configurazione server LAMP

Anzitutto configuriamo il server LAMP installando Apache, MariaDB e il PHP 7.4.

Eseguiamo il seguente comando:

A questo punto configuriamo il database eseguendo:

ATTENZIONE! Se si esegue il commando senza sudo verrà chiesta la password dell’utente root e non ci sarà modo di cambiarla, generando l’errore: ERROR 1698 (28000): Access denied for user 'root'@'localhost'

Digitare in sequenza, per le singole domande:

Change the root password? [Y/n] Y

Remove anonymous users? [Y/n] Y

Disallow root login remotely? [Y/n] Y

Remove test database and access to it? [Y/n] Y

Reload privilege tables now? [Y/n] Y

Una volta completata la configurazione di MariaDB il server LAMP e pronto è possiamo procedere con le specifiche configurazioni.

2. Creiamo il certificato di crittografia

Se non lo abbiamo già fatto installiamo openssl. Questo ci servirà per creare un certificato autofirmato, nel caso in cui si disponga già del certificato si può passare al punto successivo.

Creiamo la chiave privata e il certificato:

Nel caso specifico stiamo dicendo ad openssl:

• req sottocomando col quale specifichiamo che vogliamo usare l’X.509 CSR (certificate signing request), un’infrastruttura standard per le chiavi pubbliche utilizzata tipicamente con SSL e TSL
• nodes indica ad OpenSSL di non cifrare il certificato con una password, dal momento che verrà utilizzato su Apache che deve potervi accedere liberamente
• days specifica la durata di validità del certificato, nel nostro caso 365 giorni
• newkey specifica il tipo di chiave privata (RSA 2048) che si vuole generare e il fatto che la si voglia generare assieme al certificato
• keyout indica la posizione dove creare la chiave
• out indica la posizione dove creare il certificato

Rispondiamo ai quesiti posti da OpenSSL per la configurazione del certificato. Nel mio caso procederò così:

Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Firenze
Locality Name (eg, city) []:Firenze
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Torregatti Spa
Organizational Unit Name (eg, section) []:Servizi Cloud
Common Name (e.g. server FQDN or YOUR name) []:cloud.local
Email Address []:scrivi@petarkaran.it

I valori sono per lo più arbitrari, l’unica cosa importante è il Common Name, che può essere l’indirizzo IP del server, oppure il dominio a cui sarà associato il certificato.

Configuriamo Apache affinché utilizzi correttamente i certificati SSL:

Nel file digitiamo:

Affinché la configurazione funzioni dobbiamo attivare il modulo SSL e il modulo Headers in Apache.

A questo punto attiviamo la configurazione digitando:

Affinché la configurazione sia corretta bisogna riavviare Apache, anche se non è necessario farlo adesso, lo possiamo fare anche dopo.

3. Configuriamo il VirtualHost

A questo punto configuriamo il nostro VirtualHost, immaginiamo che il nostro ownCloud debba trovarsi all’indirizzo cloud.local. (nel caso specifico da http://cloud.local e https://cloud.local)

Creiamo anzitutto due cartelle in /var/www, una per i file, una per i dati ed una per i log, entrambe sottocartelle di cloud.local, nella maniera seguente.

Grazie all’argomento -p creiamo l’intero percorso anche se non esiste.

A questo punto procediamo con la creazione del file del VirtualHost vero e proprio.

Nel file inseriamo le seguenti istruzioni.

In questo modo forziamo il redirect sul HTTPS e abilitiamo il certificato creato in precedenza.

A questo punto riavviamo apache:

4. Creazione partizione per i dati con LVM

Aggiungiamo al nostro server un disco aggiuntivo a creiamo un nuovo disco logico con LVM. Per ulteriori approfondimenti sulla procedura rimando all’articolo LVM, gestore logico dei volumi su Ubuntu [per pinguini alle prime armi]

Anzitutto vediamo i dischi dei quali disponiamo con:

Nel mio caso (sto utilizzando VirtualBox per l’esempio con 2 dischi da 10GB ciascuno):

Il disco che utilizzerò è /dev/sdb. Procediamo quindi a preparare il disco:

Su fdisk digitiamo in ordine:

1. n per creare una nuova partizione
2. p per una partizione primaria
3. 1 numero di partizione
4. INVIO per confermare il primo settore di default 2048
5. INVIO per confermare l’ultimo settore
6. t per modificare la partizione
7. 8e per impostare Linux LVM
8. w per scrivere e salvare il tutto

Utilizzando sudo fdisk -l dovremmo vedere qualcosa di simile:

Creiamo un volume fisico digitando:

Creiamo un gruppo di volumi chiamato dati-cloud digitando:

Creiamo sopra il volume logico dati:

Formattiamo il volume in ext4.

A questo punto montiamo il nuovo volume logico sulla cartella /var/www/cloud.local/dati

Siccome vogliamo che il disco sia montato in modo permanente, modifichiamo /etc/fstab.

In fondo al file aggiungiamo la seguente riga:

In questo modo al riavvio del server il volume logico verrà caricato automaticamente.

5. Creiamo un database per ownCloud

ownCloud necessita di un database per funzionare, pertanto creiamone uno nuovo all’interno di MariaDB.

Entriamo in MariaDB/MySQL:

Una volta dentro creiamo un nuovo database chiamato cloud_db:

Creiamo anche un utente per il database appena creato, che potrà accedere esclusivamente da locale (agli scopi dell’esercizio metterò una password banale):

6. Installazione ownCloud

Scarichiamo ownCloud nella cartella httpdocs. Da qui possiamo scegliere da dove scaricarlo.

Se non abbiamo installato unzip facciamolo:

A questo punto estraiamo il file zip.

Spostiamo i file dalla cartella owncloud creata dall’unzip, nella radice del virtualhost.

In questo modo rimuoviamo anche la cartella aggiuntiva ed il file zip.

Assegniamo adesso l’utente apache a tutta la cartella ed i file creati.

Infine abilitiamo la configurazione e riavviamo apache:

Se tutto è andato bene potremo aprire ownCloud all’indirizzo https://cloud.local/

Inseriamo i parametri nella maniera seguente (utilizzando quelli creati):

1. Scegliamo un utente ed una password
   
2. Per la cartella dati impostiamo la cartella creata all’inizio
   
3. Inseriamo i dati del database configurati in precedenza:
   

Una volta fatto tutto possiamo premere su TERMINA CONFIGURAZIONE.

Se tutto è andato bene vedremo una schermata come la seguente:

Fatto tutto questo possiamo accedere al sistema. Spostandoci su Impostazioni > Generali, potremmo notare delle notifiche come le seguenti:

Apportiamo quindi ancora un paio di modifiche per aggiustare il tutto correttamente.

Anzitutto configuriamo correttamente il crontab affinché esegua gli script di ownCloud.

Digitiamo:

Se è la prima volta che lo apriamo ci chiederà quale editor preferiamo utilizzare, io scelgo 1 per nano.

Aggiungiamo la seguente riga:

Salviamo con CTRL+O e usciamo.

Nelle suddette impostazioni di ownCloud selezioniamo come meccanismo di aggiornamento Cron.

Spostiamoci nella nostra cartella di installazione con:

Eseguiamo i seguenti comandi:

L’utilizzo di sudo -u www-data è necessario perché l’esecuzione deve essere effettuata da Apache. Eseguendolo senza sudo lo faremmo usando il nostro utente, con sudo come root. In entrambi i casi non andrebbe bene.

Per risolvere l’avviso di HTTP "Strict-Transport-Security" dobbiamo aggiungere a <VirtualHost *:443> le seguenti tre righe:

Il file definitivo del virtualhost sarà come il seguente:

Riavviamo ancora una volta apache.

A questo punto è tutto pronto e possiamo cominciare ad usare ownCloud.

In questa guida vedremo come configurare un load balancer utilizzando Pound su Ubuntu Server 20.04.1.

Pound è un software opensource sviluppato principalmente come reverse proxy e application firewall, utilizzato spesso per realizzare load balancer. Tra le caratteristiche salienti ci sono la capacità di rilevare lo stato di un server di backend, la possibilità di tradurre richieste in HTTPS su HTTP e un forte accento sulla sicurezza. Quando un server di backend non è raggiungibile Pound è in grado di rilevarlo, scegliendo tra gli altri server accessibili secondo criteri predefiniti a distribuzione casuale. Il tutto avviene tenendo traccia delle sessioni attive, che tipicamente permangono verso il medesimo server di backend di partenza.

La struttura che andremo a realizzare assomiglierà alla seguente:

Detto questo installiamo Ubuntu Server su tutte e tre le macchine e configuriamo opportunamente gli indirizzi di rete.

1. Configurazione rete

Questa operazione dovrà essere ripetuta in modo uguale su tutte le macchine. Procediamo con la prima. Prima di andare avanti vediamo la configurazione che vogliamo avere.

Creeremo una rete 192.168.0.0/24 nella quale le tre macchine saranno configurate nella maniera seguente:

Per visualizzare la configurazione di rete corrente (comincio dalla prima macchina) digitiamo

Comparirà qualcosa di simile:

Nel mio caso sto utilizzando una macchina virtuale con VirtualBox e la scheda di rete è enp0s3. Tipicamente al suo posto si trova eth1. L’indirizzo configurato dal DHCP è il 192.168.0.4.

La configurazione di rete si trova in /etc/netplan

Per vedere tutti i file di configurazione presenti digitiamo:

dovremmo vedere un file tipo 00-installer-config.yaml

Creiamone un backup del file digitando:

Adesso andiamo a modificare il file, bisogna fare attenzione all’identazione, che prevede 2 spazi vuoti per ciascuna sottosezione. Digitiamo:

Il file originale dovrebbe contenere qualcosa di simile:

Modifichiamolo nella maniera seguente:

Il mio gateway è il 192.168.0.1, per scoprirlo tramite DHCP possiamo digitare ip r

Una volta modificata la configurazione salviamo il file e testiamola digitando:

Se va tutto bene possiamo applicare la modifica, digitando:

Verifichiamo infine la configurazione con:

Se tutto è andato bene vedremo qualcosa del genere:

Se dovessimo cambiare il nome della macchina possiamo digitare:

Per assegnare alla macchina il nome webserver-1. Una volta modificato il nome sarà sufficiente riavviare.

2. Installazione di Pound

Adesso procediamo ad installare Pound su load-balancer-server. Per farlo digitiamo:

Per configurare Pound procediamo a modificare il file /etc/pound/pound.cfg. Digitiamo quindi:

Troveremo di default una struttura simile alla seguente nel file:

Questo significa che Pound è in ascolto sulla porta 8080 e utilizza come servizio un server di backend sempre all’indirizzo locale (qui si suppone si sia installato apache sul medesimo server). Adesso i servizi possono essere definiti in modo globale oppure relativamente ad uno specifico listener. In questo caso sono definiti all’interno di un listener. Ogni servizio ha dentro i server di backend ai quali può essere data una priorità. La priorità di predefinito è impostata su 5, i valori possibili sono da 1 a 9.

Riorganizziamo il nostro file di configurazione per ottenere il seguente risultato:

Se volessimo configurare dei servizi di emergenza, anziché usare il TAG BackEnd potremmo utilizzare Emergency. Tutto il resto rimarrebbe identico. Un server di emergenza interverrebbe solo qualora tutti gli altri backend fallissero.

Salviamo il file e modifichiamo il meccanismo di startup digitando:

Modifichiamo il file nella maniera seguente:

A questo punto riavviamo Pound. Digitiamo:

3. Installazione di Apache sui backend

Sui server di backend sarà sufficiente installare Apache, senza ulteriori configurazioni. Ricordiamoci che Pound, anche se interrogato in HTTPS si connetterà ai server di backend in HTTP.

Per farlo digitiamo semplicemente:

Una volta installato Apache modifichiamo l’output predefinito del webserver. Per farlo cancelliamo il file originale e creiamone uno nuovo.

In questo caso ci scriverò dentro il nome del WebServer, per esempio:

Configuriamo ora il backend affinché effettui il log per le richieste X-Forwarded-For.

Anzitutto abilitiamo l’estensione remoteip di apache.

Modifichiamo il file di configurazione digitando:

Modifichiamo il seguente paragrafo del file:

Faccio notare che l’IP 192.168.0.5 è quello della macchina col Pound.

Riavviamo Apache:

Ripetiamo questa procedura su ogni backend.

4. Prova di funzionamento

A questo punto colleghiamoci al nostro server con Pound, nel mio caso si trova all’indirizzo http://192.168.56.1/

Aggiornando più volte la pagina vedremo comparire, in modo casuale, la risposta del webserver-1 oppure del webserver-2

Oppure:

Problema: con un’installazione di Plesk non sembra esserci spazio sufficiente sul disco per eseguire installazioni ed aggiornamenti con apt-get, oppure effettuare operazioni di database, come per esempio l’esportazione (si ottiene un errore mysqldump: Got errno 28 on write)

Il problema dipende tipicamente dalla mancanza di spazio sul disco. Una possibile soluzione l’abbiamo già vista in Liberare spazio su Ubuntu con errore apt-get “No space left on device”

Un’altra operazione che conviene fare è svuotare i file temporanei creati da Plesk che possono occupare anche diversi GB. Per farlo eseguiamo i seguenti comandi sul terminale:

Questo cancellerà i file temporanei più vecchi di 14 giorni. Se tale operazione non fosse sufficiente procediamo ad eliminare tutti i file temporanei:

Se neanche questo bastasse possiamo cercare i file per dimensione, digitando:

In questo caso cerchiamo file più grandi di 100MB. Controlliamo l’elenco dei file e valutiamo se possiamo eliminarne alcuni (tipicamente i file *.BAK del MySQL possono essere eliminati senza problemi)

Java 8 è stato rilasciato nel marzo 2014 ed è disponibile, all’interno delle repository ufficiali di Ubuntu, solo per le versioni Ubuntu 14.10 e superiore.

Per poterlo installare su Ubuntu 14.04 bisogna procedere nel modo seguente, installando OpenJDK 8 dalla PPA repository.

Apriamo il terminale e aggiungiamo la repository digitando:

Aggiorniamo l’apt-get digitando:

A questo punto possiamo procedere all’installazione:

Se dovessero sorgere problemi con le dipendenze digitiamo:

Dopodiché possiamo eseguire nuovamente il comando precedente per procedere con l’installazione.

L’SFTP (SSH File Transfer Protocol) è un protocollo simile al FTP, utilizzato però per trasferire e manipolare file mediante SSH.

I comandi utilizzati sono simili a quelli del FTP. E’ molto utile specialmente quando si devono trasferire i file da un server all’altro.

1. Collegarsi in SFTP

Per collegarci al server remoto in SFTP digitiamo:

Per collegarci al server remoto su una porta diversa dalla 22

Una volta collegati ci verrà richiesta la password.

2. Comandi disponibili in SFTP

Per ottenere l’elenco di tutti i comandi disponibili, digitiamo:

L’output sarà simile al seguente:

3. Scaricare file e cartelle dal SFTP

Per scaricare un singolo file, nella posizione nella quale abbiamo aperto l’SFTP, digitiamo:

Per scaricare un file rinominandolo oppure scaricandolo in una posizione locale diversa:

Per scaricare una cartella digitiamo:

Per scaricare tutti i file della cartella corrente remota nella cartella locale attuale:

4. Caricare file e cartelle sul SFTP

Per caricare un file locale nella posizione remota, digitiamo:

Per caricare una cartella locale sul server remoto digitiamo:

Per caricare tutti i file della cartella locale sul server remoto:

5. Manipolare file e cartelle sul SFTP

Vedere tutto il contenuto di una cartella:

Creare una cartella:

Rinominare un file:

Rimuovere un file:

Rimuovere una cartella:

Potrebbe accadere che si debba ripristinare la password dell’utente root del database MySQL. In tal caso su Ubuntu è sufficiente seguire la seguente procedura.

Interrompiamo l’esecuzione del servizio MySQL.

Facciamo ripartire il MySQL in modalità safe saltando le tabelle relative ai permessi.

Entriamo nel database:

Modifichiamo la password dell’utente root.

Fermiamo nuovamente il servizio:

Riavviamo il servizio.

Riallacciandomi al precedente articolo ([php] Configurare php.ini per l’upload dei file) voglio approfondire il problema del caricamento di file di grosse dimensioni su server che utilizzano PHP, Apache e nginx (nel mio caso specifico anche Plesk).

Gli errori che possono sorgere sono difatti innumerevoli e spesso apparentemente senza senso.

Cominciamo riepilogando il necessario per quello che riguarda il PHP. Come spiegato nel precedente articolo, assicuriamoci di avere una configurazione simile alla seguente nel file php.ini

In questo caso sto supponendo che caricheremo file fino a 512MB.

Per quanto riguarda il PHP ci dobbiamo assicurare che la quantità di memorie allocabile sia compatibile con la dimensione dei file da caricare e che lo sia anche il tempo di esecuzione.

Con un tempo di 1200 secondi si suppone che l’upload avverrà ad un minimo di 0,43MB/s. Questo significa che parte del caricamento dipende anche dalla velocità di upload del client, che potrebbe non essere sufficientemente alta da permettere al server di terminare l’operazione nei tempi consentiti.

Per inciso ricordiamoci che le classiche connessioni ADSL 20 Mega hanno upload che si aggirano attorno a 1 Mbit, ovvero 0,12 MB/s. Questo significa che il tempo di esecuzione dovrebbe essere per lo meno di 4.300 secondi (approssimando per eccesso).

Detto tutto questo si potrebbe incorrere in altri problemi, come ad esempio, lato client: Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR

Se si sta tentando di gestire l’upload tramite javascript e si incorre in questo errore, esso nulla ha a che fare con il protocollo HTTP/2 (e tanto meno è utile tornare al HTTP/1.1 o simili), ma è legato al fatto che la pagina non invia una risposta corretta. La risposta non viene inviata correttamente perché ad interrompere l’upload possono essere Apache oppure nginx.

Controllando il log del server si potrebbe trovare infatti un errore simile al seguente: 19855#0: *532 client intended to send too large body: 180584796 bytes

In questo caso sto cercando di caricare circa 172MB di file ed nginix blocca l’operazione.

Nel mio caso specifico posso verificare la cosa, confrontando su Windows la dimensione dei file che sto tentando di inviare al server con un unico upload.

Si può notare come la dimensione bloccata sia leggermente più grande dei file in upload, perché, come già discusso nel precedente articolo, il corpo che viene inviato al server contiene anche informazioni aggiuntive che vanno al di là dei singoli file che si stanno caricando.

A questo punto dobbiamo intervenire su nginx aggiungendo l’istruzione:

La configurazione predefinite di nginx sarebbe di 1m, mentre sotto Plesk è di 128m.

Questo parametro può essere modificato all’interno del file /etc/nginx/nginx.conf

Per farlo su Plesk procediamo nel modo seguente (è anche spiegato nella vademecum ufficiale, anche se ci sono delle piccole incongruenze):

1. Colleghiamoci via SSH al Server con Plesk
2. Creiamo un file di configurazione aggiuntivo a cui aggiungeremo l’istruzione precedente: echo 'client_max_body_size 128m;' > /etc/nginx/conf.d/aa_client_max_body.conf
3. Verifichiamo se esiste il file /usr/local/psa/admin/conf/panel.ini
4. Se non dovesse esistere creiamolo copiandolo dal file predefinito: cp /usr/local/psa/admin/conf/panel.ini.sample /usr/local/psa/admin/conf/panel.ini
5. Aggiungiamo l’impostazione per la massima dimensione del corpo: echo -e "[webserver]\n nginxClientMaxBodySize = 512m\n" >> /usr/local/psa/admin/conf/panel.ini
6. Modifichiamo i permessi: chmod 644 /usr/local/psa/admin/conf/panel.ini
7. Riconfiguriamo il tutto: plesk sbin httpdmng --reconfigure-all
8. Riavviamo nginx: service nginx restart
9. Assicuriamoci che su tutti i webserver sia configurato il parametro giusto: nginx -T | grep client_max_body_size
10. Nel caso non lo fosse possiamo usare l’istruzione, per riconfigurare il tutto: plesk repair web -y -v

In generale dovremmo assicurarci che, rispetto ai parametri suddetti, nelle configurazioni di nginx, sotto la voce server, compaiano i seguenti due valori:

Questi valori dovrebbero essere in linea (o superiori) con quelli scelti per il PHP.

Infine dobbiamo verificare che anche Apache consenta l’esecuzione dell’upload. Nel caso specifico potrebbero esserci due parametri ad influenzarlo: FcgidMaxRequestLen  e LimitRequestBody

Impostiamoli nel modo seguente:

Se abbiamo configurato tutto correttamente dovremmo essere in grado di caricare i file come definito all’inizio.