Ceci n'est pas une pipe

Risposta minimalistica ad una domanda minimalistica: come faccio a clonare un server Debian replicandone completamente il software installato?

1) sul server da clonare esporta l’elenco dei pacchetti installati:

dpkg --get-selections > installed-software

2) passalo sul server clone:

scp installed-software pippo@nomeserver.test123.com:~

3) sul server clone importa l’elenco dei pacchetti da installare:

dpkg --set-selections < installed-software

4) sul server clone avvia l’installazione dei pacchetti selezionati:

apt-get dselect-upgrade

That’s all folks!

Chi utilizza RoundCube come applicazione webmail – noi ne utilizziamo una versione nostra con alcuni miglioramenti interessanti – si sarà accorto che la gestione degli allegati avviene in una maniera piuttosto anomala. Per motivi incomprensibili, l’applicazione è stata disegnata ignorando completamente alcuni importanti settaggi del php.ini e di Postfix relativi alle dimensioni dei file allegabili ad un messaggio email:

• vengono completamente ignorati i valori dei parametri upload_max_filesize (=maximum allowed size for uploaded files), post_max_size (=maximum size of POST data that PHP will accept) e memory_limit (=maximum amount of memory a script may consume)  indicati nel file php.ini
• viene completamente ignorato il valore di message_size_limit nel file main.cf di Postfix

Ovviare a questa mancanza però è davvero semplice, è sufficente editare il file /usr/share/roundcube/.htaccess e cambiare a piacimento i valori dei rispettivi parametri:

php_value       upload_max_filesize     20M
php_value       post_max_size           21M
php_value       memory_limit            64M

Tutto qui.

Tra le molte applicazioni disponibili per tenere sotto controllo il consumo di banda di un server ce n’é uno che fa davero bene il suo lavoro: si tratta di vnStat, un network traffic monitor per sistemi BSD e Linux. Questa applicazione si comporta in pratica come un logger che tiene traccia dei volumi di dati in entrata e in uscita attingendo alle informazioni fornite in tempo reale direttamente dal kernel. Ecco quali sono le caratteristiche principali di vnStat così come vengono presentate sul sito web ifficiale del progetto:

• quick and simple to install and get running
• gathered statistics persists through system reboots
• can monitor multiple interfaces at the same time
• several output options
  • summary, hourly, daily, monthly, weekly, top 10 days
  • optional png image output (using libgd)
• months can be configured to follow billing period
• light, minimal resource usage
• same low cpu usage regardless of traffic
• can be used without root permissions
• online color configuration editor

La sua installazione è in effetti molto semplice e immediata, specialmente sui sistemi Debian-derivati:

# aptitude install vnstat

Una volta installato il pacchetto, è necessario inizializzare un database dedicato al logging per ogni scheda di rete che si vuole monitorare. Se si vuole monitorare la scheda eth0, ad esempio, è sufficiente lanciare il comando:

# vnstat -u -i eth0

Fatto questo, per tenere monitorato il traffico su quella specifica scheda di rete è sufficiente lanciare il programma senza alcun argomento:

ivan@biberon:~$ vnstat
Database updated: Fri Jun 24 01:00:01 2011
eth0
received:       4.71 GB (13.0%)
transmitted:    31.58 GB (87.0%)
total:          36.29 GB
                rx     |     tx     |  total
-----------------------+------------+-----------
yesterday      1.74 GB |   11.92 GB |   13.66 GB
today         31.97 MB |  162.10 MB |  194.07 MB
-----------------------+------------+-----------
estimated       720 MB |    3.67 GB |    4.38 GB

E’ possibile generare diverse tipologie di report semplicemente passando al programma l’argomento necessario, ma credo che già l’utilizzo standard indicato sopra possa essere più che sufficiente per le ordinarie operazioni di monitoraggio. Maggiori informazioni le trovate a questi indirizzi:

• http://humdi.net/vnstat/
• http://www.debian-administration.org/articles/330

La versione originale di questo script gira ormai da oltre un lustro su molti dei miei server, almeno su quelli più puri dove ancora bastano una manciata di script nudi e crudi messi in cron per gestire sia il monitoraggio che la manutenzione ordinaria dell’intero sistema. Quello che fa lo script è elementare: interroga il kernel mediante il comando uptime, dal cui output ricava i 3 valori del l0ad average; se questi superano il limite impostato nella variabile $NOTIFY, un messaggio email contenente un breve avviso e l’output del top viene inviato all’indirizzo email impostato nella variabile $EMAIL.

Il valore da assegnare alla variabile $NOTIFY varia da sistema a sistema, spesso individuare quello ottimale per un server non è una operazione del tutto immediata – richiede un minimo di esperienza e senza dubbio almeno un breve periodo di osservazione. Questo per evitare di ricevere un numero eccessivo di warning o, di contro, non ricevere notifiche per eventi che meriterebbero invece un po’ di attenzione. Leggi il resto »

Quelli che hanno la cattiva abitudine di installare le applicazioni web nella document root si trovano  spesso a dover affrontare un fastidioso problema: l’impossibilità di gestire directory e sub-directory estranee all’applicazione a causa delle restrizioni di accesso imposte dal file .htaccess.

L’esempio più tipico è quello del CMS Drupal. Supponiamo di averlo installato e reso completamente accessibile all’URL:

http://www.miodominio.xx/

Il file .htaccess di Drupal controllerà tutto quello che può o non può essere accessibile al di sotto della propria document root, che in questo caso coincide esattamente con la document root del virtual host. Infatti il file .htaccess si trova nella radice del filesystem dedicato a questa applicazione:

http://www.miodominio.xx/.htaccess

In questo modo, se decidiamo di creare una qualsiasi nuova directory, questa subirà le medesime restrizioni scritte nel file .htaccess durante l’installazione di Drupal, come ad esempio l’impossibilità di navigare liberamente tra i suoi file e le subdirectory che essa contiene:

http://www.miodominio.xx/test/

Questa directory non è accessibile in questo modo, ma solo richiamando il nome del file in essa contenuto a cui vogliamo accedere, ad esempio:

http://www.miodominio.xx/test/pippo.html
http://www.miodominio.xx/test/imago.jpg

Se non viene indicato alcun file, viene cercato e mostrato il solo file index.php:

http://www.miodominio.xx/test/index.php

Se il file index.php non esiste, non viene mostrato il contenuto della directory – come molti si aspetterebbero – ma al contrario viene generato un bell’errore 404  (File Not Found).

Per ovviare a questo problema è sufficiente agire sul file .htacces, aggiungendo le istruzioni che rendono la directory /test/ immune da queste regole, immediatamente dopo l’inizializzazione del RewriteEngine:

<IfModule mod_rewrite.c>
RewriteEngine on
#
# ECCO LE DUE RIGHE DI ISTRUZIONI:
RewriteCond %{REQUEST_URI} "/test/"
RewriteRule (.*) $1 [L]
#

Provare per credere.

Un dritta veloce per chi mi ha chiesto un modo per ovviare al timeout delle connessioni SSH. Premetto che si tratta di una situazione sempre più diffusa, dovuta alla configurazione di default dei nuovi di router distribuiti da Telecom per Alice ADSL. Il problema può essere ovviato passando al comando ssh il parametro:

-o ServerAliveInterval=10

Il parametro manda un messaggio di noop al server ogni n secondi (in questo caso: 10) notificando al router che la connessione è di fatto operativa, anche in mancanza di alcun tipo di attività. Dato che non è comodissimo digitarlo ogni volta, è possibile aggiornare il proprio file .bashrc con un alias che incorpori l’opzione nel comando base:

alias ssh="ssh -o ServerAliveInterval=10"

Questo è quanto

Segnalo a tutti i pischelli che per deprecabili motivi anagrafici non la conoscono un’opera che per quelli della mia generazione ha rappresentato una vera e propria icona pionieristica dello spirito Free Software in Italia. Si tratta della ormai mitica raccolta di appunti collezionati e pubblicati sistematicamente da Daniele Giacomini a partire dal 1997.  Denominata inizialmente “Appunti di Linux”, dal 2000 ha preso il nome di “Appunti di Informatica Libera” e copre in maniera semplice ed estremamente empirica una vasta gamma di argomenti, dai concetti più elementari alla compilazione di sorgenti in vari linguaggi – sì, ci sono anche istruzioni piuttosto dettagliate circa la compilazione del kernel Linux.

Anche se il sito web istituzionale risulta da tempo irraggiungibile, sopravvive una ultima copia dell’opera aggiornata al 27 novembre 2008 all’indirizzo:

http://a2.pluto.it/a21.htm

Trovo che gran parte delle informazioni conservate in questi appunti siano ancora estremamente utili, specie per chi si appresta ad affrontare il mondo dell’open source per la prima volta.

UPDATE! Mi hanno segnalato la disponibilità di una versione molto più aggiornata degli Appunti di Informatica Libera in vari formati: TXT, HTML, PDF, etc. Potete trovarli a questo indirizzo, pronti per il download:

http://appuntilinux.mirror.garr.it/mirrors/appuntilinux/2009.11111/

Mi capita sempre più spesso di dovere effettuare backup di partizioni Linux installate su SD card e di doverle ripristinare su altre SD. Il tutto rientra in un progetto molto interessante in cui un microserver basato su Linux gestisce una serie di funzionalità di rete amministrabili da un backoffice accessibile da LAN, WAN e WLAN. Lo sviluppo di questa soluzione necessita di repliche su microserver di backup e su vari altri dispositivi benchmark. Dato che ripeto questa procedura almeno 2 volte al giorno, la registro qui perché possa essere di pubblica utilità.

Per backuppare l’intero filesystem dalla SD card pluggata al mio PC con un adattatore USB, uso il comando:

dd if=/dev/sdb | gzip -c9 > ./backup_sdb.gz

Parafrasando: copia l’intero filesystem della device /dev/sdb nel file gzippato “backup_sda.gz”. Occhio quindi ad indicare la corretta device nel caso in cui sul vostro server/PC non sia sdb!

Per ripristinare il tutto, eseguo l’operazione complementare:

gunzip -c ./backup_sdb.gz | dd of=/dev/sdb

Se avete dubbi o domande, chiedete e vi sarà risposto. Non prima di avere consultato “man dd”, però…

Una delle domande più frequenti che mi vengono rivolte dai nuovi aspiranti sysadmin Linux riguarda il significato dei nomi delle “cartelle” – così purtroppo ancora le chiamano. Si riferiscono a quelle directory di sistema comuni alla famiglia di sistemi operativi derivati dal mitico 4.4BSD. Ebbene, per tutti coloro che non riescono a dormire la notte chiedendosi cosa possano mettere e cosa no in directory come /var, /usr/lib, /etc e /opt… la risposta ufficiale e autorevolissima è contenuta in questo PDF:

• Filesystem Hierarchy Standard 2.3

RTFM a tutti!

Uno dei comandi più utilizzati quando si amministra un server UNIX o Linux da linea di comando è senza dubbio `grep`. Per chi non lo conoscesse, mi limito a dire che si tratta di uno script efficiente e flessibilissimo in grado di individuare espressioni regolari all’interno di un file o di un output testuale. Il nome del comando è infatti acronimo di “global regular-expression print”. Tutto il resto lo trovate con il solito `man grep`. Per chi invece usa abitualmente grep per i task di amministrazione di ogni giorno, raccolgo qui una serie di esempi d’uso un po’ più evoluti e – magari – insoliti. Potrebbero essere utili a voi come lo sono stati a me in numerose occasioni.

Trova le ricorrenze della sequenza qui, quo AND qua in file.txt:
grep "qui.*quo.*qua" ./file.txt

Trova le ricorrenze di qui OR quo OR qua in file.txt:
grep -P 'qui|quo|qua' ./file.txt

Verifica che un indirizzo email sia formattato correttamente:
echo "info@test.eu" | grep -Ei '\b[a-z0-9]{1,}@*\.(it|eu|com|net|org|tv)\b'

Trova la parola qua in modalità case in-sensitive in ./file.txt:
grep -iw "is" demo_file

Trova gli indirizzi email in test.txt formattati come <qwerty.qwerty@qwerty.com> e rimuove i caratteri di enclosure (< e >):
grep -o '<.*@.*\.*>' ./test.txt | tr -d '<>'

Trova le ricorrenze multiple di qui OR quo OR qua in una stringa di testo:
echo -e "1) qui quo qua\n2) quo qui qua\n3)qui quo qui\n4) qua quo qui\n" | grep -E '(qui|quo|qua).*\1'

Verifica se la stringa passata mediante pipe sia un indirizzo IP o meno (provate passando un indirizzo IP mal formato):
echo "192.168.123.123" | grep -E '\b((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b'

Mostra tutte le righe dell’httpd.conf omettendo le istruzioni commentate:
grep -v -E '^\#|^$' /etc/apache2/httpd.conf

Supponendo che lo script test.sh contenga le seguenti istruzioni:

#!/bin/bash
contatore=1
until [ $contatore -gt 10 ]; do
echo contatore $contatore
let contatore+=1
done

… il comando che segue individua la riga 4 e le 3 righe che seguono:

./test.sh | grep -A 3 -i "contatore 4"

… il comando che segue individua invece tutte le righe tranne quelle contenenti il 4 e il 6:

./test.sh | grep -v -e "4" -e "6"

Il sito Internet ufficiale del progetto grep si trova all’indirizzo http://gnu.org/software/grep/.