redis – nosql repository

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.

 

Primi passi in IPv6

Questo articolo lo sto scrivendo connesso all’IP

2001:41d0:1:1b00:94:23.64:3

. Quello che si ottiene con un

dig -t AAAA linuxandcompany.it

Non è mica poco!

Alla fine cercando in rete ho trovato che da rete Fastweb è piuttosto semplice, anche se le informazioni è stato necessario metterle insieme da più fonti.

Prima di tutto l’IPv6 non è nativo ma la rete fastweb, come riportato qui, contiene il server

tsp.ipv6.fastweb.it

che permette di fare un tunnel verso la rete IPv6.

Per usare questo client si piò utilizzare il client gogoc sviluppato in gogo6. Da sito si scaricano solo i sorgenti e almeno sulla mia versione di ubuntu la compilazione non va a buon fine ma ho scoperto che il client è tra i pacchetti di ubunto e si chiama gogoc; basta quindi un

aptitude install gogoc

L’ultimo step è inserire qualche dato in

/etc/gogoc/gogoc.conf

ovvero

server=tsp.ipv6.fastweb.it
auth_method=anonymous

Dopo di che

/etc/init.d/gogoc start
/etc/init.d/gogoc status
ip add sh

saranno sufficienti per attivare il tunnel IPv6 e per verificarne lo stato.

Potremo poi verificare l’avvenuta attivazione dai siti

http://test.ipv6.fastweb.it/
http://www.ipv6.fastweb.it/

Se si ha poi un qualche tool che visualizza l’IP del sito che si sta visualizzando sul browser, e si naviga dopo averlo riavviato, si cominceranno a vedere molti accessi su questo protocollo di trasporto, che ha priorità più alta. Dovreste vederlo su linuxandcompany.it ma anche su qualche sito minore come www.google.com.

djbdns dns server: dnscache

Il mondo dei server DNS è sicuramente dominato da bind in ambito linux ma esistono altri prodotti interessanti soprattutto se la necessità non è quella di dare il servizio DNS su internet.

Trovo particolarmente interessante djbdns. Questo daemon è stato sviluppato da D.J. Bernstein, autore, tra l’altro, anche di qmail. La caratteristica più interessante di djbdns è quella di separare in tre daemon differenti tre funzionalità differenti generalmente unificate sotto un’unico daemon:

  • caching DNS: dnscache
  • authoriting delle zone: tinydns
  • trasferimento di zone: axfrdns and axfr-get

Di questi il più utile secondo me è dnscache che, essendo un sistema estremamente leggero è ideale per essere istallato e ridurre il carico di lavoro di tutti quei server che hanno la necessità di gestire un elevato numero di connessioni che giungono da svariati IP.

Djbdns richiede due software: daemontools e ucspi-tcp. Questi li istalliamo da pacchetto.

aptitude install daemontools
aptitude install ucspi-tcp

djbdns non è però presente sulla distribuzione debian. Scarichiamo quindi i sorgenti. La compilazione richiede i pacchetti make, gcc

 wget http://cr.yp.to/djbdns/djbdns-1.05.tar.gz
tar -zxvf djbdns-1.05.tar.gz
cd djbdns-1.05
echo gcc -O2 -include /usr/include/errno.h > conf-cc
make
make setup check

L’autore richiede poi di segnalare l’avvenuta istallazione con

( echo 'First M. Last'; cat `cat SYSDEPS` ) \
| mail djb-sysdeps@cr.yp.to

Passiamo ora alla configurazione del servizio. Come sempre non è il caos di di far girare dei daemon come root; aggiungiamo quindi due utenti al sistema inserendo nel file */etc/passwd*

dnscache:x:999:999::/dev/null:/usr/sbin/nologin
dnslog:x:998:999::/dev/null:/usr/sbin/nologin

e al file /etc/group

dnscache:x:999:

Prepariamo la configurazione di base

dnscache-conf dnscache dnslog /etc/dnscache 127.0.0.1

Con questo comando abbiamo generato la configurazione in /etc/dnscache specificando che l’utente che dovrà eseguire il daemon sarà dnscache, che i log saranno gestiti dall’utente dnslog e che il daemone sarà in ascolto sull’IP 127.0.0.1.

La directory creata conterrà 5 sottodirectory: env, log, root, run e seed. In particolare env e root contengono le configurazioni vere e proprie e log i log. Vedremo qualche dettaglio in seguito.

Occupiamoci ora dell’avvio del sistema. Vogliamo sfrutatre i daemontools e per farlo dovremo far si che svscanboot venga avviato all’avvio del sistema attraverso i meccanismi della distribuzione che stiamo utilizzando. Per le finalità di questo tutorial ci accontentiamo di lanciarlo a mano:

mkdir /etc/service/
cd /tmp/
nohup svcscanboot &

Il sistema dei daemontools si aspetta una directory in /etc/service per ogni servizio da gestire e monitorare. Aggiungiamo quindi la nostra cache dns

ln -s /etc/dnscache /etc/service/dnscache

Dopo qualche secondo il daemon sarà avviato

svstat /etc/service/dnscache/

ci restituirà il tempo di esecuzione e il PID del demone.

Interessanti un paio di *ps*

root@debian:/tmp# ps aux|grep sv
root      7605  0.0  0.0   4180   580 pts/0    S    22:24   0:00 /bin/sh /usr/bin/svscanboot
root      7607  0.0  0.0   4120   460 pts/0    S    22:24   0:00 svscan /etc/service
root@debian:/tmp# ps aux|grep dns
root      7609  0.0  0.0   3948   316 pts/0    S    22:24   0:00 supervise dnscache
dnslog    7611  0.0  0.0   4092   468 pts/0    S    22:24   0:00 multilog t ./main
dnscache  7612  0.0  0.1   5484  1492 pts/0    S    22:24   0:00 /usr/local/bin/dnscache

che mostrano tutti i processi coinvolti. Notare che la gestione dei log è fatta attraverso un daemon separato e infatti si troverà all’interno della directory log in /etc/dnscache una directory *service* esattamente come in */etc/dnscache*.

Per fermare e riavviare dnscahe si può ricorrere a

svc -d /etc/service/dnscache
svc -u /etc/service/dnscache

o anche a un più brutale kill del daemon dnscache: ci penseranno i daemontools a riavviarlo.

Per meglio gestire le zone interne o se si vuole sfruttare qualche dns interno si consideri che in /etc/dnscache/root/servers si possono aggiungere file, denominati come un dominio e contenenti una lista di DNS interrogabili per quel dominio. Ad esempio con:

cd /etc/dnscache/root/servers
echo 213.251.188.150 > linuxandcompany.it
echo 213.251.128.150 > linuxandcompany.it
svc -d /etc/service/dnscache
svc -u /etc/service/dnscache

posso dire alla cache dove di preferenza deve rivolgersi per le risoluzioni del dominio di questo sito.

Questa directory contiene di base un file denominato @ in cui è contenuta la lista dei root dns di internet.

Awstats e analisi dei log

Generalmente l’analisi del traffico sui siti web viene fatto strumenti sul genere di google analytics che si basano su chiamate dei client, generate da javascript, a siti di terze parti che si occupano della raccolta e della reportistica dei dati.

I server web generano però enormi quantità di log che contengono molti dettagli su tutte le attività del sito web. Nel caso di problemi specifici gli strumenti per analizzarli sono i vari tool della shell e il magari il perl ma se quello che si vuole è monitorare l’andamento del sito la cosa migliore è ricorrere a tool specifici. Uno dei tool storici per questa attività in ambiente LAMP è awstats.

Awstats è un insieme di scripts che si occupa di analizzare i log che gli vengono serviti e genera dei report fruibili poi attraverso un server web. Awstats è in grado di lavorare molti tipi di log che spaziano da quelli di svariati tipi di web server (come Apache o anche IIS) a quelli di ftp server o mail server.

Awstats non è il solo tool e loro stessi riportano una tabella di comparazione con altri prodotti analoghi.

Passiamo ora ad esaminare come configurare awstats. Come iare sempre non troverete qui una guida completa ma un punto di partenza per poter iniziare ad esplorare le potenzialità di questo prodotto.

La prima cosa è ovviamente istallarlo. Anche awstats è presente in gran parte delle distribuzioni. Su debian/ubuntu potrete quindi procedere con:

aptitude update
aptitude search awstats
aptitude install awstats apache2

Alternativamente dal sito di awstats è possibile effettuare il download dell’ultima versione stabile.

Se si procede da pacchetto si avranno a questo punto nella directory

/usr/share/doc/awstats/examples

molti file di esempio utili.

Iniziamo ora dalla configurazione di apache necessaria per la visulizzazione dei report: bisogna infatti istruire apache a mostrare i report aggiungendo ad un vhost le seguenti direttive:

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
</Directory>

Alias /awstatsclasses "/usr/share/awstats/lib/"
Alias /awstats-icon "/usr/share/awstats/icon/"
Alias /awstatscss "/usr/share/doc/awstats/examples/css"
ScriptAlias /awstats/ /usr/lib/cgi-bin/
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch

E’ necessario poi riavviare apache.

Passiamo ora all’anailsi dei file. Cominciamo facendo una copia del file /etc/awstats/awstats.conf rinominandolo in awstats.linuxandcompany.it.conf.
Le righe fondamentali da editare al suo interno sono

  • LogFile: che dovrà contenere il nome completo di path dei log da esaminare
  • SiteDomain: che conterrà il nome del dominio
  • HostAliases: per indicare, separati da spazi, eventuali nomi alternativi del dominio
  • LoadPlugin: vorremo probabilmente aggiungere almeno “ipv6”
  • LogFormat: permette di descrivere in dettaglio il formato dei log se non sio è utilizzato quello standard di apache o squid.

I parametri configurabili sono veramente molti e, se non la documentazione, il file merita almeno una scorsa per individuare elementi di interesse.

A questo punto non rimane che scaricare il file di log nella directory e far parsare il file ad awstats. Da sottolineare che i vari file di log devono essere processati nell’ordine in cui vengono generati e che il nome nella configurazione è univoco e bisognerà quindi o copiare giorno per giorno il file di log nella directory designata sovrascrivendo il precedente o sfruttare un link simbolico. Si tratta comunque di un’attività facilmente automatizzabile.

Procediamo quindi con il parse

/usr/lib/cgi-bin/awstats.pl -config=linuxandcompany.it -update

Se apache è stato configurato sulla propria macchina e se l’elaborazione è stata fatta localmente sarà possibile vedere il report sull’url

http://localhost/awstats/awstats.pl?output=main&config=linuxandcompany.it&framename=index