Très intéressant quand on n'est pas très au courant de tout ce qu'il peut se passer dans un CPU.

Voila un petit package de rien du tout qui fait son entrée dans jessie et qui est bien pratique quand on nous demande un boulot casse-pieds pour faire un DVD :)
C'est un nid à problèmes, j'ai déjà passé des jours à créer un DVD, mais ici ça passe tout seul, en gros les lignes de commandes ffmpeg/avconv difficiles à deviner sont créées toutes seules !
Il y a quelques ajustements à faire par-ci par là mais rien de bien méchant.

Juste pour partage la page de notes que j'ai écrite après être passé à jessie sur mon PC de tous les jours et mon serveur. Normalement j'ai pas oublié trop de choses (j'ai bien noté et tout !).

Pas mal le coup du -$$ pour tuer tous les process du groupe ! Dommage par contre qu'il faille jouer avec trap pour l'implémenter et que huponexit puisse pas marcher aussi pour un non-login shell.

Principe de passage d'une topologie 2×2 à 3×2 avec glusterfs. Attention : le replace-brick existe plus (voir : http://review.gluster.org/#/c/8503/2/doc/admin-guide/en-US/markdown/admin_replace_brick.md).
Attention aussi (version 3.4.2, ça a pu passer dans un bugfix entretemps…) : à l'ajout des nouvelles briques, la topologie change mais les briques n'ont pas encore les arborescences ni les liens vers les vraies données qui elles sont encore sur les autres briques. Il faut faire un rebalance. Cette opération peut être très longue donc, en attendant, on peut faire un rebalance fix-layout (long mais beaucoup moins) qui met uniquement à jour les informations de layout des fichiers/dossiers etc.
En tous cas c'est un moment de grand stress quand on voit les messages d'erreur qui pleuvent dans les logs…

Une liste de 30 arguments récurrents contre systemd, que Lennart a essayé de couper court. Je suis pas convaincu par toutes les réponses mais on apprend quand même pas mal de choses. Surtout dans les liens connexes (j'ai lu ceux-ci) :
http://freedesktop.org/wiki/Software/systemd/Debugging/
www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

Envie de savoir si la compilation a bien profité d'extensions processeur ? Il "suffit" de voir si des instructions spéciales correspondantes sont utilisées. Ici un script bash autour d'un gros coup de grep sur la sortie d'objdump.

Après perso j'ai testé pour AVX et sans avoir spécialement activé AVX il trouvait déjà des instructions … donc je sais pas, peut-être qu'il y en a trop qui sont considérées AVX ?
En tous cas en recompilant avec -march=native, j'avais bien des binaires différents, et même très différents niveau taille (des plus petits, des plus gros…).

Dans GCC, il y a une belle liste d'options spécifiques à la machine (target). Cette commande permet de toute les lister, et de voir lesquelles sont choisies si on demande d'utiliser la machine courante comme référence (native). Je la paste directement ici pour les impatients :)
gcc -march=native -Q --help=target

Run the next command to see where is the library snmp.so that was installed from the php5-snmp package:
find / | grep snmp.so
Ils disent :
Copy the path that shows to path where apache lampp needs.
Example from my machine:
cp /usr/lib/php5/20060613+lfs/snmp.so /opt/lampp/lib/php/extensions/no-debug-non-zts-20060613/

Sur cette base j'ai pu installer la lib snmp dans une install lampp 32 bits sur un OS 64 bits.
La version de l'API php (la date là-haut) de wheezy correspond à celle du lampp en question (coup de pot). Donc il suffit de wget comme un porc les paquet i386 wheezy de php5-snmp et libsnmp15, coller la snmp.so dans /opt/lampp/lib/php/extensions/no-debug-non-zts-20100525/ et les lib directement dans /opt/lampp/lib comme un goret et ouf ça passe.

En tous cas je sais pas pourquoi lampp ça existe mais je vois vraiment pas l'intérêt à part se faire mal.

Analyse intéressante et très détaillée sur une option d'allocation RAM dans un contexte NUMA (ici plusieurs bancs de RAM gérés par des processeurs différents). En gros on a le choix entre plus de cache (disque…) ou meilleure localité des allocations.

numastat (de numactl), petit outil sympa pour voir où se font les allocations mémoire dans un contexte NUMA. À voir aussi, numactl -H (affiche la topologie). Et pour la beauté du truc (4 contextes NUMA :P) :

numastat
node0 node1 node2 node3
numa_hit 3740055242 4256903182 5486056480 5472483399
numa_miss 39588198 694069046 932981188 28149314
numa_foreign 1314513937 333411725 5543529 41318555
interleave_hit 106874 106725 106880 106725
local_node 3740026559 4256782396 5485924234 5472366371
other_node 39616881 694189832 933113434 28266342

Bloqué sur un firmware tomato et envie d'installer des packages quand même ? Il y a optware, ça marche, y'a 1256 paquets dispos. Pas envie d'arriver à faire marcher la mémoire interne (JFFS etc.) ? Hop, clef USB. En suivant cette doc en 1/2h ça marche et on peut avoir tcpdump, bash, vim et ce genre de choses sur son routeur :)

Jouer avec des tunnels IP c'est facile. Ici une page assez longue qui explique plutôt bien je trouve. Il faut juste ne pas oublier de définir le tunnel des deux côtés bien sûr, sinon on n'a jamais le retour…
J'en profite pour noter le préfix IPv6 privées : fc00::/7

Explication et réponses claires sur les histoires de listen et d'IPv6 dans nginx.

J'ajouterai qu'il faut aussi faire gaffe avec les options, par exemple, ipv6only=off n'a le droit d'être mis QUE à un des listen.

J'ai déjà entendu parler de Cumulus en mai, et j'ai trouvé l'idée intéressante : banalisation d'un switch et utilisation dans un environnement normal Linux. Ici un retour d'utilisateur assez intéressant (même s'il n'y a pas de donnée de stabilité/rapidité/autre), on a quand même un aperçu de ce qu'on peut en faire.

ifdata, pratique… bon ça répond pas à mon problème (quelle est l'IP de la machine dans tel subnet) mais c'est un petit outil sympa… et dans le man on a :
AUTHOR
Benjamin BAYART

En attendant je vais faire comme ça pour 10.10.10.0/24 (pas bô) :
ip a s | grep -oP '10.10.10..+(?=/)'

Une seule commande pour renew le certif SSL d'exim :
/usr/share/doc/exim4-base/examples/exim-gencert --force
Pas besoin de lancer la commande openssl donnée à la main : le script le fait.

À noter que ce sera (forcément) un certif auto-signé, et qu'il est créé pour 3 ans.

Ma doc sur ganeti au taff… déjà beaucoup d'info, j'en rajouterai par la suite. En tous cas il y a moyen de faire un setup sympa : cluster de VM (donc on peut les bouger même si l'host tombe), avec disques directement (sans montage) dans un stockage partagé via la libgfapi de GlusterFS.
Là où je me suis bien amusé c'est avec le script pour installer GRUB dans un chroot…

Super article (j'ai pas tout lu…) sur les boot-loaders, puis lilo. C'est super long, mais il y en a, de l'info !

Découverte de la variable 'prefix' de GRUB…