J’ai souhaité limiter l’accès au serveur proxy aux serveurs concernés, tous possédant une IP dans un sous-réseau logique. Je me suis donc tourné vers Netfilter. J’ai créé deux scripts, if-pre-up.sh et if-post-down.sh, que j’ai placés dans /etc/apt-proxy/. Voilà d’abord le script if-pre-up.sh :

#!/bin/sh -e
# Written by bobe

if [ ! "$IFACE" = "eth0" ]; then
        exit 0
fi

iptables -N aptProxy
iptables -A INPUT -i eth0 -p tcp --dport 9999 -j aptProxy
iptables -A aptProxy -s xxx.xxx.xxx.xxx/28 -j ACCEPT
iptables -A aptProxy -j DROP
exit 0

Et le script if-post-down.sh :

#!/bin/sh -e
# Written by bobe

if [ ! "$IFACE" = "eth0" ]; then
        exit 0
fi

iptables -D INPUT -i eth0 -p tcp --dport 9999 -j aptProxy
iptables -F aptProxy
iptables -X aptProxy
exit 0

Il suffit ensuite de donner les droits d’exécution et de créer les liens nécessaires dans /etc/network/ :

# chmod a+x if-pre-up.sh if-post-down.sh
# ln -s /etc/apt-proxy/if-pre-up.sh /etc/network/if-pre-up.d/apt-proxy
# ln -s /etc/apt-proxy/if-post-down.sh /etc/network/if-post-down.d/apt-proxy

Ce billet est aussi l’occasion de ranimer un peu ce blog mourant. Je vais essayer de m’en occuper plus souvent désormais ;-)

On s’est pris tuile sur tuile, un truc de dingue. Je ferai un compte-rendu plus détaillé ces prochains jours (et quelques photos).

Je ne sais ce qu’il en est du support d’OpenPGP/MIME dans la plupart des clients mail, mais je suppose qu’il doit être largement supporté, vu la relative facilité avec laquelle j’ai appréhendé le principe des clés et implémenté OpenPGP/MIME dans Wamailer.

J’ai aussi mis à jour la page de garde du wiki et ajouté la page OpenPgp pour fournir des explications et exemples.

• Zone de développement de Wamailer
• Site officiel de GnuPG
• La RFC 3156 sur le format OpenPGP/MIME de sécurisation des emails

• XHTML 2.0 : Working Draft du 26 juillet 2006
• Changements avec la version précédente

Par exemple, ouvrez le gestionnaire de signets (Organize Bookmarks… quoi…) et créez un nouveau signet avec dans le champ location https://bugzilla.mozilla.org/show_bug.cgi?id=%s et dans le champ keyword mozbug.

Et voilà ! Il vous suffit de taper mozbug 15000 dans la barre d’adresse pour accéder au bug n°15000 de Mozilla :¬)

Perso, je n’ai que trois signets de ce genre actuellement :

Geek d’un jour, geek toujours :D

P.S : Je me demande s’il est possible de combiner plusieurs paramètres avec un mot-clé ? J’en demande peut-être beaucoup là…

Les listes adjacentes

C’est la méthode la plus naturelle et celle à laquelle j’ai d’abord penser. Le principe est tout simplement d’associer à chaque nœud l’identifiant du nœud parent. On peut ensuite extraire nos données de différentes façons avec des auto-jointures (voir le lien vers mysql en fin de billet).

Le problème est que cela n’est pas applicable si la profondeur de l’arbre n’est pas fixée. Il faut alors en passer par une routine récursive (en PHP dans mon cas) pour construire l’arbre et travailler dessus. C’est bourrin, c’est coûteux…

Les ensembles imbriquées ou représentation intervallaire

Moins facile à appréhender, cette technique offre en revanche une bien plus grande facilité pour lire tout ou partie de l’arbre. La plupart des opérations de lecture ne nécessitent qu’une requête SQL !

Le principe est d’assigner à chaque élément deux bornes, les descendants de cet élément étant englobés dans l’interval créé par ces deux bornes. Je me permets de copier ici la représentation visuelle en tranche donnée dans l’article de SQLpro, ça permet de tout de suite se faire une bonne idée du mécanisme :

Je ne m’attarde pas sur les requêtes SQL à utiliser pour consulter un tel arbre, consultez l’excellent article Gestion d'arbres par représentation intervallaire pour en savoir plus.

Ici, donc, pas besoin de récursivité, la lecture est simple et claire. Mais les choses se gâtent dès qu’on souhaite effectuer des changements sur notre arbre. Souhaite t-on ajouter un élément dans notre arbre ? Paf, trois requêtes ! Une pour décaler les bornes droite, une autre pour décaler les bornes gauches, et enfin, la requête pour insérer le nouvel élément. Et si plusieurs modifications peuvent potentiellement survenir quasiment au même moment, ne pas utiliser les transactions, et donc, dans le cas de MySQL, les tables innoDB, serait plutôt hasardeux.

Autres idées

Comme autre technique, il y en a une qui consiste à stocker carrément le chemin canonisé d’un élément à la racine. Pas super élégant et viable seulement pour des petits arbrisseaux ;¬)

J’ai vaguement pensé à stocker la structure de l’arbre sous forme XML, elle-même stockée dans la base de données, mais là comme ça, sans creuser l’idée, je me dis que les performances ne seront pas vraiment au rendez-vous. Qu’en penses-tu toi, visiteur perdu sur mon journal ? Et si tu as d’autres idées pour gérer un arbre, n’hésite pas ;¬)

• Managing Hierarchical Data in MySQL
• Une référence : Gestion d’arbres par représentation intervallaire
• Trees in SQL: Nested Sets and Materialized Path
• PEAR : Paquet DB_NestedSet
• Four ways to work with hierarchical data

D’abord, en envoyant un cookie avec pour domaine de validité .example.com, celui-ci sera viable également sur example.com. L’extension View Cookies de Firefox m’a induit en erreur.

Il semble que seuls les cookies dont le domaine de validité matche exactement le domaine courant soient affichés par cette extension, les cookies avec un domaine de validité de type .example.com valides sur plusieurs sous-domaines ne sont pas du tout affichés. Un coup d’œil à liveHttpHeaders ou avec print_r($_COOKIE); montre qu’ils sont bien actifs.

Ensuite, concernant le nombre minimum de caractères point dans le domaine de validité, celui-ci doit contenir au moins un point "embarqué" (x.y est bon, .y ou x. ne l’est pas) et la partie précédent le domaine de validité du cookie dans le nom d’hôte courant ne doit pas contenir de point. Example : le cookie avec le domaine de validité .foo.com sera valide sur foo.com et n’importe quel sous-domaine *.foo.com où * est une chaîne ne contenant pas de caractère point. Donc le cookie n’est pas valable sur *.bar.foo.com.

Au vu de ces règles (extraites de la RFC 2965), je ne vois plus ce qui empêche en principe d’émettre un cookie avec un domaine de validité tel que .co.uk et qui serait valable par exemple sur blah.co.uk. Ce billet est donc sujet à une mise à jour ultérieure, quand j’aurais éclairci ce point :¬)

• RFC 2965 - HTTP State Management Mechanism

PHP en mode interactif

Connaissais pas… Ça a l’air interessant

Installation de SubVersion, Trac et BuildBot

Un article sur la façon d’installer et configurer ce trio de logiciel. Je ne connaissais pas la possibilité de SubVersion d’exécuter divers scripts avant ou après un commit

Installation et configuration de SubVersion

Encore un article sur l’installation et la configuration de SubVersion (sur une debian) que j’avais en réserve depuis quelques temps

L’attribut domain d’un cookie ne peut cibler qu’un sous-domaine (le nom complet doit comporter au moins deux points, par exemple www.example.com). Pour que le cookie soit actif sur tous les sous-domaines, n’indiquez pas de sous-domaine (mais laissez le point en tête) : .example.com
Problème : example.com ne fait pas partie des heureux élus.

Compte tenu de l’obligation d’indiquer un nom de domaine comportant au moins deux points, toute tentative d’envoyer un cookie sur la racine d’un domaine (example.com) en précisant le domaine dans la fonction setcookie() sera vouée à l’échec. La seule solution est de ne pas préciser le domaine de validité du cookie (= cookie valable uniquement sur example.com dans notre cas).

D’après la spécification, cette limitation est là pour éviter des émissions de cookie dans des domaines de validité tels que .com ou encore .co.uk.
je lis d’ailleurs à l’instant que le nombre de caractères points minimum est porté à trois si l’extension du domaine n’est pas dans la liste des extensions "spéciales" : "COM", "EDU", "NET", "ORG", "GOV", "MIL", et "INT".

• Persistent client state HTTP cookies
• RFC 2965 - HTTP State Management Mechanism

Tomber nez à nez avec ça au moment d’aller se coucher, ça a de quoi vous rendre insomniaque, je vous le garantis. Plus d’infos sur cette vision d’horreur.

Je viens de tomber sur une analyse du think-tanks Europe 2020 à propos de la crise mondiale majeure qui se profile à l’horizon. Cet article est à lire absolument ! Je vous préviens cependant, vous en ressortirez probablement avec un filet de sueur froide entre les omoplates…

• Enfin MySQL 4.1 ! Enfin, mes données sont stockées dans des tables proprement déclarées comme contenant de l’utf-8, et je peux profiter de toutes les autres nouveautés qu’apporte cette version par rapport à la 4.0.
• Adieu l’antique Webalizer, bonjour Awstats.
• L’avantage quand on est sur un serveur privé, c’est qu’on peut installer à peu près ce qu’on veut (les limitations ne se trouvant qu’entre la chaise et le clavier). Je me suis donc installé les magnifiques outils que sont Subversion et Trac pour rendre public le développement de Wamailer 3.0. C’est par ici que ça se passe.
• PHP 5.1.2 à la place de PHP 5.0.5. C’est toujours ça de pris, surtout au vu des nouveautés apportées par la branche 5.1.x
• Apache 2.x à la place d’Apache 1.3.x. C’est toujours ça de pris également. La version 2 est de toute évidence plus puissante, plus rapide, toussa.