usbcore.autosuspend=-1 … et comment on devine ça ? En tous cas c'était bien ça le problème.
Petit programme tout simple, sans état (pas de base de données ou de fichier dans les coins), qui exécute des scripts et envoie des alertes en cas d'erreur. En gros, un cœur de monitoring, en version légère et moderne. Il y a le minimum pour cette tâche, mais j'ai autant que possible voulu optimiser les fonctionnalités, il y a par exemple un "'threading" des mails problem/recovery (bien pratique), le moyen de configurer plusieurs vérifications à plusieurs hôtes d'un coup (avec les mêmes paramètres, intervalle etc.), ce genre de petites choses qui simplifient la vie.
Je considère depuis quelques jours que c'est convenablement testé (chez ARN), mais bien sûr pas à grande échelle.
Il a été conçu dans l'optique d'être léger, par exemple dans le cas de l'auto-hébergement : on peut très bien l'installer rapidement chez un autre auto-hébergé et configurer les vérifications de son serveur @home sans se prendre la tête avec un nagios ou autre zabbix du même tonneau.
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…
C'est sûr que si on le sait pas… on va pas taper 7 fois sur un bouton au hasard.
Tout pareil pour moi, avec les projets geany (que je commence à peine à utiliser). Je pensais que c'était par défaut dans git, mais bon si ça se configure c'est pas plus mal.
Hé oui, pile mon cas avec picomon… comme quoi toujours des surprises. Mais là c'était bien embêtant quand même.
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.
Aide WIndows : « FCIV-md5-sha1 path\filename.ext » ça a l'air bien… mais non. Erreur de traduction c'est « FCIV -md5 -sha1 path\filename.ext ». Mais ça marche quand même pas, faut pas croire. FCIV n'existe juste pas (ou plus…) sur Win8 :)
L'aide Windows, toujours égale à elle-même !
… quand malgré tout le dépôt git veut garder quelques blob au chaud malgré tous nos efforts, on peut encore tenter de virer ce qu'il y a dans packed-refs. A priori ça supprime des "points d'entrée" dans les commit, donc avec un peu de chance ça peut supprimer la raison qui retient git de supprimer cette partie. En tous cas ça a fonctionné ce matin pour moi.
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."
… et surtout la section "Removing a File from Every Commit", c'est assez la classe ! Bon par contre ça ne réduit pas immédiatement la copie locale du dépôt car les commits sont encore liés par le backup de filter-branch et par le reflog. Pour vraiment nettoyer, il faut virer ces deux références et passer le GC, voir la fin de la page de man, c'est tout bien expliqué.
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
Hier, renouvellement des certificats SSL d'ARN. On utilise des certifs StartSSL (gratuits). Sauf que après avoir remplacé le certif, j'ai eu une erreur bizarre que je ne connaissais pas à propos de OSCP. En fait le serveur OSCP de StartCom n'était pas encore à jour, donc les nouveaux certificats étaient refusés.
OCSP est une sorte de hack pour permettre plus facilement la vérification des certificats (en particulier, sans avoir une liste de révocation en local qui ne serait que difficilement à jour). Le client interroge à chaque fois un serveur pour savoir si le certif est (encore) valide. Mouais, ça veut donc dire que StartCom connait TOUS les gens qui se connectent à notre site.
FTR, l'erreur présentée par firefox :
Le serveur OCSP n'a pas de statut pour le certificat. (Code d'erreur : sec_error_ocsp_unknown_cert)
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.
Jouer avec un certificat SSL serveur, ça pète une semaine plus tard… et dans un autre service, oups. Le topo :
Les mails StrasWeb étaient en rade ; explications :
Et paf les mails, sans qu'on n'en sache rien… oups.
Pour la postérité, les messages d'erreurs sont :
connect to Milter service inet:127.0.0.1:8891: Connection refused
Starting OpenDKIM: opendkim: /etc/opendkim.conf: /etc/apache2/server.key: key
data is not secure
Alors oui ok OpenDKIM qui tape dans le certif chez apache c'est pas top…
Faire des perlre avec look-ahead et look-behind à 9h du mat' : check
Il n'en reste pas moins que c'est sacrément puissant comme truc.
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.