Archive pour la catégorie ‘Geekerie’
Connaître la taille totale de la sortie standard StdOut
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
Ulogd avec SQLite sur Debian
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.
Nokia et son Remote Device Access
Le saviez vous ?
Nokia met à disposition pour les developpeurs d’applications et widgets une plate-forme de prise de contrôle à distance avec un large panel de smartphones que l’entreprise propose sur le marché.
A l’exception des branchements, vous pouvez tout faire avec comme si vous aviez le téléphone dans les mains, et pour cause : c’est un vrai téléphone. Ce qui a pour conséquence une indisponibilité des modèles en cours d’utilisation mais une réservation est possible si vous voulez travailler sur un appareil spécifique.
Cela peut être aussi un bon moyen de tester un mobile avant d’en faire l’acquisition.

Rendez vous ici pour tester Nokia RDA
(Pour y avoir accès, il faut créer au préalable un compte sur le forum Nokia)
Emoze un sauveur pour les accros aux mails
Pour ceux qui comme moi ont eux la surprise de ne pas pouvoir recevoir leurs mail sur des offres mobile « Internet Illimité » limitées, vous serez heureux d’apprendre qu’il existe une application qui n’a rien à envier aux applications de mail standard fonctionnant sur les ports standard et disponible pour une large gamme de smartphone/portables : Emoze, qui fonctionne via le port 443 et donc accessible lorsque le port est ouvert.
Conçu par une petite société Israëlienne, Emoze vous permettra de faire du push mail comme le BlackBerry ou bien de faire un check automatique (A intervalle configurable) de vos mails; assez pratique si vous souhaitez éviter que le push réduise fortement l’autonomie de l’appareil.
Emoze vous propose donc de vous connecter à une boite :
- Gmail
- Hotmail/Windows live
- AOL
- Facebook
- Hi5
- Une boite POP/IMAP configurée à configurer avec vos petits doigts.
- Office (Outlook Web Access, Enterprise Edition, PC Connector)
Il vous propose aussi de nombreuses fonctionnalités comme le réglage de la plage horaire de check, les notifications sonores à la réception d’un mail …. .
De base vous ne pouvez créer qu’une seule boite, ce qui devrait suffir à nombreux d’entre nous; mais si ce n’est pas le cas, il existe une version payante qui rend illimité ce nombre pour 9,99€ par an (largement en dessous des offres mail proposées par les opérateurs).
Alors rendez vous sur le site Emoze.