Just Another Geek

function nba-timestamp2date() {
    if [[ "x"== "x$1"]]; then
        1=time
    fi
    perl -le "print scalar localtime $1";
}

Comment ça je suis un gros fainéant ? D'accord le nom de la fonction est aussi long que l'appel a la commande finale, mais au moins, zsh me le complète :)

Exemple :

% nba-timestamp2date
Tue Aug 10 12:27:04 2004
% nba-timestamp2date 1091940610
Sun Aug 8 06:50:10 2004

Quand on est paresseux, on l'est juqu'au bout ! (c)

Ça faisait longtemps que j'en rêvais : faire un stage (sérieux) de pilotage. La réservation a été prise du 28 au 30 août 2004 : 3 jours de bonheur à bord de 206 RC et S16, 505 V6, 306 S16, sweeeeeeeeet :)

(Paraitrait même qu'il y a des 307 CC, va falloir me dire ce qu'elles font là bas...)

$ perl -MDate::Manip -le '$x=ParseDate("today"); $y=ParseDate("08/28/2004"); \
              print Delta_Format(                                           \
              DateCalc($x, $y, \$err), undef,                               \
              "Ces %dt jours  d''attentes vont  être longs...")' 
Ces 34.280463 jours d'attentes vont être longs... 

pcat [archive] est un paquet Debian [archive] (non-officiel) désormais !

À mettre dans votre /etc/apt/sources.list :

Pour Stable/Woody :

deb http://mouarf.org/deb/ stable/

Pour Testing/Unstable :

deb http://mouarf.org/deb/ testing/

pcat [archive] est l'équivalent de la commande cat(1) mais en version sniffeur.
pcat va sniffer le trafic (avec ou sans filtre pcap) et concaténer tous les champs DATA des paquets TCP, UDP ou ICMP vérifiant le filtre.

Exemple : voir une session SMTP entre deux machines.

$ sudo pcat -i eth0 'tcp port 25'
HELO shibby
250 plop.priv.mouarf.org Hello shibby.priv.mouarf.org [192.168.0.1]
MAIL FROM:<>
250 OK
HELP
214-Commands supported:
214 AUTH STARTTLS HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP ETRN
QUIT
221 plop.priv.mouarf.org closing connection

pcat est capable de lire un fichier au format pcap (tcpdump -w file), d'afficher les données dans un fichier spécifique, de limiter l'affichage aux caractères ASCII (fonctionnalité peu testée par contre), de se séparer de ses privilèges super utilisateur, etc.
Le tout sous GPL bien sûr. J'attends vos remarques, rapports de bug, etc.

J'avoue, mon jeu de mots est pourri : pcap + cat = pcat. Désolé.

Après les journées à colmater les trou de sécurité, passons un après midi à boucher les trou de mon pot d'échappement.

Pourvu que ça tienne...

zsh% print -l *(.Lm+1oL)

Comment ça c'est illisible ? C'est pourtant simple, ça affiche la liste triée sur la taille (de manière croissante) des fichiers réguliers faisant plus d'un méga-octet du répertoire courant.

Depuis le travail, je me connecte en ssh sur ma machine pour lire mes mails/usenet avec Gnus en mode console. C'est bien mais c'est parfois lent car Gnus est souvent verbeux, par exemple, lorsque je sors d'un gros dossier IMAP, il va afficher une ligne indiquant qu'il va garder le message et non l'expirer (= le supprimer) puis l'effacer pour afficher une ligne similaire. En local, c'est presque invisible.

L'ennui est que ma connexion ADSL est trop lente pour afficher/effacer/afficher ces lignes instantanément. Alors une ligne par message s'affiche une demie-seconde. Ça peut paraître peu, mais pour les dossiers IMAP épassant les milliers de mails, ça dure longtemps :-(

C'est pas super génant non plus, ça fait quelques semaines que je suis comme ça et je ne m'en étais même pas rendu compte =)

Mais j'ai activé la compression ssh (Option -C) et c'est impeccable maintenant :)

WormRadar [archive], développé par Roger Thompson, est un projet qui a pour but d'écouter le trafic passant par une machine et de faire des statistiques sur les connexions entrantes en fonction des ports ciblés. Le résultat final est un graphique [archive] disponible sur le site du projet mis à jour toutes les trente minutes.

L'objectif principal est de détecter les nouveaux Worms, bots, ou tentative de piratage. WormRadar est un outil "distribué" dans le sens où tous les clients participant au projet envoient leurs résultat à un serveur principal qui traitera les données.

En effet, les paquets reçus par le client sont analysés pour détecter les patterns déjà connus. On peut alors distinguer deux catégories de "connexion" :

• Les données non reconnus par le moteur, représentée par l'item rouge dans le graphique. Les noms sur le graphique sont déterminés à partir du protocole (TCP ou UDP principalement), du numéro de port et de la chaîne "unk".
  Exemple : t1433unk pour le port 1433 en TCP
• Les paquets reconnus par l'analyseur, en vert. Cette catégorie comptablilise également les paquets vides.

Ce qui nous intéresse le plus sont les données inconnues car si on reçoit sur un même port un nombre important de connexions, on peut découvrir un nouveau Worm ou une nouvelle faille.

A l'heure actuelle, un peu plus de 1500 nodes participent au projet. Les données sont uploadées au serveur par mail et par UDP (avec exactement le même contenu que le mail sans l'enveloppe).

Les projets similaires ne manquent pas (Dshield [archive], ISC [archive]) et semblent beaucoup plus ouvert que WormRadar qui n'est disponible que sous forme binaire pour les systèmes Microsoft Windows (mais son auteur compterait porter l'application sous GNU/Linux).

Plus je lis les sources du noyau, plus je me dit que c'est pas si mal l'instruction goto. Ca clarifie vraiment le code dans certains cas.

Par contre, je n'ai toujours pas compris pourquoi ils utilisaient :

for (;;) {
  ...
}

Plutôt que

while (1) {
  ...
}

D'accord, y a moins de touches pour la boucle for(), mais je trouve ça tellement moins lisible !

C'est amusant de voir toutes les personnes qui croient avoir le scoop en or à chaque faille de sécurité. Par exemple, regardez tous les marketeux qui parlent au sujet de la Faille TCP/IP ! Ils sont tellement content qu'ils diffusent l'information sur toutes les mailing lists, ou forums. On leur dit que la technique est connue depuis 1996 ?

Ah si si si si, l'Internet va couler par les méchants n'hackers...

M'enfin...

Google propose depuis deux ans d'accéder aux fonctionnalités du moteur de recherche à travers un protocole méconnue : SOAP. Ce protocole permet aux programmes d'avoir un accès rapide aux résultat d'une recherche sans avoir besoin de faire des requêtes HTTP/HTML classiques puis de parser le résultat.

L'article détaille le protocole utilisé, et offre une implémentation Python de ce service. De plus, une (courte) réflexion sur l'utilisation de ces données est émise.

Le tout disponible sur http://mouarf.org/papers/google-soap/ [archive]

C'est Wanadoo qui respecte sa tradition d'excellent FAI ou bien Google [archive] est vraiment lent depuis ce week-end ?

Voici un lien trouvé sur le blog de Kenneth Hunt au sujet de l' architecture de Google [archive].

On peut voir que Google a un système assez atypique (Traduction: qui n'est pas Décideur compliant), on sent que les choix ont été fait par des vrais techniciens/architectes, et pas par un marketeux, résultat : pas de SAN, ni de RAID, etc. Ils préfèrent utiliser beaucoup (Plusieurs milliers) de machines de type PC pour avoir une infrastructure puissante, et pas chère.

C'est original et puis ca doit etre tellement beau de voir ces centaines de machines par salle tournant sous Linux

Voici un exemple concret de "Pourquoi Gnus [archive] est bon pour vous ?" : La gestion des cross-postings, ou des doublons en général.

Par exemple, je suis inscrit à une liste (Mail) qui résume des dizaines de liste de diffusion. Et je lis quelques unes de ces listes par l'intermédiaire de Gmane [archive] (par le protocole NNTP donc).

Gnus reconnait alors automatiquement les posts que j'ai déjà lu dans ma liste mail et vice-versa. Super non ?

Comme quoi cela n'a pas que des désavantages que d'avoir un client qui fasse Mail et NNTP.

Voila enfin la liste des blogs [archive] que je lis quotidiennement et qui a été généré à partir du script disponible sur http://mouarf.org/coding/perl/opml2html.perl [archive]