Quand on a grub qui essaye de chercher ses petits sur le disque complet au lieu de la partition…

Enfin un article intéressant sur le problème de sécurité de bash. Là j'ai compris :)

Petit outil pour monitorer l'activité d'un système, dans les détails de chaque process. Peut aussi enregistrer les états régulièrement dans un log (binaire) pour pouvoir remonter après un crash à la cause (par exemple en cas d'OOM). Est interactif de base mais peut être utilisé pour extraire des infos de ses fichiers de log.

Exemple pour voir les process de la veille de 13h36 à 13h37 :
atop -r /var/log/atop.log.1 -b 13:36 -e 13:37 -P PRG

Sur cette page, un peu de doc sur CTDB, que je découvre (avec un certain intérêt, je dois avouer). Pour l'instant, après les deux/trois problèmes de mise, ça marche plutôt bien.
Avec ça, samba et glusterfs, et un DNS avec round-robin, ça devrait finir par être une solution de stockage pratique, facile à faire évoluer, et avec des implémentations entièrement libres ! (Oui il y a du CIFS, protocole Microsoft etc. mais on peut pas encore complètement ignorer windows, et c'est le seul qui a des ACL par utilisateur que je connaisse.)

Ma doc sur glusterfs. Au final on a décidé de l'utiliser au boulot, donc j'ai un peu joué avec… il y a de quoi se faire une idée du soft je pense.

Je me suis jamais collé aux flux RSS. Parce que j'estimais que j'avais assez d'info sans (en suivant les chans IRC par exemple), parce que j'avais la flemme de me demander comment ça marche, d'installer un truc, …
Et puis là depuis hier y'a les flux de deux personnes de plus que j'ai envie de lire… donc ça fait 3 (plus des sites de news mais bon). Donc F5 ça va devenir chiant. J'ai donc regardé s'il n'y avait pas un client en ligne de commande et j'ai trouvé ça. Pour l'instant ça juste marche. Packagé dans Debian et tout :)
(En passant, la conf pour C/C dans un screen du post précédent est aussi valable ici.)

usbcore.autosuspend=-1 … et comment on devine ça ? En tous cas c'était bien ça le problème.

Alors ça c'était le gros truc de vendredi soir, trouver pourquoi SIGUSR1 était bloqué dans picomon. Quand on a eu remarqué que ça ne marchait pas que chez le celui qui est en Debian sid, et que d'autres programmes tel 'dd' ne recevaient pas ce signal, c'est tout de suite allé mieux pour moi. Et puis, en tty ça marchait… il restait à trouver quel programme entre le tty et l'émulateur de terminal masquait le signal. L'explication est toute simple au final…

Petit bout de C pour jouer avec la mémoire cache de fichiers.
Apparemment ça se base sur mincore() pour avoir la liste des pages mémoire correspondant à un fichier mmap()é qui sont déjà en cache. Après pour forcer le tout à rester en RAM (exemple 5), il fork, mmap() tous les fichiers puis mlock() dessus et hop.

Le code est configuré pour au maximum des fichiers de 500 Mio, et n'est pas disponible dans Debian (malgré des tentatives apparemment). Et j'ai même l'impression que c'est plutôt bien écrit. :P J'ai testé les différents usages (les exemples), ça juste marche bien.

Intéressant, je savais pas qu'on pouvait faire aussi simple pour ça. Ça peut servir dans des cas foireux où une iso/netboot/autre a un module qui fait braire qui est dans un initramfs et que donc c'est compliqué à rebuild.

You can blacklist a module using the following syntax: module_name.blacklist=yes."

Simple, rapide, efficace, drush et hop taktak sans se faire chier :)

"MiniMagAsm is minimalistic, but powerful and flexible content management system ( CMS ), implemented entirely in assembly language. " voila tout est dit :P

Ouais donc en gros, il tourne par numéro de cœurs, un proc physique après l'autre, puis recommence tout pareil une deuxième fois quand il y a l'hyperthreading. Donc sur 48 cœurs (96 en tout), le 1 est pairé avec le 49 (ou le 0 avec le 48).
Attention, pour info ici sur un proc 12 cœurs les "core id" vont de 0 à 5 et de 8 à 13.

Un bon résumé qui explique pourquoi eglibc et surtout pourquoi c'est fini.

Toi aussi joue avec une LED avec juste un echo dans un dev. En tous cas ça juste marche. Pas mal le pcduino a priori.

J'ai fait un petit setup de test, ça marche plutôt pas mal a priori. Par contre dans mon test j'ai laissé le MTA poser les nouveaux mails dans /new du Maildir lui-même, et du coup dovecot ne réagissait pas et ne lançait pas la réplication… en basculant sur du LMTP c'est bon (LDA aurait probablement suffit). Pourtant il semblerait que dovecot utilise inotify mais peut-être pas pour ça.

Le demuxer concat de ffmpeg (depuis la version 1.1), bien pratique pour rassembler des clips pris avec mon appareil photo sans transcoder quoi que ce soit. Le plus dur a été d'avoir la 1.1 sous Debian… via deb multimedia et un peu de temps dans aptitude, ça passe.
Donc montage de clips an CLI sans peine :
avconv -i qqpart/DSCF1454.MOV -c copy -to 6 /tmp/c.mov
avconv -f concat -i list -c copy /tmp/d.mov
Première ligne, pour couper la fin (qui devenait flou…), on peut aussi couper le début avec -ss. Deuxième ligne, montage en concaténant, avec une liste des fichiers à concaténer dans "list".

J'ai testé le bonding Linux sur du Debian, ça marche bien (/e/n/i etc.). Par contre pas de miracles avec le round-robin de paquets en TCP : les paquets arrivent dans un ordre aléatoire, donc y'a du boulot de rangement. Et du coup l'algorithme baisse le débit croyant qu'il y a des problèmes sur le lien. Bien sûr dans un environnement bien parallélisé, pas de soucis.

Agréger des liens, pour la haute-dispo ou le failover, ça m'a toujours paru intéressant et ça a même l'air plutôt abordable. Ici toute la doc du kernel Linux, que je viens de parcourir et qui m'a parue plutôt claire.

grub2 (et l'ISO ubuntu 14.04, oui j'ai voulu tester ça…) ça gère : boot d'une ISO sur une partoche ext4 dans du LVM, hop ça roule. Simplement (sous Debian en tous cas) il faut pas mettre le "lvm/" dans le set root comme indiqué ici.