Problème avec des certifs x509 sur des ESXi pas mis à jour, une histoire de param DH trop faibles. C'est bien de check. C'est bien d'avertir. C'est pas forcément idiot de faire peur. C'est con d'empêcher de contourner (oui les gens le font sans réfléchir du coup mais il faut aussi pouvoir faire ce qu'on veut à un moment). Et quand t'es en interne, que t'as besoin d'administrer ça vite-fait et que l'alternative c'est le client lourd fenêtre-only, bah c'est moins pire.
Donc sous Firefox, ça se désactive (complètement du coup…) dans about:config, sous chromium via un param de ligne de commande.

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

J'y aurais pas pensé : pour avoir que la première et la dernière ligne d'un pipe (ou autre), envoyer dans un subshell head et tail. Par exemple pour premier et dernier fichier d'un dossier :
ll dossier | (head -n2 && tail -n1)
(oui c'est head -n2 parce qu'il y a la ligne total débile là, on pourrait la virer en rajoutant une étape de pipe mais c'était juste pour visualiser alors je m'en fiche d'une ligne inutile)

EDIT:
On me souffle ça, c'est probablement mieux :
ll dossier | sed -n '2p;$p'

Une liste de photos et envie de faire un tar avec seulement les dernière ? Au lieu de s'embêter à utiliser une interface graphique et de sélectionner, d'imaginer des solutions à base for et de ln ou autre, il suffit juste d'utiliser cette option : --after-date=date (ou juste -N)
On peut donner un fichier (considéré comme tel si commençant pas '.' ou '/') comme référence, pratique.

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.

Envie de tester boinc à fond ? Avec les paramètres par défaut apparemment il y a une sorte de throttling à 60% ! Donc les process tournent à fond un moment, puis sont suspendus, etc. en permanence. Ça se remarque bien dans boinctui par exemple.
En cherchant, sur la page ci-liée on tombe sur une option "Use at most N % CPU time", qui, dans la liste d'options ici (http://boinc.berkeley.edu/wiki/Global_prefs_override.xml) pourrait correspondre à cpu_usage_limit.
On tente donc de mettre
<cpu_usage_limit>100.0</cpu_usage_limit>
dans /etc/boinc-client/global_prefs_override.xml puis de voir si ça change quelque chose : boinccmd --read_global_prefs_override
Et pouf, plus jamais de pause saugrenue.
Je me demande un peu pourquoi ils font ça par défaut, si on veut calculer, on y va… le seul intérêt que je vois serait pour pas qu'un laptop chauffe trop.

Des sources.list plus clairs, plus faciles à lire/écrire programmaticalement et permettant de factoriser mieux, pourquoi pas. Surtout quand on commence à avoir les backports, les symboles de débugage, différentes suites, …
Attention j'ai lié un mail préliminaire, dans le thread il y a des considérations intéressantes et des changements au format, c'est juste pour dire que c'est en cours.

Ça a l'air pas mal : des paquets Debian de symboles de débugage, automatiquement construits sans intervention du mainteneur et disponibles en-dehors du dépôt officiel (c'est quand même des paquets rarement utilisés). Au moins on sera sûr qu'il y a le paquet correspondant (actuellement c'est à la discrétion du mainteneur) et ce en-dehors du chemin (mirrorer ça partout et les avoir tous toujours dans les listes de paquets c'est un peu overkill).

Une méthode de root des android sur processeur intel (x86) : injection d'un binaire via fastboot puis exéctution dudit binaire. Ici ce binaire enchaîne avec un autre, qui lui lance le cwm recovery (une "rom" recovery apparemment très utilisée et assez complète, que j'ai déjà utilisé sur mon téléphone).
Le post original sur xda-developers fournit un script windows, j'y connais rien mais ça se décortique pas trop difficilement (j'avais pas trouvé la page ci-liée avant, l'auteur a aussi traduit le script en quelques commandes shell…).
Pour moi donc :
adb reboot-bootloader
fastboot flash /tmp/recovery.zip /tmp/IntelAndroid-FBRL-07-24-2015/FB_RecoveryLauncher/cwm.zip
fastboot flash /tmp/recovery.launcher /tmp/IntelAndroid-FBRL-07-24-2015/FB_RecoveryLauncher/recovery.launcher
fastboot flash /sbin/partlink /tmp/IntelAndroid-FBRL-07-24-2015/FB_RecoveryLauncher/fbrl.trigger
fastboot oem stop_partitioning

À ce moment-là on est dans la recovery cwm, et on peut par exemple installer SuperSU ou tout autre zip d'installation. Et on peut aussi enfin faire des backup du système complet (boot, system, …) cas où… :)

Pour désactiver un périphérique bloc (clef / disque USB, …), au lieu d'eject on peut utiliser la méthode moderne (avec du polkit dedans !) :
udisksctl power-off -b /dev/sda
Ceci demandera le mot de passe même en SSH à distance, avec un version texte de l'écran "polkit" qu'on connait.

Ci-lié un post où j'explique comment j'ai mis en place des certificats Let's Encrypt sur mon serveur.

En passant j'ajouterai que dans le cas d'un site mod_proxy d'apache, on peut sortir le dossier de vérification du proxy comme cela :
ProxyPass /.well-known/acme-challenge/ !

J'ai dû désactiver IPv6 sur les machines du labo que je gère car un RA involontaire avait filtré et configuré du SLAAC de partout… et là un chercheur se plaignait que ssh -X marchait plus. Side-effect marrant :P