Michele Bologna

Tag: apache

  • django: come fare il deploy di un’applicazione su Apache

    Una volta che avete terminato lo sviluppo di un’applicazione basata su django, è il momento di installarla in produzione. Nel mio caso, ho utilizzato django 1.3.1 e ho scelto di utilizzare Apache e mod_wsgi. Vediamo come fare il deploy passo-passo:

    • Fortunatamente mod_wsgi richiede Apache mpm-worker (anziché il meno performante prefork) che su Debian/Ubuntu è facilmente installabile tramite sudo apt-get install libapache2-mod-wsgi
    • Spostiamo l’applicazione sotto un path di sistema, tipo /usr/share/app
    • Aggiungere a /etc/httpd.conf la direttiva WSGIScriptAlias / /usr/share/app/django.wsgi dove il primo parametro (/) rappresenta il path a cui django dovrà rispondere (in questo caso la root), mentre il secondo parametro rappresenta un file che scriveremo nel prossimo step, e che descrive a WSGI come interpretare l’applicazione django che abbiamo scritto
    • Aprite il file che abbiamo definito al punto precedente (django.wsgi) e inserite il seguente codice Python:
      “`
      import os
      import sys
      import django.core.handlers.wsgipath = '/usr/share/app'
      if path not in sys.path:
      sys.path.append(path)

      os.environ['DJANGO_SETTINGS_MODULE'] = 'app.settings'

      application = django.core.handlers.wsgi.WSGIHandler()
      “`

      Ricordatevi di settare correttamente il path e i settings (che corrisponde al settings.py di django)

    • Riavviare apache: service apache2 restart

    Aprite il browser andando a settare l’URL in corrispondenza di quanto definito al punto 1 di questo tutorial (il context-path) e controllate che sia tutto a posto (diversamente, controllate l’error log di Apache).
    Una soluzione aggiuntiva sarebbe quella di introdurre un reverse proxy (scelta personale: nginx) davanti ad Apache per servire i files statici (js, css, png, etc.). Ma questo sarà un altro post.

  • Munin e phpSysInfo: monitorare server remoti tramite un’interfaccia web

    Monitorare dei server remoti è un’attività che richiede tempo, capacità e gli strumenti corretti. Per monitorare quotidianamente alcuni server aziendali che amministro, ho recentemente scoperto due comodi strumenti a cui si accede tramite interfaccia web (e di conseguenza molto comodi): si tratta di phpSysInfo e di munin.

    Come si evince dal nome, phpSysInfo si basa su PHP (e quindi vi obbligherà ad utilizzare apache-prefork anziché il più performante apache-mdm-worker). L’interfaccia di phpSysInfo è molto semplice e riassuntiva, presentando le informazioni principali del sistema (CPU, RAM utilizzata, occupazione dei vari file-system) in una schermata pulita e ordinata.

    munin invece è più complesso, ma anche più potente: si presenta come una serie di grafici che rappresentano il comportamento di tutti i principali componenti di sistema e le grandezze di sistema (numero di processi attivi, % dei processi attivi e sleeping, etc.). Ogni quantità viene rappresentata su un grafico giornaliero e su un grafico settimanale. Munin è scritto in Perl, ed è sicuramente più dettagliato ed approfondito. Inoltre, è possibile estendere le funzionalità di munin grazie ai plugin.

    In caso di problemi, però, non è possibile sfruttare nessuna delle due interfacce qui esposte: dovremo quindi ricorrere ad uno strumento “attivo” (come ssh, vnc, o Teamviewer) per apportare le modifiche necessarie.

    munin e phpSysInfo sono disponibili per tutte le distribuzioni Linux.

  • Apache: come nascondere il banner contenente la versione, il packaging, etc. [ServerTokens]

    Ispirato dalla filosofia “security by obscurity” [sicurezza tramite segretezza], ho sempre avuto l’abitudine di limitare le informazioni rivelate dai server Apache che amministro. Solitamente (= di default), Apache rivela le seguenti informazioni:

    • Versione, major build [1, 2]
    • Packaging [Ubuntu, Fedora, etc.]
    • Eventuali moduli installati [mod_security, mod_python, etc.]
    • Versione estesa [2.0.47]

    Un po’ troppe per i miei gusti… Quindi limito la quantità di informazioni che Apache rivela al mondo in questo modo [istruzioni personalizzate per Ubuntu]:

    • Diventando root, modificate il file /etc/apache2/conf.d/security
    • Andate alla riga ServerTokens: # ServerTokens
      # This directive configures what you return as the Server HTTP response
      # Header. The default is 'Full' which sends information about the OS-Type
      # and compiled in modules.
      # Set to one of:  Full | OS | Minimal | Minor | Major | Prod
      # where Full conveys the most information, and Prod the least.
      #
      ServerTokens Minimal

      Come vi viene spiegato, potete scegliere il livello di granularità delle informazioni rivelate, andando da Full (che rivela tutte le informazioni possibili) fino a Prod, che non rivela quasi nulla (solo che usate Apache). Sui miei server, di solito, scelgo una via di mezzo e di conseguenza imposto ServerTokens a Minimal.

    • Salvate e riavviate Apache: sudo /etc/init.d/apache2 reload

  • Apache: bloccare determinati IP usando .htaccess

    Se il vostro hosting vi fornisce una piattaforma Apache, allora è possibile bloccare la visione del vostro sito a determinati IP (ad esempio per questioni di spam o privacy – sicuramente se vi siete imbattuti in questa pagina sapete perché li volete bloccare).

    Vediamo come possiamo bloccare questi IP:

    • creiamo un file .htaccess;
    • scriviamo le seguenti righe nel file appena creato:

      • allow from all
      deny from 111.222.222.2
      deny from 1.2

    • facciamo l’upload del file nella root del proprio sito

    In questo caso blocchiamo tutte le richieste provenienti dall’indirizzo IP 111.222.222.2 e dalla sottorete 1.2/16. È sufficiente aggiungere ogni IP (o ogni sottorete) che vogliamo bloccare su una nuova riga, seguendo il pattern mostrato.

    Quando questi IP cercheranno di visualizzare il vostro sito, otterranno una pagina HTTP 403 (Access Forbidden).
    Altri possibili utilizzi del file .htaccess si possono trovare qui.

    • Apache Ant: Unable to locate tools.jar

      Se Ant si rifiuta di eseguire uno script di compilazione restituendo l’errore “Unable to locate tools.jar.” procedete in questo modo:

      • create la variabile d’ambiente JAVA_HOME (su Windows: Risorse del computer -> Proprietà -> Avanzate -> Variabili d’ambiente -> Nuovo)
      • impostate il valore di tale variabile al PATH del JDK (dipende dal vostro sistema, nel mio caso: C:\Programmi\Java\jdk1.6.0_03)