Ta vie on s’en fout!

Des fois il y a des choses qui énervent, et pas seulement les discours présidentiels. Par exemple quand on envoie une belle archive dodue de 5Go sur un serveur distant par scp et qu’au bout de 8h et 4Go le transfert plante. Si on relance bêtement le transfert scp, tout repart à zéro, scp ne gère pas les reprises de transfert. En revanche rsync fait ça très bien avec l’option –partial, c’est donc un outil beaucoup plus adapté au transferts de gros fichiers, et il est tout à fait capable de reprendre un transfert partiel initié par scp.

Lire la suite »

De gros soucis en ce moment sous Debian Sid 64 bits avec la dernière version 3.1.9 de Icedove (le clone de Thunderbird) et l’extension calendrier Lightning. Le paquet iceowl-extension 1.0~b2-5 qui apporte la fonctionnalité calendrier fait misérablement planter Icedove avec tout un tas de messages de ce genre dans .xsession-errors :

Error: [Exception... "'[JavaScript Error: "too much recursion" {file: "file:///usr/lib/icedove/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calCompositeCalendar.js" line: 526}]' when calling method: [calIOperationListener::onOperationComplete]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///usr/lib/icedove/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calProviderUtils.jsm :: cPB_notifyOperationComplete :: line 658"  data: yes]

J’ai résolu le problème en désinstallant les paquets coupables et en téléchargeant les « Nightly builds » qui vont bien, toute la difficulté étant de trouver lesquels vont bien, dans mon cas c’était là.

aptitude purge iceowl-extension calendar-google-provider
wget http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-1.9.2/linux-xpi/lightning.xpi
wget http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-1.9.2/linux-xpi/gdata-provider.xpi

Il ne reste qu’à les installer avec le gestionnaire d’extensions Icedove.

Lien

Calendar weblog

Testé sous Debian 5.07 Lenny

Un certificat ssl avec passphrase (phrase de passe selon l’Académie Française) sous Apache, au premier abord ça semble bien pour la sécurité mais dans les faits c’est un très bon moyen d’avoir un serveur en rade sans savoir pourquoi: la passphrase est demandée à chaque redémarrage d’Apache, il faut donc une intervention humaine. Si Apache est redémarré par un script ou un reboot du serveur il restera à attendre cette fichue passphrase qui a peu de chance d’arriver comme ça…

La solution est de supprimer la passphrase de la clé privée, qu’on aura sauvegardée au préalable :

cp -a mondomaine.key mondomaine.key.sav
openssl rsa -in mondomaine.key.sav -out mondomaine.key
chmod 400 mondomaine.key

Lien

How can I get rid of the pass-phrase dialog at Apache startup time?

Il y a deux mois de ça j’avais publié un billet où je m’extasiais presque sur les possibilités de la Google Fonts API. J’avais tort.

Entre temps j’ai lu des articles bien intéressants ici ou là écrits par des gens qui maîtrisent le sujet, et ils m’ont convaincu que cette API ne sert finalement pas à grand-chose. En gros il s’agit juste d’un bout de code Javascript qui va générer dynamiquement des règles CSS @font-face pour embarquer dans la page des polices hébergées chez Google, donc bien loin de chez nous.

Vu le nombre limité de polices disponibles au catalogue Google Web Fonts, on peut se demander quel est l’intérêt de la chose alors que l’utilisation de @font-face permet d’utiliser quasiment n’importe quelle typo hébergée sur votre serveur, pourvu qu’elle soit libre de droits (le problème des droits est une limitation légale, pas technique, pour le moment il n’y a pas de DRM sur les polices ).

Mise en oeuvre de @font-face

Lire la suite »

Testé sous Debian 6.0 Squeeze et Nagios 3.2.3

En migrant mon serveur Nagios sur une nouvelle machine j’ai à nouveau rencontré un problème que j’avais eu lors de la première installation : impossible de forcer la vérification d’un service par l’interface Nagios (commande Re-schedule the next check of this service).

Le message d’erreur que j’avais était « Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’! », certaines personnes signalent le message « Error: No command was specified » sur le même sujet.

C’est un problème de droits d’accès entre Nagios et Apache sur le répertoire des commandes externes, voilà comment régler le problème :
Lire la suite »