Linux

Come editare il file hosts su linux

In questo breve articolo vi spiegherò cosa è il file di hosts e come editarlo su linux.
Editare il file di hosts su linux è molto semplice perchè ha una sintassi molto semplice, e in maniera un pò banale è possibile definirlo come “il primo DNS” che contatta il Sistema Operativo.

Perchè modificare il file hosts?

I casi in cui conviene modificare il file hosts sono molteplici, per esempio:

  • Bloccare un dominio
  • Testare le configurazioni di apache
  • Simulare un piccolo network

Passiamo alla pratica, editiamo il file di hosts su linux.

Il file di Hosts sui sistemi linux lo troviamo nella cartella /etc/ quindi per leggerlo possiamo lanciare il seguente comando:

less /etc/hosts

e l’output, nel mio caso è:

127.0.0.1       localhost
127.0.1.1       foobar

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

In parole povere, digitando localhost sulla barra del browser risponderà l’indirizzo 127.0.0.1, uguale digitando foobar.
Possiamo editare il file di hosts usando vi oppure se siete utenti meno esperti c’è nano.

sudo nano /etc/hosts
sudo vi /etc/hosts

Mentre in lettura abbiamo potuto leggere il file di hosts senza essere superutenti, per editare il file di hosts è necessario essere superutenti.
Una volta aperto il file di hosts, ci posizionaniamo alla riga sotto 127.0.0.1, scriviamo l’indirizzo IP che desideriamo, premiamo TAB e poi scriviamo il dominio.
Per esempio:

127.0.0.1       localhost
127.0.1.1       OpenPingu
192.168.1.21    foo.apptecsrl.com

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Una volta salvato, se digito sul browser foo.apptecsrl.com mi risponderà l’indirizzo IP 192.168.1.21

Cosa possiamo fare in pratica?

Se vogliamo bloccare un dominio, basta ridirigire il dominio target su un indirizzo IP, anche localhost. Per esempio:

127.0.1.1       www.ilgiornale.it

In questo caso, quando sul PC digiti il suddetto indirizzo web sarai reindirizzato alla porta 80 del tuo pc.
Per testare le configurazioni di Apache bisogna modificare il file di hosts sia della macchina che effettua la richiesta, sia quella che la gestisce.
Supponiamo che la macchina che ha il webserver risponda all’indirizzo 150.217.23.45 e al dominio www.example.com. Il nostro obiettivo è testare il servizio che risponderà all’indirizzo foo.example.com
Sia sullla macchina server, che sulla nostra modifichiamo il file hosts inserendo la stringa:

150.217.23.45      foo.example.com

Soltanto chi avrà il file hosts modificato potrà accedere al servizio che risponde al dominio foo.example.com

Infine, possiamo simulare anche un piccolo network. Assumiamo che vogliamo testare una futura configurazione composta da 6 macchine ed ognuna al suo interno ha un demone di Docker. Tutte insieme fanno parte del solito stack dove è stata deployata la solita Webapp.
In questa configurazione ci possiamo veramente sbizzarrire, anche perchè possiamo partire da configurazioni più semplici, fino a finire con configurazioni che includono dei load balancer.

Coding

Deploy di Django con Apache/httpd e mod_wsgi

Premetto che ho intrapreso una personale crociata nei confronti dei deploy di Django con Apache. Spesso e volentieri mi trovo a dover utilizzare ancora questa modalità di deploy per motivi di forza maggiore.

Partiamo da dei concetti semplicissimi che devono essere dei capisaldi per ogni deploy, i file statici devono essere gestiti da servizi esterni ( ad esempio amazon S3), l’applicazione python deve essere dentro un virtualenv e devono poter convivere più applicazioni web assieme.
Sulle distribuzioni debian based, ubuntu compresa, è possibile installare il mod-wsgi lanciando il comando:

sudo apt-get install libapache2-mod-wsgi-py3

Mentre su Centos e derivate è possibile installare il modulo con:

sudo yum install python36u-mod_wsgi

Una precisazione, nei repository quando non viene specificata la versione di Python, viene assunto che il modulo è per python 2.7.x.
Successivamente, ricordatevi di riavviare Apache/httpd affinchè le modifiche abbiano effetto.

Permessi sui files

Passiamo adesso alla parte più noiosa, quella delle path e dei permessi.
Assumiamo che il vostro progetto di django si chiami test_app ( visto che fantasia!?) ed è installato nella path /home/foo/test_app/ mentre il virtualenv è installato nella path /home/foo/test_app_env/
Per quanto riguarda i permessi, di solito eseguo le seguenti operazioni:

sudo chmod +x /home/foo/test_app_env/

Il chmod + x sulle cartelle permette di entrare ed accedere ai file e cartelle. Successimavamente lancio:

find /home/foo/test_app_env -type d -exec chmod 755 {} \;
find /home/foo/test_app_env -type f -exec chmod 644 {} \;

Con il primo comando setto i permessi sulle cartelle e con il secondo sui file. In teoria adesso dovremmo essere in regola con i permessi.
E adesso il file di configurazione di VirtualHost che è il cuore del deploy di Django con Apache.

Configurazione di Apache per il deploy di Django


Nelle centos solitamente il file è posizionato in /etc/httpd/conf.d/ mentre sulle debian/ubuntu in /etc/apache2/conf.d/sites-available/ e bisogna usare gli script a2ensite e a2dissite

<VirtualHost *:80>  
ServerName foo.apptecsrl.com  

WSGIScriptAlias / /home/foo/test_app/test_app/wsgi.py 
WSGIDaemonProcess test_app processes=5 python-path=/home/foo/test_app:/home/foo/test_app_env/lib/python3.6/site-packages:/home/foo/test_app_env/lib/python3.6 threads=1 
WSGIProcessGroup test_app 
Alias /static/ /home/foo/test_app/test_app/public/static/ 
Alias /media/ /home/foo/test_app/test_app/public/media/ 
 
<Directory /home/foo/test_app/>  
  AllowOverride all  
  Require all granted  
  Options Indexes FollowSymlinks  
</Directory>  
 
</VirtualHost> 

Nota di merito di questa configurazione base, va alle direttive: WSGIDaemonProcess e ServerName.


ServerName specifica a quale nome risponde la configurazione. Quindi digitando foo.apptecsrl.com vi risponderà la configurazione appena creata.
Configurazioni diverse, con ServerName diversi corrisponsono a siti diversi. (Potete testare la configurazione editanto il file hosts)


WSGIDaemonProcess è la direttiva che specifica quanti demoni distinti devono essere creati. Ad ogni demone viene delegata l’esecuzione dell’applicazione wsgi.
test_app è il display-name dei singoli demoni, process=5 specifica il numero dei demoni che saranno avviati, nel nostro caso saranno 5.
python-path è la lista delle path necessarie per avviare la nostra applicazione. Nel nostro caso abbiamo specificato la path dell’applicazione, la site-packages del virtualenv e il binario dell’interprete.
threads=1 specifica il numero di thread che saranno creati da ogni demone per gestire la richiesta.


Ci tengo a precisare che questa configurazione l’ho usata per anni su un e-commerce con un traffico medio/basso, non ho mai avuto problemi di prestazioni, ma mi rendo anche conto che è una configurazione per niente ottimizzata.