À savoir : postfix retient les filtres à appliquer aux mails en attente, même si on les supprime de la config. Donc en gros si on a un filter (amavis) dans les choux, qu'on le supprime de la config pour débloquer le problème, puis qu'on flush les mails, çamarchepas™. Il faut faire comme ici, postsuper -r ALL !

Ça imprime plus ! Et dans les logs "Can't copy stdin to temporary file". /var plein :) Bon j'ai fait un peu de ménage mais CUPS garde quand même 200 jobs apparemment, pour peu qu'il y ait des PDF ou autre un peu gros, je me retrouvais avec 500 Mo de spool CUPS…
Comme proposé ici, effectivement un MaxJobs plus bas puis lancer un nouveau job arrangent ça.

Calcul de distance tout simple avec OSM, juste des gros traits (pas de suivi des routes), facilement ajustable (points qui se déplacent, segments qui se coupent en deux).

Un système de fichier basé sur FUSE, qui produit une vue rassemblée de N systèmes de fichiers, par exemple plusieurs disques durs. On a donc toujours accès aux différents systèmes de fichiers normaux sous-jacents, le module se débrouille juste pour unifier les accès et répartir les fichiers.
Par défaut il remplit dans l'ordre un système de fichier après l'autre, en laissant 4Go libres avant de passer au suivant. On peut modifier cela, en mettant par exemple un seuil à 25% de libre (pour éviter la fragmentation etc.). J'ai testé et à partir de 1.4To remplis (sur un disque de 2) il est passé sur le suivant.
Beaucoup moins bancal que d'agréger via LVM où on n'a alors qu'un seul système de fichier qui est à cheval sur les disques, et donc on perd potentiellement tout si un seul tombe en panne. Et j'aime bien le côté rassurant de voir ses fichiers directement sur les disques, contrairement à du RAID.

for… else en python : je connaissais pas (tombé dessus en lisant un bout de code). Ça peut être pratique en effet, mais si on passe une demi-heure à se demander ce que c'est que ce truc et en vérifiant qu'il n'y a pas de problème tab/space c'est pas forcément un cadeau :)

Par exemple pour le disque d'une machine virtuelle qu'on voudrait transmettre/copier/whatever, il peut être malin (ou juste amusant) de chercher à réduire la taille du fichier. On arrive donc à la notion de fichiers creux (sparse), où les blocs ne contenant que des zéros peuvent tout simplement ne pas être alloués par le système de fichiers.

Il faut donc d'abord mettre des zéros partout où le système invité de la VM n'a rien d'utile : zerofree. Petit outil simple, mais qui a besoin d'un FS non monté ou en ro. On passe donc en ro… (remount ne fonctionne pas : busy) :
echo u | sudo tee /proc/sysrq-trigger
Puis on peut lancer zerofree.

Là on se rend compte que la taille allouée ne diminue pas :
59G -rw-r--r-- 1 root root 59G mai 12 09:55 oleron.raw
59G de taille, 59G alloués… il faut donc… creuser des trous ! Et pour ça, rien de plus simple : fallocate -d
15G -rw-r--r-- 1 root root 59G mai 12 14:17 oleron.raw
Bien ! (à noter qu'on peut aussi utiliser cp --sparse=always, mais qu'il y a donc une copie du fichier (et dans ce test l'allocation était descendue à 20G au lieu de 15G avec fallocate, probablement une histoire de taille de bloc)).

Si l'on veut ensuite écrire cette image sur une clef USB, autant essayer de ne pas écrire ces trous de zéros (ce qui est pourtant le cas avec un dd simple). Pour cela on découvre l'option conv=sparse de dd. En testant je suis arrivé à cela (image de 64Gio, 20G alloués, sur clef USB3 190Mo/s) :
dd simple, bs=1M : 348,944 s, 180 MB/s
cp sparse (bs probablement 4k) : 6m55.131s (donc 415s)
dd sparse : 206,039 s, 305 MB/s
On remarque que la vitesse moyenne est plus grande que la vitesse d'écriture max constatée ! :) Bon et si on poussait le vice à faire deux clefs en parallèle ? 235,069 s, 267 MB/s !
Conclusion, avec tout cela on s'est bien amusé et on peut écrire 2 clefs de 64G utilisables (20G réels) en moins de 5 minutes :) Pour moi qui en ai 25 à faire, c'est pas si mal.

EDIT: 172,801 s, 363 MB/s avec l'image fallocate (qui fait donc 15G au lieu de 20G) en mono-dd sparse.

Basé (entre autre sur ce lien), pour créer une image bootable par UEFI à partir d'une image MBR, j'ai :

• fait une place de 150Mo pour la partition EFI (je sais pas si ça doit être la première mais dans le doute…) au début en décalant la partition existante ;
• créé la partition EFI, mis le type 0xEF ;
• installé grub-efi (qui désinstalle grub-pc, mais le boot MBR est déjà en place)
• monté la partition sur /boot/efi
• sudo grub-install --target=x86_64-efi /dev/vda
  et/ou
  sudo grub-install --target=x86_64-efi --removable /dev/vda

La première commande crée un fichier spécifique sur la partition et essaye de dire à l'UEFI de l'utiliser (mais n'y arrive pas si on est pas déjà en mode UEFI). La seconde place grub dans un fichier de boot fallback générique (/efi/EFI/BOOT/BOOTX64.EFI).

Pour tester dans KVM, on peut utiliser EDK II, packagé dans Debian (non-free) dans le paque ovmf.
Il suffit alors de paramétrer la VM pour utiliser ce firmware (voir précédent shaarli). Dans le shell interactif on peut alors booter à la main le fichier de grub (FS0: puis cd dans le dossier et BOOTX64.EFI), puis refaire le grub-install pour positionner le boot sur ce fichier (vu qu'on est booté en EFI ce coup-ci).
On a alors une image qui fonctionne dans KVM (via la config UEFI et le grub spécifique) ou sur une clef via le grub sur fichier fallback.

Il y a une option 'f' à fdisk pour fix l'ordre des partitions dans l'index. On peut en avoir besoin quand par exemple on crée une partition avant une autre dans l'ordre du disque mais après chronologiquement (dans un espace vide créé devant une autre partition existante).

Pour avoir de l'UEFI dans une VM Qemu :

• installer un firmware UEFI (j'ai pris le paquet ovmf de sid à la main)
• éditer la conf de la VM (pas dispo avant virt-manager plus récent que jessie) et ajouter dans la section "os" :
  virsh edit nom-instance
  <loader readonly='yes' type='rom'>/usr/share/ovmf/OVMF.fd</loader>

Tiens, ça y est, Mozilla et Debian s'entendent enfin sur les histoires de licence pour avoir le droit d'utiliser "Firefox" ? :)
Tant mieux, pas la peine de faire des exceptions de partout. Après ça a pas l'air non plus si simple et clair, avec des avis divergents (comme toujours)…

coquelicot (interface web de partage de fichiers orienté vie privée) est packagé dans Debian. Mais dans Jessie, il tourne en root alors que le cron de cleanup tourne bien avec l'utilisateur spécial "coquelicot".
C'est corrigé dans la version 0.9.4 du package. Il suffit de prendre le paquet et de l'installer par-dessus. Il y a même le bout de migration qui va bien (changement des permissions, on peut le voir a posteriori dans le postinst, /var/lib/dpkg/info/coquelicot.postinst).
Un peu crade surtout que du coup on perd le support de sécurité mais bon.

Installation de DD-WRT sur un WN2000RPTv2 : ça juste marche comme annoncé. J'ai utilisé les images du post du 2 février, et la procédure donnée par l'utilisateur de raspbian (mode binary, l'autre commande doit être pour une autre implémentation de TFTP).
Globalement, DD-WRT a effectivement l'air très léger, l'interface web est rapide, mais ne suis pas impartial car mes essais d'OpenWRT étaient sur du matériel beaucoup plus ancien.
L'upgrade avec une image OpenWRT n'a pas fonctionné, mais je n'ai rien contre DD-WRT, ça me permettra de voir autre chose.

Simple sonde de température, 3 soudures à faire, rien de méchant. Testé sur un RPi 2. J'ai utilisé une résistance de 1k ohm et ça fonctionne aussi. Par contre pour changer le port gpio (il y a déjà d'autres choses sur le port par défaut, le 4), il suffit pas de charger le module Linux avec le paramètre qui va bien. Il faut aussi le dire au "Device Tree" du firmware du RPi.

Doc du firmware, partie "overlays" : https://github.com/raspberrypi/firmware/tree/master/boot/overlays

Pour utilser le dernier GPIO (le 21 (proc) / 40 (board)), il faut donc mettre dans /boot/config.txt :
dtoverlay=w1-gpio,gpiopin=21

Avec juste cette modification, on a directement accès aux données comme prévu, sans avoir rien d'autre à faire (modprobe ou /etc/modules, rien).
Exemple :
$ cat /sys/bus/w1/devices/28-80000002cefa/w1_slave
58 01 ff ff 7f ff ff ff c1 : crc=c1 YES
58 01 ff ff 7f ff ff ff c1 t=21500

… et c'est packagé dans Debian. :)
Si on peut éviter de s'embêter avec un awstats pour par exemple voir la BP ou les hits qui finissent 404, c'est pas si mal.
En ce qui me concerne, je dois choisir "NCSA Combined Log Format".

Besoin de faire un dd pour par exemple remplacer en recopiant entièrement un disque qui est en train de tomber ? ddrescue peut faire ça mieux qu'un bête dd, dans la mesure où il est prévu pour les erreurs.
Merci lg pour m'avoir remis ça sous le nez au bon moment :D

Petit outil packagé dans Debian pour convertir le format proprio alakon Outlook pst en vrais formats standards. Par défaut on a un mbox.
readpst dell.pst

Troll du jour : faire une clef USB avec un binaire Linux et un Windows et pouvoir exécuter directement depuis la clef…
En fat : pas de permissions, et exécution désactivée par défaut (sécurité toussa si j'ai bien compris).
En NTFS : pas possible d'écrire les permissions avec ntfs-3G.
En exFAT : tout est exécutable par défaut donc ça marche… mais c'est crade comme format et il faut installer ces paquets qui sont pas par défaut sur les desktop.

En passant j'ai vu un fichier exécutable sur le FAT, et j'ai rien compris… en creusant on trouve (sur la page ci-liée) : "You can use the option showexec instead of the umask and dmask options, which shows all Windows executables (com, exe, bat) in executable colours."
Donc si on mv en .exe et démonte/remonte, pouf on peut exécuter…

pyinstaller + reportlab = boum, une erreur de loader-je-sais-pas-quoi. C'est bizarre comme problème, mais du coup plutôt du côté de reportlab. En tous cas même en python interactif ça marche pas.
Pour moi il a suffit de rajouter un return False avant la ligne compliquée dans rl_isdir et hop.

J'utilise le paquet omnibus pour gitlab (pour pas m'embêter…) mais avec le postgres du système (parce que bon les trucs bundlés, boff). Du coup il manquait un paquet qui fournit des extensions à la mise à jour en gitlab 8.6 et j'avais une erreur 500 avec une histoire de template.
Basé sur la réponse ci-liée, le fix pour chez moi a été :
aptitude install postgresql-contrib
sudo -u postgres psql -d gitlabhq_production -c "CREATE EXTENSION pg_trgm;"
gitlab-rake db:migrate
gitlab-ctl restart

C'est super spécifique mais bon les commandes sont intéressantes à connaitre, au cas où un autre problème du même style se produit.

L'erreur était : undefined method `main_language', visible avec un gitlab-ctl tail

J'ai voulu me connecter à IRC en IPv6 via un tunnel HE (https://tunnelbroker.net/). Hé bah non. Filtré.
Sur le forum ci-lié on lit :
"I realized that I have to go through all the certifications to enable IRC ports."
En testant au pif avec telnet on trouve qu'on n'a pas de connexion refusée sur 6660-6670 inclus et 6697 mais bien aucune réponse, donc du drop. Nmap confirme :
$ nmap -6 -sT -p 6650-6750 vp.michalon.eu
Starting Nmap 6.47 ( http://nmap.org ) at 2016-03-06 20:55 CET
Nmap scan report for vp.michalon.eu (2a00:5881:8110::1)
Host is up (0.064s latency).
Not shown: 89 closed ports
PORT STATE SERVICE
6660/tcp filtered unknown
6661/tcp filtered unknown
6662/tcp filtered radmind
6663/tcp filtered unknown
6664/tcp filtered unknown
6665/tcp filtered irc
6666/tcp filtered irc
6667/tcp filtered irc
6668/tcp filtered irc
6669/tcp filtered irc
6670/tcp filtered irc
6697/tcp filtered unknown

Un nmap similaire mais sur tous les ports (1-65535) montre "31 filtered ports" (j'ai pas eu le détail du coup).

Pour vérifier que c'est pas sur le retour le filtrage mais bien à l'aller, j'ai limité le nmap sur 6695-6699
nmap -6 -PN -sT -p 6695-6699 -r vp.michalon.eu
et tcpdump les TCP SYN de l'autre côté (lignes de sortie raccourcies ; merci http://www.packetlevel.ch/html/tcpdumpf.html pour le filter).
tcpdump -i eth0 -n "ip6 and (ip6[6] == 0x06) and (ip6[53] == 0x02)"

2a00:5881:8110::1.6695: Flags [S]
2a00:5881:8110::1.6696: Flags [S]
2a00:5881:8110::1.6698: Flags [S]
2a00:5881:8110::1.6699: Flags [S]

lala.