Come Gestire i Log su Linux con Syslog

Una necessità primaria dei sistemi di produzione è la raccolta e la gestione dei log.

Sempre di più i log vengono generati in enorme quantità e quando l’infrastruttura cresce oltre un certo livello diventa fondamentale passare ad un sistema che ne gestisca la centralizzazione.

Su Linux generalmente si usa una qualche versione del demone syslog (su ubuntu ad esempio ci sono tre opzioni dsyslog, rsyslog, syslog-ng) a questo scopo. Questi sistemi si occupano sia della gestione locale dei log sia della loro eventuale centralizzazione e mettono a disposizione strumenti per filtrare le informazioni più importanti o per integrarsi con sistemi di monitoraggio come nagios o con sistemi di reportistica come logstash. La scelta di un file come repository finale dei dati non è obbligata ma questi sistemi permettono di passare i dati a molti altri tipi di repository.

Farò riferimento per i dettagli a syslog-ng.

Conviene immaginare questi sistemi come a gestori di flussi di informazioni nei quali ci sono dei punti di entrata (un server apache ad esempio), delle regole di elaborazione più o meno complesse e dei punti di uscita (tipicamente un file, altri server syslog nei sistemi centralizzati, database etc..). La configurazione rispecchia questa prospettiva.

Una volta definiti delle opzioni generali si definisco le sorgenti dei log. Questa ad esempio raccoglie le informazioni che tipicamente finiscono sui log standard di sistema.

source s_src { unix-dgram(“/dev/log”); internal();
file(“/proc/kmsg” program_override(“kernel”));
};
Altre tipiche sorgenti di dati saranno delle porte in ascolto su protocolli udp o tcp

source s_udp_apache {
udp(ip(0.0.0.0) port(8515));
};
source s_tcp_apache {
tcp(ip(0.0.0.0) port(8515));
};
utili sia per la costruzione di sistemi gerarchici che permettano la centralizzazione dei log sia come sistema semplice per separare su molti canali i log.
Tra le possibili sorgenti ci sono anche i file

source s_apache_access {file(“/var/log/apache2/access.log” log_fetch_limit(100) log_iw_size(1000)); };
utili ad esempio per raccogliere i log anche di sistemi che hanno solo questa.

Il secondo elemento chiave della configurazione sono le destinazioni dei flussi di log. Anche in questo caso è possibile inviare i log su di un file locale, su un canale tcp o udp nel caso di sistemi gerarchici per la gestione di log.

destination d_auth { file(“/var/log/auth.log”); };
destination d_udp_system { udp(vip-syslog.de.prod port(8514));};
destination d_tcp_system { tcp(vip-syslog.de.prod port(8514));};
Ci sono molte possibili altre destinazioni tra cui stream unix, o mongodb.

Il terzo elemento della configurazione è filter. Come il nome lascia intuire questo elemento serve a definire delle regole per selezionare un sottoinsieme dellerighe in arrivo. L’elemento tradizionale per suddividere i log è la selezione della facility, ma filter permette di agire su svariati elementi tra cui l’host di invio, il livello del messggio (notice, warn, error…) appositi tag assegnati alla riga di log o anche regular expression sul contenuto.

filter f_err { level(err); };
filter f_mail { facility(mail) and not filter(f_debug); };
I vari elementi della configurazione devono essere poi combinati con un’ultimo elemento della configurazione:

log { source(s_src); filter(f_auth); destination(d_auth); };
log { source(s_apache_extranet); destination(d_apache_extranet); flags(flow_control); };
La combinazione di questi elementi permette una grande flessibilità nella gestione del log. Tornerò su questo tema per approfondirne il filtraggio ed altre opzioni.

Approfondisci

Come Proteggere una Rete WiFi

Dopo avere visto come configurare il nostro router per l’accesso in rete, sia in modalità cablata che Wireless, è arrivato il momento di vedere come proteggere tale connessione, in modo che altri utenti, alla portata della nostra connessione Wireless, possa intrufolarsi nella nostra rete e dunque utilizzarla per navigare gratuitamente, a nostra insaputa, e quindi avere un sovraccarico non autorizzato di banda internet.

Una volta configurato il router, accedere alla rete tramite Wireless è piuttosto semplice, basta infatti cliccare sull’icona di connessione senza fili presente nella tray icon di Windows (accanto l’orologio), cliccandoci su scandiremo la rete alla ricerca di punti d’accesso, quindi una volta identificato il nostro router basta un click per avviare il collegamento, e dunque attivare la connessione ad internet.

Ovviamente tutto questo è fattibile anche da un qualsiasi utente esterno, per tale ragione è necessario proteggere la rete utilizzando uno dei diversi metodi di protezione disponibili.

Per attivare una protezione è necessario accedere alla pagina di configurazione del nostro router, quindi, come abbiamo visto nell’articolo su come configurare il router, bisogna aprire il browser e dunque digitare l’indirizzo del router.

Ricordo che la schermata di configurazione varia da router a router, quindi le schermate visualizzate di seguito potrebbero essere differenti.

L’opzione per attivare una protezione si trova generalmente nelle impostazioni wireless.

Una volta identificata dobbiamo scegliere un’opzione di protezione tra:

WEP (Wired Equivalent Privacy)
WPA-PSK (Wi-Fi Protected Access Pre-Shared Key)
WPA2-PSK (Wi-Fi Protected Access 2 Pre-Shared Key)
Mista: WPA-PSK+WPA2-PSK
WPA-802.1x

La protezione WEP è più diffusa e compatibile, per tale ragione è anche la più attaccata e quindi soggetta ad essere infranta, la WPA2 è un ottima soluzione, tuttavia non tutti i dispositivi sono compatibili soprattutto alcune console di gioco, quindi alla fine l’unica soluzione è andare per tentativi.

Una volta scelta l’opzione di protezione dobbiamo digitare la chiave vera e propria, questa deve contenere da un minimo di 8 caratteri ad un massimo di 63 caratteri alfanumerici, inutile dire che più caratteri utilizziamo e più sarà sicura la nostra chiave.

Una volta impostata la chiave applichiamo le impostazioni e, se richiesto, riavviamo il router.

A questo punto la nostra connessione è finalmente protetta, questa volta, cliccando sul punto d’accesso Wireless relativo alla nostra connessione, Windows ci chiederà il codice di protezione, immettendolo potremo accedere alla rete e dunque navigare, chiunque tenti di connettersi al nostro router verrà accolto da una bella richiesta di codice, che ovviamente non avendolo, non potrà connettersi.

Approfondisci

Come Fare Backup su Linux con Rsync

Avere una politica di backup che ci permetta di limitare i danni in caso di errori o problemi è una necessità che risale all’origine dell’informatica.

UNIX e Linux hanno ovviamente diversi tool che vengono in aiuto per questa necessità, e, almeno nel caso di una macchina singola, si possono implementare delle politiche asolutamente soddisfacenti con soli tool interni come cron ed rsync.

Come molti comandi della shell UNIX rsync è estremamente versatile. Il comando di base è:

rsync /path/to/source/file /path/to/destination
Come suggerisce il nome rsync non è un semplice tool per la copia dei file ma si occupa di sincronizzare due directory effettuando la copia dei soli file che lo richiedono.

Tendenzialmente rsync è utile soprattutto se si ha la necessità di copiare molti file e quindi sarà necessario utilizzare l’opzione -r

rsync -r /path/to/source/ /path/to/destination
rsync -r /path/to/source /path/to/destination
Ho riportato due comandi per sottolineare una particolarità di rsync. Se si copia una directory e si specifica / nel path della sorgente il contenuto della directory verrà copiato nella destinazione; se invece il path viene scritto senza / è la directory che viene copiata nella destinazione.

Rsync generalmente non ha quasi nessun output a video, il che è ottimo per script in crontab, se però si sta eseguendo il backup in real time si vorrà probabilmente un’indicazione di come sta procedendo l’attività. PEr questo si hanno due opzioni -v e –progress.

rsync generalmente controlla le dimensioni e la data di ultima modifica per capire se devono essere copiate. Sono però disponibili specifiche opzioni per fare controlli differenti. Ad esempio –size-only se si vole considerare solo le dimensioni del file o –checksum se si vuole un conformto più affidabile anche se più oneroso.

Le opzioni di questo comando sono svarite ma generalmente se si stanno effettuando dei backup -a farà si che vengano attivate le opzioni che più comunemente vengono utilizzate per questa attività.

Una mensione particolare merita l’opzione -b; in questa modalità rsync effettuerà un backup incrementale spostando i file rimossi dalla sorgente in un appositp path e scrivendo su un file tutte le operazioni effettuate. Si otterrà quindi una directory allineata a quella sorgente e si manterranno i file e le informazioni necessari per ricostruire la situazione al momento del backup precedente.

Un esempio di comando reale potrebbe quindi essere

rsync -avb –size-only –delete –log-file=/path/to/file_log/file.log –backup-dir=/path/to/directory_file_incrementali/ –progress /directory/source/ /directory/destination/

Approfondisci

Come Controllare i Processi su Linux con Supervisord

Parliamo oggi di supervisord, un sistema di controllo dei processi. Questi sistemi hanno la funzione di garantire che altri processi siano costantemente attivi. Possono essere quindi elementi importanti per garantire l’affidabilità di un servizio soprattutto nei casi in cui il daemon da controllare è sviluppato in casa e da, quindi, molta meno affidabilità di un daemon con migliaia di istallazioni.

Il primo passo è, come sempre, istallare supervisord. Lo possiamo fare dal sito del progetto o utlizzando il sistema di pacchetti della propria distribuzione. Su Debian o Ubuntu:

aptitude install supervisor
Ad istallazione effettuata si avrà il demone supervisord e il tool di controllo supervisorctl. Inoltre il demone può essere configurato per rispondere a chiamate html (di default sulla porta 9001) sia per monitoraggio via browser sia per gestione tramite API xml-rpc.

Per prima cosa esaminiamo la configurazione di default che arriva con il pacchetto Ubuntu:

; supervisor config file

[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)

[supervisord]
logfile=/var/log/supervisor/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log/supervisor ; (‘AUTO’ child log dir, default $TEMP)

; the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket

; The [include] section can just contain the “files” setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files *cannot*
; include files themselves.

[include]
files = /etc/supervisor/conf.d/*.conf
Come avviene in moltissimi casi i parametri di configurazione sono raggruppati in paragrafi.

[unix_http_server]: contiene i parametri necessari a definire il socket unix per le connessioni a supervisord.
[supervisord]: configurazione vera e propria del daemon; file di log, file di lock.
[rpcinterface:supervisor]: serve ad abilitare l’interfaccia rpc
[supervisorctl]: parametri passati usati al client; ad esempio come connettersi al server se non specificato altrimenti
[include]: un elenco di file da includere. Tipicamente uno per ogni tipo di daemon da controllare con le specifiche direttive.
Come prima cosa attiviamo l’interfaccia web abilitando un’utenza ed una password. Aggiungiamo o modifichiamo quindi il paragrafo inet_http_server con i seguenti valori:

[inet_http_server]
port = 127.0.0.1:9001
username = user
password = 123
e riavviamo il daemon

/etc/init.d/supervisord restart
Possiamo ora accedere all’interfaccia web connettendoci in localhost sulla porta 9001 ed inserendo i dati dell’account quando richiesti.

Creiamo ora uno script che utilizzeremo come daemon di test e configuriamo supervisord per gestirlo.

Editiamo quindi un file denominato test_supervisord.sh con il nostro editor di riferimento ed inseriamoci il seguente codice:

#!/bin/sh
while [ true ]; do
ls -lh /tmp/
rm /tmp/pippo
touch /tmp/pippo
sleep 5
done
cambiamo poi i permessi per renderlo eseguibile

chmod 700 test_supervisord.sh
Creiamo ora la configurazione su supervisord per dirgli di gestire questo daemon. Andremo ad inserire nel file /etc/supervisor/conf.d/test.conf il seguente contenuto

[program:test_supervisord]
command=/tmp/test_supervisord.sh
autostart=true
autorestart=true
stderr_logfile=/var/log/supervisor/test.err
stdout_logfile=/var/log/supervisor/test.log
dove, in un apposito paragrafo specifichiamo

[program:test_supervisord]: il nome del daemon da riportare sui vari report
command=/tmp/test_supervisord.sh: il comando da eseguire
autostart=true: se deve partire automaticamente all’avvio
autorestart=true: se deve essere riavviato in caso di interruzione
stderr_logfile=/var/log/supervisor/test.err: file di log in cui viene registrato l’output del daemon
stdout_logfile=/var/log/supervisor/test.log file di log in cui vengono riportato lo standard error del daemon
I parametri specificabili sono molti altri. Ad esempio

user: permette di specificare l’utente con cui il daemon viene eseguito
environment: accetta coppie chiave-valore che vengono trasformate in variabili di ambiente per l’esecuzione del daemon.
Per rendere attiva la nuova configurazione si può procedere con uno tra

kill -HUP “PID”
supervisorctl reread && supervisorctl update
o anche attraverso l’interfaccia web visto che l’abbiamo attivata.

supervisorctl rimane comunque l’interfaccia di eccellenza di questo sistema.

Al suo avvio presenta l’elenco dei demoni configurati ed il loro stato. Ed il comando help mostra cosa può essere fatto all’interno di questa command line.

root@nb:/etc/supervisor/conf.d# supervisorctl
test_supervisord RUNNING pid 8443, uptime 0:03:40
supervisor> help

default commands (type help ):
=====================================
add clear fg open quit remove restart start stop update
avail exit maintail pid reload reread shutdown status tail version

supervisor>
stop, start, restart e status serviranno ad esempio a gestire i vari daemon. reread e update li abbiamo già visti in azione. Quit permette di lasciare questa shell.

Approfondisci

Come Funziona il Database Redis

Nell’ articolato panorama dei database nosql riveste un certo interesse Redis. Questo database ancora immaturo per gli aspetti di scalabilità e di alta affidabilità è sicuramente interessante per le prestazioni.

Redis, generalmente indicato come respository chiave/valore, è in realtà in grado di gestire 5 tipi di dato differente ognuno adatto ad ottimizzare le prestazioni di specifiche operazioni. Redis fa infatti della velocità il suo punto di forza.

In Redis possono essere immagazzinati:

stringhe
hash
liste
set
sorted set
Redis dispone anche della possibilità di scrivere delle stored procedure in LUA.

Questo database lavora mantenendo tutti i dati in memoria ma al tempo stesso è in grado di garantire la persistenza dei dati attraverso due meccanismi, entrambi disattivabili:

il salvataggio periodico del dataset su disco triggerabile sia su base temporale sia sulla base del numero di modifiche
la produzione di log delle modifiche
Redis dispone inoltre di un sistema di replica che permette di generare copie di un repository a caldo. Ci sono poi altri tool legati alla clusterizzazione ma che al momento attuale non sono in verisone stabile.

Per un’istallazione di test la via più comoda è come sempre ricorrere ai pacchetti della propria distribuzione:

aptitude install redis-server
Su debian è opportuno ricorrere ai pacchetti di backport visto che come tutti i sistemi nosql, Redis è un prodotto piuttosto giovane e ci sono spessp importanti fix nelle nuove versioni.

Sul manuale del prodotto sono riportate due considerazioni di cui è meglio tener conto:

è bene che il server disponga di molto swap perché in alcune situazioni Redis arriva anche a raddoppiare l’uso della memoria e nel caso questa finisca il kernel va in protezione ed uccide il processo.
Redis ha problemi con l’uso standard di Linux della memoria virtuale; viene quindi consigliato di impostare ad uno vm.overcommit_memory
Redis può essere fatto lavorare in una modalità analoga a quella di una cache impnendogli di sovrascrivere i TTl degli oggetti se si presenta la necessità di liberare memoria.

Con il pacchetto viene istallato anche un client

redis-benchmark
redis-cli
Il primo permette una prima verifica del funzionamento del sistema e da un’idea delle prestazioni del sistema. Il secondo è un client che permette di interrogarlo.
Ovviamente l’accesso più naturale ad un sistema di questo tipo sono le librerie di qualche linguaggio.

Ad ogni modo una volta dentro si possono ottenere informazioni sullo stato del daemon con il comando info:

$>redis-cli
redis 127.0.0.1:6379> info
oppure si possono gestire i dati con i molti comandi possibili:

redis 127.0.0.1:6379> set nome:pippo ‘{“città”: topolinia, “razza”: cane}’
redis 127.0.0.1:6379> get nome:pippo
get e set sono alcuni dei comandi relativi alle stringe. Per la gestione di altri tipi di dati ci sono i comandi relativi.

Approfondisci