Archive pour janvier 2010

Il peut être utile parfois de connaître la dimension des informations qui vous sont renvoyées dans votre shell.
Ca peut vous paraître abstrait, voici donc une étude de cas.

J’ai un fichier gzip qui traine sur mon disque, je souhaiterai le décompresser mais je ne suis pas sûr d’avoir l’espace nécessaire pour parvenir à mes fins. On sait que gzip est capable de décompresser un fichier ou un flux stdin (via le pipe) puis le renvoyer dans le stdout (via l’argument -c). Vous pouvez donc utiliser par exemple les commandes :

# gzip -cd fichier.gz | puis je m’amuse avec mon flux
Ou
# zcat fichier.gz | puis je m’amuse avec mon flux

La partie après le pipe correspond au flux décompressé.
Nous voulons à présent connaître la taille totale de ce flux décompressé, qui correspondra à la taille du fichier décompressé.

Il suffit tout simplement d’utiliser l’outil magique dd

Soit :
# zcat fichier.gz | dd of=/dev/null
14793468+1 records in
14793468+1 records out
7574255817 bytes (7.6 GB) copied, 87.8925 s, 86.2 MB/s

Ici le fichier décompressé prendrait donc 7.6 Go d’espace disque.

Cette méthode est bien évidement applicable sur tout ce qui vous renvoi un flux dans le stdout.

Pour les gzip :
Merci à la personne (toto), qui m’a fait connaitre cette méthode via les commentaires.
Vous pouvez pour les fichiers Gzip utiliser « gzip -l », qui en plus d’être plus performant affichera plus de détails

$ gzip -l sed-4.1.5.tar.gz
compressed uncompressed ratio uncompressed_name
799584 3584000 77.7% sed-4.1.5.tar

Il n’y a pas beaucoup de tutoriels sur Internet pour aider à la mise en place de l’enregistrement des logs Ulog dans une base SQLite. Bien que cette opération soit simple, un petit tuto évitant une longue prise de tête ne peut être que bénéfique.

Pourquoi SQLite ?

Je ne suis qu’un novice avec ce SGBD, et Ulogd m’a permit d’y jeter un coup d’oeil.

Mon choix s’est porté dessus car par sa légèreté et son fiabilité hors norme il pourra résister à des attaques  de Deny de Service (DoS), ou autres attaques par flooding auquel un SGBD traditionnel de type MySQL ou PostGres ne résisterait pas.

Pourquoi ?

SQLite contrairement aux deux exemples cités n’est pas un démon mais une simple librairie permettant de gérer un fichier de base de donnée : l’opération se révèle donc juste un peu plus un lourde qu’une écriture classique dans un fichier de log, et donc adaptée à notre cas. De plus, pas besoin de faire du dump ou autre moyen pour la sauvegarde; un simple « cp » ou « rsync » fera l’affaire.

Les inconvénients majeurs que j’ai pu recenser sont : la gestion des droits inexistante (GRANT, REVOKE), et le verrouillage en écriture de la base ne permettant de faire écrire plusieurs applications sur la même base.

Installation

Je suppose que vous avez déjà installé Ulog et qu’il fonctionne.

Commençons par installer SQLite3, si ça n’est pas déjà fait :

# apt-get install sqlite3

Puis la librairie SQLite pour Ulogd :
# apt-get install ulogd-sqlite3

Passons maintenant à la création de la base « ulog.db » :
# cd /usr/share/doc/ulogd-sqlite3/
# sqlite3 /var/log/ulog/ulog.db < sqlite3.table

Puis à la configuration :
# vim /etc/ulogd.conf

Assurez vous que la ligne plugin="/usr/lib/ulogd/ulogd_SQLITE3.so" est dé-commentée.
Vous pouvez aussi regarder que le chemin du fichier .so est bien valide.

Puis passons à la configuration du module :
[SQLITE3]
table= »ulog »
db= »/var/log/ulog/ulog.db »
buffer=200

Si vous avez suivit les étapes précédentes, aucun modification ne devrait être faite. La ligne buffer correspond au nombre de lignes qui seront gardées en mémoire avant d’être écrites dans la base (Ici 200 lignes).

Pour finir un petit restart Ulogd :
# /etc/init.d/ulogd restart

Voilou vos logs firewall devraient être enregistrés en base SQLite à présent.

Pour cette nouvelle année, le site http://www.my-linux.fr a fermé ses portes pour laisser place à ce blog.
La forme est différente, et convient très bien à son alimentation effectuée au fil du temps et de mes projets en cours : donc chronologique.
Le fond reste le même, les tutos, dossiers et téléchargements ont été migrés sur ce blog (voir liens dans menu supérieur), et j’espère toujours intéresser les administrateurs systèmes, les passionnés de la communauté Open Source ou encore les curieux.

Pour info : le site après deux semaines en ligne est enfin recensé sur notre ami Google.

Et pour finir :

Bonne Année 2010
Bonne tranche timestamp 1262300400 – 1293836400
Bonne seconde décennie du 21ème siècle

…. et tout ce qui va avec.