Ça commence à faire un petit moment que je n'ai rien posté. On va donc se faire un concentré d'astuces.
Table des matières
- Table des matières
- Copier/déplacer un dossier contenant beaucoup de petits fichiers
- Trier vos comptes de courrier sous Thunderbird/Icedove
- Restreindre les droits de Wireshark
- Ne pas être informé des mises à jour d'une extension WordPress
- Faire en sorte que les identifiants de Table of Contents Generator soient uniques
- À voir
- Quelques définitions basiques et simplifiées de termes employés chez les opérateurs
- Les différentes approches de la collecte ADSL
- Interconnexion locale de FAI locaux
- NTP via DHCP sous Debian
Copier/déplacer un dossier contenant beaucoup de petits fichiers
Quand vous tentez de déplacer un dossier qui contient vraiment beaucoup de petits fichiers (au hasard, le Buildroot complet d'OpenWRT), vous allez prendre du temps car le débit en écriture va s'effondrer à cause des petits fichiers. Pour peu que le support physique qui est en dessous soit un peu mou, la copie va vraiment s'éterniser.
On n'y pense pas assez souvent mais tar est notre ami. La création de l'archive (tar -cf destination.tar source/ ), même directement sur le support de destination sera largement plus rapide (on parle d'un gain de plusieurs dizaines de minutes dans mon cas). 7z s'est montré moins efficace. Pas contre, rien n'empêche de 7zippé une archive tar 😉 .
Dans le même ordre d'idée, un rm -rf dossier sera toujours plus rapide dans ces cas-là qu'une interface graphique.
Trier vos comptes de courrier sous Thunderbird/Icedove
La barre latérale gauche de Thunderbird vous montre vos comptes de courrier ainsi que leurs sous-dossiers. Si vous souhaitez trier l'ordre d'affichage de cette liste, il y a deux méthodes : le faire à la main dans le about:config ou le faire avec une extension.
Parmi les extensions existantes, ma préférence va à manually-sort-folders/manually-sort-folders qui fait juste ce qu'on attend d'elle.
Restreindre les droits de Wireshark
Pour utiliser Wireshark, il y a le bon vieux sudo que personne ne recommande et pour cause, lancer une GUI en root est une aberration car elle n'a pas besoin des droits acquis et qu'il s'agit donc d'un vecteur d'attaque supplémentaire. Il y a aussi la méthode qui consiste à exécuter seulement la dumpcap (la librairie de capture) en mode root en utilisant le setuid bit. C'est la méthode que j'ai toujours utilisée.
®om nous parle d'une autre méthode qui consiste à autoriser les membres d'un groupe d'utilisateurs bien défini à capturer les paquets.
Notez deux choses :
- On a déporté les droits d'une application sur un groupe : n'importe quelle application lancée par l'utilisateur faisant partie du groupe aura donc la possibilité de capturer le trafic réseau.
- Cette méthode permet de faire en sorte que la manipulation soit persistante : le setuid bit sur la dumpcap saute à chacune de ses mises à jour (sauf à utiliser dpkg-statoverride mais c'est une autre histoire).
Pensez à regarder les commentaires sous le billet de ®om pour y trouver d'autres manips sympas (capabilities ou le chaînage tcpdump/wireshark).
Ne pas être informé des mises à jour d'une extension WordPress
Quand une mise à jour pour un thème ou une extension que vous utilisez apparaît, WordPress vous le signale dans l'administration. C'est très bien. Sauf quand il confond une extension avec une autre. Non, Table of Contents Generator de Scott Yang n'est pas la même extension que Table of Contents Generator de Tim Carr (l'insertion d'une TOC ne se fait pas avec le même tag et il y a qu'un seul fichier dans la version de Scott Yang contre une multitude dans celle de Tim Carr, par exemple).
Jusqu'à peu, j'empêchais WordPress de m'informer d'une mise à jour de cette extension en modifiant son numéro de version dans le fichier source. Mais depuis peu, WordPress ne se laisse plus berner. J'ai donc recours à une extension qui bloque les notifications de mise à jour d'une extension en particulier. Parmi toutes les extensions disponibles pour ce travail, j'ai choisi Plugin updates blocker. Simple et efficace.
Attention toutefois à ne pas faire n'importe quoi : ce n'est pas une bonne idée de bloquer les notifications de MAJ de toutes vos extensions, par exemple. Entre autres, sachez que la non-mise à jour d'une extension peut entraîner des risques de compromission (sisi, ça c'est déjà vu). Mais quand l'extension dont vous désirez bloquer les notifications n'est plus maintenue depuis plus de 5 ans ...
Faire en sorte que les identifiants de Table of Contents Generator soient uniques
En effet, si vous utilisez un même titre dans deux de vos billets et que vous utilisez ToCG (de Scott Yang hein), vous aurez deux identifiants identiques. Exemple fictif : Pour deux titres "toto" dans deux billets différents, vous aurez http://www.guiguishow.info/2011/07/14/mon-super-billet/#toc-toto et http://www.guiguishow.info/2012/08/02/en-vrac-2/#toc-toto. Si les deux billets tombent sur la même page (index, catégories, archives, ...), cela posera quelques problèmes au navigateur, au validateur W3C et à l'utilisateur qui n'obtiendra pas ce qu'il voudra quand il cliquera sur le lien. En effet, un identifiant (ancre ou autre) doit être unique dans une page web.
L'idée est donc d'ajouter dans l'identifiant toc un élément variable et unique. L'ID du billet ? Dans l'exemple précédent, cela donnerait (toujours fictif) :http://www.guiguishow.info/2011/07/14/mon-super-billet/#toc-254-toto et http://www.guiguishow.info/2012/08/02/en-vrac-2/#toc-123-toto. Les identifiants seront uniques et plus aucune collision ne se produira si les billets tombent sur la même page.
Pour réaliser ce changement, il suffit de modifier une ligne de la méthode "get_tocid($text)" :
La ligne 26 :
return "toc-$tocid"; |
devient :
return "toc-$this->postid-$tocid"; |
Le code complet de la méthode devient donc :
function get_tocid($text) { $text = sanitize_title_with_dashes($text); $text = preg_replace('|%([a-fA-F0-9][a-fA-F0-9])|', '', $text); $tocid = $text; $count = 0; while (isset($this->tocmap[$tocid])) $tocid = $text.strval(++ $count); $this->tocmap[$tocid] = true; return "toc-$this->postid-$tocid"; } |
La variable d'instance $this->postid est définie dans la méthode "the_posts($posts)".
À voir
Si vous ne vous êtes jamais penché sur eux, je vous conseille d'aller voir de plus près :
- OpenStreetMap (OSM) : Projet de cartographie mondiale libre. Je ne trollerai pas sur "pas complet"/"plus complet que"/"collaboratif donc pas fiable" car la messe est déjà dite avec Wikipédia (dans le sens où Wikipédia a été reconnue aussi fiable que les encyclopédies classiques) et ce billet de SebSauvage. Et quand je vois les arnaques sur les GPS commerciaux (30 jours max après achat pour mettre à jour les cartes avec un soft non libre, une seule mise à jour dans les GPS bas de gamme, les GPS haut de gamme mise à jour "à vie" limitées, ...), je ne peux pas m'empêcher de penser que si je m'achète un GPS un jour, alors ça sera un modèle sur lequel je pourrais mettre les cartes OSM. En attendant, j'ai déjà effectué quelques modifications de la carte de ma ville et il faut reconnaître que c'est facile à faire et rapide même avec l'éditeur en ligne.
- FRnOG : "Le FRench Network Operators Group (FRnOG) est un groupe d'échange d'informations qui rassemble des personnes intéressées par les domaines de la sécurité, la recherche et le fonctionnement d'Internet en France." Mélange entre information et troll, toute personne intéressée par le monde des réseaux se doit de suivre cette liste de discussion.
Quelques définitions basiques et simplifiées de termes employés chez les opérateurs
Quelques définitions à ceux qui débutent en "vrai" réseau ( 😉 ) car le net regorge de schémas et d'explication juste que des fois, il faut faire plus simple.
GIX | IX | IPX | Point d'échange : Lieu physique (généralement un datacenter) dans lequel des opérateurs s'interconnectent. Pour simplifier, il faut voir cela comme un gros switch sur lequel des opérateurs viendraient connecter un câble menant à leur réseau. Actuellement, beaucoup d'interconnexions se font sur Paris. Ce qui est une mauvaise chose puisque le trafic se concentre en un lieu avant d'être réparti localement. L'idéal serait de favoriser les GIX locaux entre plusieurs membres de la fédération.
Peering : Accord (souvent gratuit mais pas que) entre deux (ou plus) opérateurs pour s'échanger le trafic entre leurs réseaux de manière directe.
Avantages :
- Optimisation : route plus courte donc on diminue la latence.
- On gagne (un poil) en indépendance vis-à-vis de son transitaire : si le réseau de ce dernier tombe, on a encore nos routes vers les réseaux avec lesquels on a un peering.
- On augmente les interconnexions existantes entre plusieurs points et donc, on augmente la robustesse de l'Internet.
Dans la vraie vie, les opérateurs imposent des politiques de peering plus ou moins débiles (quota, “jeCausePasAuxPetits”, …).
Attention : le peering n'est pas transitif. Si A peer avec B et B peer avec C, A ne peer pas avec C et A devra donc avoir un transitaire pour faire le trajet A <> C.
Transitaire : Opérateur qui donne accès à tous les réseaux qui composent Internet. Cet opérateur peut faire des peering, acheter des routes, … mais l'important est qu'il doit fournir un accès complet. La question bête qui peut venir à l'esprit est : mais si tous les transitaires fournissent toutes les routes vers n'importe où, comment en choisir un plutôt qu'un autre ? On tombe là dans des problématiques de qualité des routes proposées. Exemple : vous êtes en France et vous avez le choix entre le transitaire A et le transitaire B. A peer avec les réseaux importants français (FT, Free, peu importe) à Paris. B peer avec ces mêmes réseaux à Amsterdam. Vous comprenez que, dans votre cas, A > B.
Porte de collecte : Point de sortie d'un tunnel L2TP.
Tunnel L2TP : Permet de récupérer les abonnés au BAS (= concentrateur en sortie de DSLAM) et de les acheminer jusqu'au réseau de l'opérateur desdits abonnés quand l'opérateur ne dispose pas de ses propres installations au niveau physique et local. Il faut voir ça comme un câble virtuel amenant l'abonné jusqu'au réseau de l'opérateur.
Note : ce contenu est disponible sur le wiki de la FFDN tout simplement car je l'y ai mis. Mais comme j'aime bien la redondance, je recopie ici.
Les différentes approches de la collecte ADSL
Attention : Cette page se veut simple et non-exhaustive. Son but principal est de répondre à la question “Pourquoi un FAI de FFDN ne prend pas en charge l'abonné de son routeur jusqu'à son réseau ?”.
Quel est le but du jeu quand on est FAI ? Amener un abonné à votre service jusqu'à Internet. Plus précisément, jusqu'à votre réseau, qui, comme d'autres, compose Internet. Ce qui n'est pas forcement clair, c'est qu'il y a plusieurs niveaux. Du plus indépendant au plus dépendant. On ne parle ici que d'ADSL et donc de collecte ADSL. La fibre semble ouvrir de nouvelles opportunités.
Tout faire soit même (du routeur de l'abonné jusqu'à votre réseau opérateur)
Vous êtes financé par une jeune et riche Nigérienne qui vient d'hériter de ses parents ( 😀 ) ?
Alors vous installez des DSLAM dans les NRA dans lesquels arrivent les lignes des abonnés qui vous intéressent. Ensuite vous avez votre propre BAS (= un bête concentrateur) raccordé à votre DSLAM, votre propre lien en fibre optique jusqu'à un datacenter dans lequel vous installez votre cœur de réseau (le routeur qui parle BGP, entre autres) et depuis lequel vous donnez accès au net grâce à des peering et des transitaires.
L'indépendance est totale (sauf vis-à-vis du(des) prestataires qui vous fournissent des chemins vers le reste d'Internet). Cette solution est fortement onéreuse : coût du DSLAM et du BAS, location des lignes de vos abonnés à FT, “loyer” pour installer votre DSLAM et votre BAS, …
Plus raisonnable
Faire appel à un opérateur de collecte qui vous livrera, en L2TP, vos abonnés dans un datacenter. Reste à trouver celui qui fait ça à un niveau local sans passer par Paris. Il y a eu coût à prévoir qui n'est pas à la portée du premier FAI local en construction venu.
Être en marque blanche FDN. Cela est déjà expliqué ailleurs sur ce wiki 🙂 . Cela revient à de la collecte Parisienne à prix réduit.
Note : ce contenu est disponible sur le wiki de la FFDN tout simplement car je l'y ai mis. Mais comme j'aime bien la redondance, je recopie ici.
Interconnexion locale de FAI locaux
C'est quoi le VRAI Internet dont les membres de FFDN ne cessent de parler ?
En plus d'être neutre et libre, le vrai Internet est acentré. Si l'on crée un centre, on recréer le Minitel, pas de l'Internet. Donc il faut favoriser les points d'échanges locaux plutôt que de tout regrouper à Paris (en plus de favoriser des usages acentrés (pas de Facebook ou de MSN) mais c'est un autre sujet).
Pour l'exemple FICTIF, prenons 2 FAI de la fédération géographiquement proches : Ilico (Corrèze) et Aquilenet (Aquitaine). Il y a plusieurs moyens de s'échanger du trafic entre un abonné Ilico et un abonné Aquilenet :
- Soit on demande à un opérateur tiers qui a le matériel au niveau local de la zone à couvrir de nous livrer le trafic en un point donné (notez que plusieurs opérateurs de collecte peuvent intervenir (= se chaîner) : Nerim passe à FDN qui passe à l'association locale, par exemple). La centralisation française fait que la livraison se fait généralement dans un datacenter de la région Parisienne. Donc, un abonné Ilico qui veut consulter un contenu hébergé par un abonné Aquilenet fera le chemin suivant : opérateur de collecte → porte de collecte Ilico → réseau d'Ilico (à Paris donc) → réseau d'Aquilenet (à Paris) → porte de collecte Aquilenet → opérateur de collecte.
- Soit on fait de la collecte locale. Ilico récupère ses abonnés dans un datacenter à Brive et Aquilenet récupère les siens dans un datacenter à Bordeaux. En l'état, ça ne change rien au point précédent, il faudra emprunter des réseaux tiers pour faire Bordeaux → Brive. Mais si l'on fait un lien physique entre Brive et Bordeaux ? Le chemin devient opérateur de collecte → porte de collecte Ilico → réseau d'Ilico (à Brive donc) → réseau d'Aquilenet (à Bordeaux) → porte de collecte Aquilenet → opérateur de collecte. La distance est raccourcie. Remarquez également qu'un lien supplémentaire relie désormais Brive à Bordeaux : si Paris se fait bombarder, ces deux villes pourront encore communiquer. La liaison Bordeaux <> Brive peut se faire en fibre (on parle de 150€/mois) ou en WiFi (Plus d'infos).
- Soit on fait la collecte de telle façon que les abonnés des deux FAI soient récupérés au même endroit (Bordeaux ou Brive donc) et les deux FAI installent leur cœur de réseau dans le même datacenter de la même ville.
- D'autres solutions existent, c'était juste pour le cas d'école. D'ailleurs, il est donné au lecteur l'exercice de réfléchir à cette question : est-il pertinent de mettre un GIX entre 3 tout petits opérateurs comme dans l'exemple que nous venons de développer ? 🙂 /> (Indice : On est dans une question de charge des liens à comparer aux coûts de ces mêmes liens.)
Il ne s'agit pas d'un rêve : d'autres pays d'Europe sont moins centralisés (Plus d'infos). Les USA sont également décentralisés par construction (état fédéral et disposition géographique de la population). Des projets sont en cours pour construire des GIX locaux (Plus d'infos).
Note : ce contenu est disponible sur le wiki de la FFDN tout simplement car je l'y ai mis. Mais comme j'aime bien la redondance, je recopie ici.
Plutôt que de vous arrêter là, je vous invite à lire le reste du wiki de la FFDN ainsi que les contenus produits par ses membres.
NTP via DHCP sous Debian
DHCP permet de passer tout un tas de paramètres en dehors des traditionnels IP, masque, broadcast, gateway, hostname, serveur dns, ... Il permet également de passer l'IP d'un serveur de temps. Rappelez-vous, j'ai installé un serveur de temps sur mon routeur OpenWRT. Je suis donc un peu furax quand je vois mon Debian aller contacter le pool ntp.org pour se synchroniser.
L'étendue du problème est résumée ici : NTP - Configuration des clients chez L'Internet Rapide et Permanent. Pour résumer : le Network-Manager (NM) bypass les scripts dhclient.
Pour résoudre le problème, il suffit de placer un script dans le dispatcher du Network-Manager comme indiqué ici : network-manager: ignores /etc/dhcp3/dhclient-*-hooks.d. J'avais tenté de copier les scripts dhclient dans le dispatcher, sans effet (et pour cause, les variables contenant l'information ne sont pas les mêmes entre dhclient et NM).
Mais plutôt que de reprendre le script, je vous propose ce script fortement inspiré de celui proposé sur le bugreport de Debian :
#!/bin/sh -e # Script to take DHCP configured NTP servers # This heavily leverages the ntp script from dhclient-exit-hooks.d if [ -z "$1" ]; then echo "$0: called with no interface" 1>&2 exit 1; fi case "$2" in up|vpn-up) if [ -z "$DHCP4_NTP_SERVERS" ]; then logger "DHCP n'a retourné aucun serveur NTP." exit 1; else ntpdate $DHCP4_NTP_SERVERS if [ $? -eq 0 ] then logger "Synchronisation NTP effectuée." exit 0; else logger "Problème lors de la synchronisation NTP." exit 1; fi fi ;; down|vpn-down) ;; *) echo "$0: called with unknown action \`$2'" 1>&2 exit 1 ;; esac |
Placez ce script dans le dispatcher NM (exemple : /etc/Network-Manager/dispatcher.d/02ntpdate) et votre ordinateur prendra le serveur NTP local pour synchroniser son horloge (si le serveur DHCP lui a bien communiqué ladite IP). La variable $DHCP4_NTP_SERVERS est fournie par NM.
ÉDIT du 17/02/2014 à 11h50 : Mouais, il y a mieux à faire ...
/etc/NetworkManager/dispatcher.d/01ifupdown exécute les scripts contenus dans les dossiers /etc/network/if-(up|down).d. /etc/network/if-up.d/ntpdate exécute /usr/sbin/ntpdate-debian. Par défaut, ce dernier script récupère la liste des serveurs NTP à utiliser dans /etc/default/ntpdate ou dans /etc/{ntp.conf,/openntpd/ntpd.conf} ou dans /var/lib/ntpdate/default.dhcp.
Il suffit donc de rajouter un bloc : si on récupère des adresses de serveurs NTP en DHCP, on les utilise, sinon on utilise ceux de /etc/default/ntpdate :
[...] if [ -r /etc/default/ntpdate ]; then . /etc/default/ntpdate fi # VIA DHCP NTPSERVERS=$(nmcli -f DHCP4 dev list | grep ntp_servers | cut -d '=' -f 2)" "$NTPSERVERS [...] |
Oui, si un fichier ntp.conf/openntpd/ntpd.conf existe, alors les paramètres obtenus via DHCP seront ignorés. Il suffit de mettre ce morceau de code après le check ntp.conf.
Oui, ça se repose sur Network-Manager.
« NTPSERVERS=[...]" "$NTPSERVERS » permet de garder les serveurs du pool ntp.org (ceux indiqués dans /etc/default/ntpdate) sous le coude au cas où le(s) serveur(s) NTP obtenu(s) avec DHCP ne soi(ent) pas disponibles ou erronés. Fin de l'édit
Et pour ceux que ça intéresse : Pour indiquer au dnsmasq d'OpenWRT de préciser le serveur NTP à utiliser via DHCP, il suffit de créer/modifier la variable "dhcp.lan.dhcp_option" d'uCi. Exemple :
uci set dhcp.lan.dhcp_option=42,192.168.0.254 /etc/init.d/dnsmasq restart |
42 est le numéro d'option concernant NTP. L'intégralité des options (et le code associé) permissent par DHCP sont publiées dans le RFC 2132.
Vous pouvez spécifier n'importe quelle option (serveur TFTP + nom du fichier pour un boot PXE, par exemple) à dnsmasq de la même manière. Et si vous voulez combiner plusieurs options (ici TFTP et NTP), deux méthodes sont à votre disposition :
uci set dhcp.lan.dhcp_option="42,192.168.0.254 66,tftpsrv.lan 67,tftp.bin" /etc/init.d/dnsmasq restart ou uci add_list dhcp.lan.dhcp_option=42,192.168.0.254 uci add_list dhcp.lan.dhcp_option=66,tftpsrv.lan uci add_list dhcp.lan.dhcp_option=66,tftp.bin /etc/init.d/dnsmasq restart |