GuiGui's Show

Pour un logiciel qui en analyse le contenu, un Shaarli (au sens de l'application entière) est imbitable. Rien est hiérarchisé, tout est encapsulé dans du div, du span, du ul, etc. Pour un logiciel, un Shaarli apparaît comme de la bouillie, il ne sait pas déterminer où un shaarli commence et où il termine dans une liste de shaarlis.

On peut faire une légère modification : entourer le titre du Shaarli des balises HTML <h1></h1> et entourer le titre de chaque shaarli des balises HTML <h2></h2>. Dans le corps de mes shaarlis, je commence mes titres à la graduation Markdown ###, ce qui créera des titres de type <h3></h3> et inférieurs. On obtient ainsi un début de hiérarchisation de l'information. En outre, cela permet aux synthèses vocales, utilisées par les malvoyants / aveugles, d'identifier un peu la structure et de permettre à leur utilisateur⋅rice de naviguer d'un shaarli à un autre avec le raccourci clavier habituel, ainsi que d'identifier les contours d'un shaarli.

Sur ma vieille version de Shaarli avec son vieux thème, le titre du Shaarli est mis en forme dans la page tpl/page.header.html. Je remplace les lignes suivantes (11-13) :

<span id="shaarli_title">
    <a href="{$titleLink}">{$shaarlititle}</a>
</span>

Par :

<h1 id="shaarli_title">
    <a href="{$titleLink}">{$shaarlititle}</a>
</h1>

La liste des shaarlis (1 shaarli est une liste contenant un seul élément ;) ) est mis en forme dans la page tpl/linklist.html. Je remplace les lignes suivantes (86-89) :

<span class="linktitle">
    <a href="{$value.real_url}">{$value.title}</a>
</span>
<br>

Par :

<h2 class="linktitle">
    <a href="{$value.real_url}">{$value.title}</a>
</h2>
<!-- <br> -->

Une autre liste de shaarlis est mise en forme dans la page tpl/daily.html. Je remplace les lignes suivantes (68-70) :

<div class="dailyEntryTitle">
    <a href="{$link.real_url}">{$link.title}</a>
</div>

Par :

<h2 class="dailyEntryTitle">
    <a href="{$link.real_url}">{$link.title}</a>
</h2>

Je modifie le CSS pour positionner le titre du Shaarli. Pour ce faire, je remplace les lignes suivantes (256-260) du fichier inc/shaarli.css :

/*#shaarli_title {
    font-weight: bold;
    font-style: italic;
    margin-top: 0;
}*/

Par :

#shaarli_title {
    display: inline;
    font-size: 100%;
    font-style: italic;
    margin: 0;
    padding: 0;
}

Je modifie le même CSS afin que le titre d'un shaarli ne déborde pas. Pour ce faire, je remplace les lignes suivantes (434-437) :

.linktitle {
    font-size: 14pt;
    font-weight: bold;
}

Par :

.linktitle {
    font-size: 14pt;
    font-weight: bold;
    marging: 0;
    padding: 0;
}

Enfin, je modifie le même CSS afin que le titre d'un shaarli dans l'affichage "journal quotidien" conserve ses propriétés. Pour ce faire, je remplace la ligne suivante (832) :

div.dailyEntryTitle {

Par :

h2.dailyEntryTitle {

Au taff, nous utilisons FOG (qui semble être l'évolution du Clonezilla Server Édition que j'utilisais il y a 7 ans…) pour déployer régulièrement des images disques sur notre parc informatique de plusieurs centaines de machines.

Compte-tenu que nous devons déployer une même image sur plusieurs dizaines de machines en une seule itération, un déploiement unicast sature notre réseau informatique. En effet, sur un réseau gigabit comme le nôtre, le débit par machine sera de 1 gigabit par seconde divisé par le nombre de machines déployées Avec une cinquantaine de machines déployées en même temps, cela nous fait du 20 mégas soit 2,5 mo/s par machine. Évidemment, ceci est le débit optimal, pas le réel. Bon courage pour déployer une image disque de 72 gigaoctets à ce débit-là ! Si l'on déploie séquentiellement, petit paquet de machines par petit paquet de machines, alors cela crame une énergie humaine considérable, ce qui n'est pas acceptable.

Donc nous utilisons le multicast. Problème : il faut encore environ 3 heures pour déployer une image de 72 Go. On calcule le débit : environ 7 mo/s. Sur un réseau gigabit ?! Nous utilisons environ 5 % de la capacité de notre réseau ! Nous avons testé un déploiement en heures non ouvrées afin de nous assurer que d'autres usages ne saturent pas le réseau : même constat.

Dès que l'on a configuré notre métrologie pour utiliser les compteurs SNMP 64 bits, nous avons pu constater que le switch qui constitue le cœur de notre réseau architecturé en étoile envoie le trafic multicast sur tooooous ses ports, c'est-à-dire à tous les switchs de tous nos bâtiments, qui eux-mêmes, l’envoient sur tous leurs ports (ce qui inclut le switch qui le leur a envoyé) ! Le flux multicast ne reste pas cantonné aux switchs sur lesquels sont directement ou indirectement raccordées les machines que nous déployons ! Incrédules, nous vérifions physiquement : oui, tous les ports d'un switch non concerné par un déploiement clignotent à fond et, oui, un wireshark depuis un port sur un switch non concerné par le déploiement met en exergue que le flux multicast est envoyé partout…

Dans ces moments-là, on essaye de se raccrocher à la théorie que l'on a étudiée il y a des années : mais, bon sang, le multicast, c'est justement la création d'un groupe de diffusion auquel s'abonnent les machines qui veulent recevoir ce flux et l'émission d'un flux dans ce groupe et uniquement dans ce groupe… Ben, oui, mais comment un switch sait sur quels ports il doit laisser passer le flux et sur quels ports il ne doit rien relayer ?

Réponse : en écoutant les paquets IGMP, qui est le protocole qui permet d'annoncer l'existence d'un groupe multicast, de le rejoindre et de le quitter. Cela se nomme « IGMP snooping ». Il faut activer cette fonctionnalité sur tous les switchs d'un réseau dans lequel circulent des flux multicast un peu sérieux. L'analyse des paquets IGMP consomme des ressources CPU du switch, mais moins qu'une saturation causée par une retransmission en broadcast.

Le résultat est flagrant : déployer la même image disque de 72 Go sur le même sous-ensemble de machines prend désormais environ 30 minutes, soit un débit d'environ 42 mo/s. Si l'on déploie sur très peu de machines, on monte même jusqu'au débit maximal du réseau, 125 mo/s, et l'image est déployée en environ 10 minutes ! Comment explique-t-on cette différence ? En multicast, tout le monde doit avancer au même rythme donc la machine la plus lente ralentie tout le monde. Si une machine a un support de stockage plus lent que celui des autres machines ou un câble réseau endommagé qui l'oblige à effectuer beaucoup de retransmissions ou autre problème, alors tout le groupe est ralenti. Plus le nombre de machines déployées simultanément est petit et plus les machines sont homogènes dans leurs caractéristiques matérielles, plus le débit maximal du réseau sera atteignable.

Bref, l'IGMP snooping, c'est bon, mange-en !

Sur un switch HP H3C équipé de ComWare 5 ou 7, l'IGMP snooping s'active de manière globale et VLAN par VLAN… :

igmp-snooping
  quit

vlan $ID
  igmp-snooping enable
  igmp-snooping drop-unknown
  quit

Sur un switch Allied Telesis x600, l'IGMP snooping est activé par défaut. Si l'on ne lit pas « no ip igmp snooping » dans la sortie de « sh run », c'est que l'IGMP snooping est activé. Sinon, on l'active globalement :

ip igmp snooping

Sur un switch Allied Telesis 8000GS, l'IGMP snooping n'est pas activé par défaut… Il s'active uniquement de manière globale de la manière suivante :

bridge multicast filtering
ip igmp snooping