À 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.

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.

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).

… 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

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…

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

Petite interface minimaliste pour faire du reverse VNC (c'est le serveur qui se connecte au client, pour traverser NATs ou autres joyeusetés).
Dans l'optique d'aider un novice, il suffit donc d'ouvrir le port (5500 TCP) chez celui qui va aider et qui est supposé savoir faire. De l'autre côté il y a juste à installer et entrer une IP ou une adresse et hop.

Besoin de debug un programme qui se met rapidement à bouffer toute la RAM ? Pas besoin de dégainer du cgroup ou autre, un bon vieux ulimit fait très bien l'affaire. L'option à retenir c'est -S :
$ ulimit -Sv 500000 # Set ~500 mb limit

Attention, plus possible de faire de l'indirect rendering OpenGL par défaut apparemment…
Il semblerait que ça casse OpenGL complètement en SSH -X lorsque le serveur n'est pas sous mesa (nvidia proprio par exemple) ?!
En tous cas ça ça fonctionne plus :
LIBGL_ALWAYS_INDIRECT=1 glxinfo

Script perl qui regarde quels processus utilisent encore des libs qui ont disparu depuis leur démarrage (mises à jour).

Liste :
needrestart -r l -v
(le -v affiche de quelles libs il est question, et comment il est arrivé à la conclusion que ces services-là doivent être relancés (ou ignorés : cas d'un process lancé à la main en session utilisateur)).
Par exemple pour une instance picomon "ban" lancée par systemd :
[main] #183 exe => /usr/bin/python3.4
[Core] #183 is a NeedRestart::Interp::Python
[Core] #183 source is /usr/local/bin/picomon
[main] #183 is picomon@ban.service

On peut aussi directement lui faire relancer les services, avec -r i (ou rien, c'est par défaut). On a alors soit un debconf qui permet de sélectionner les service que l'on souhaite (tous pré-cochés sauf certains comme journald ou dbus), soit une ligne-question par services.

needrestart est packagé dans Debian (depuis Jessie et wheezy-backports) et intègre des hooks pour apt/dpkg.

Envie de monter automatiquement un disque/clef USB à distance ? Polkit/whatever demande un mot de passe malgré le groupe "plugdev" ?
Il suffit de dropper un petit fichier en root et pouf udisksctl fait son job.
J'ai fait comme dit dans le post lié :
dans /etc/polkit-1/localauthority/50-local.d/auto-mount.pkla
[Allow Automount]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.filesystem-mount
ResultAny=yes
ResultInactive=yes
ResultActive=yes

et hop ! :)

Ici une explication que j'ai trouvée a posteriori après avoir galéré facile une heure : pourquoi grep semble ne pas fonctionner quand il grep sur quelque chose qui ne termine pas, et dans une autre commande ? Par exemple :
while true; do echo a; sleep 1; done | grep '' | cat
=> rien
while true; do echo a; sleep 1; done | grep ''
=> fonctionne
Dans mon cas c'était inotifywait, grep, while read mais c'est bien pareil.
La réponse est toute bête mais il fallait y penser (ou lire tout le man de grep, merci ban :)) : buffer sur stdout. grep se fait bufferiser sa sortie, ce qui est tout à fait normal. Il suffirait d'attendre plein d'événements dans le pipe pour les voir arriver. Et le fait d'avoir un terminal au bout masque ça car il bufferise pas plus qu'un ligne.
Bref, il suffit de dire "--line-buffered" à grep :)

Envie d'éteindre la petite LED de la caméra d'un Raspberry Pi ? On trouve toutes sortes de chose, moi un coup de echo dans un dev ça me va bien :P
FTR:
sudo sh -c 'echo "32" > /sys/class/gpio/export'
sudo sh -c 'echo "out" > /sys/class/gpio/gpio32/direction'
Turn the LED off:
sudo sh -c 'echo "0" > /sys/class/gpio/gpio32/value'
Turn the LED on:
sudo sh -c 'echo "1" > /sys/class/gpio/gpio32/value'

Fonctionne sur un Pi2B aussi.

Si l'on a soudainement envie de diminuer le nombre de CPUs que boinc utilise (même si en pratique il est sensé s'écraser quand d'autres processus ont besoin de passer), on peut le faire en live :
Dans /etc/boinc-client/cc_config.xml mettre (par exemple)
<options>
<ncpus>120</ncpus>
</options>
Puis recharger la config :
boinccmd --read_cc_config
On voit alors avec boinccmd --get_host_info que #CPUS est modifié, le nombre de task en état "run" passe à 120 et les logs disent :
Number of usable CPUs has changed from 128 to 120.

Suite à une discussion AFK où on se demandait comment marchaient les shebang (#! au début d'un script), voici un site avec des explications en long, en large et en travers, avec même un historique et un tableau expliquant comment ça se passe pour pleeeein de systèmes et selon les versions.

C'est donc bien au niveau du noyau, au moment de l'exec, quand le noyau détermine le format binaire du fichier. Si le format n'est pas compris (un script sans shebang) c'est le shell qui réagit et essaye de l'interpréter lui-même (car exec* lui aura renvoyé un ENOEXEC).

À noter qu'apparemment le shebang récursif (l'interpréteur est lui-même un script avec shebang) n'est pas très répandu parmi les unix (mais est supporté par Linux), et que en général tous les arguments sont repris tels quels, sans séparation (on aura donc un seul argument côté interpréteur en plus du nom du fichier, quel que soit le shebang).

Le code Linux est ici : https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/binfmt_script.c
Le parcours des différents formats est ici : search_binary_handler() sur http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/exec.c

Petit test (Linux 3.16), un shebang récursif (2 niveaux) fonctionne bien, met bien tous les arguments en un seul. Par contre si le 2e script n'a pas de shebang, il se passe juste rien et le code de retour de bash est 0.

J'utilise lsyncd chez moi pour copier automatiquement certains dossiers sur mon serveur, pour backup. Quand un fichier est créé ou modifié, il est immédiatement rsync (déclenchement par inotify).
Donc je suis reparti dessus pour un autre usage : un système d'acquisition générant des images pendant longtemps, et dont la personne voulait repartir avec les données rapidement après la fin de l'acquisition. Sauf que copier de gros datasets sur un disque externe risque d'être long. L'idée est donc de copier au fur et à mesure, comme ça le disque sera prêt dès la fin de l'acquisition.
Il y a une option peu documentée (mais tout de même dans le man) : direct. Du coup, plus de rsync ou quoi, il spawn juste un bête cp quand il faut \o/
On peut donc utiliser quelque chose comme :
lsyncd -nodaemon -log all -delay 30 -direct /chemin/dossier/source /ailleurs/destination
lsyncd fait alors un premier rsync pour synchroniser l'ensemble puis copie au fur et à mesure.