un bon agenda avec iceowl-extension

En tant que fervant utilisateur de Debian, j'utilise souvent icedove, le client lourd messagerie. L'intéret de Icedove (comme thunderbird) est d'etre extensible par un système de plugins. Il existe pas mal d'extensions mais cette fois, je vous parlerai uniquement de l'extension lightning. Dans le monde Debian, cette extension est renommée iceowl-extension. Iceowl est le client lourd d'agenda (aka Sunbird dans le monde hors-Debian). Iceowl gère les calendriers iCal ainsi que le protocole wcap (Sun Calendar Server) en natif (une des rares applications à le faire sans devoir bidouiller).

Pour gérer son agenda, on peut également utiliser la solution fournie par Evolution. Mais comme on a le choix, autant utiliser ce qui existe dans les deux mondes. L'intéret de iceowl-extension est que sa version est en 0.8 (qui correspond également à la version 0.8 de lightning). A noter que l'installation de l'extension lightning ne fonctionne pas avec Icedove: les identifiants de construction du paquet ne sont pas compatibles.

Pour ma part, j'avais essayé de faire un paquet à partir de quelques informations trouvées sur internet mais visiblement, quelqu'un (Alexander Sack, le mainteneur Debian du paquet) a déjà fait le sale travail !

Donc l'installation est finalement assez aisée et se déroule comme suit.

Installation de iceowl-extension 0.8 en français sur Debian Lenny

Récupérer le paquet pour sid:

  • Il faut télécharger le paquet pour debian sid. Il se trouve à l'emplacement suivant: http://packages.debian.org/sid/iceowl-extension
  • ensuite, en tant que root: dpkg -i iceowl-extension_0.8-3_i386.deb
  • ensuite, lancer Icedove et constater le changement de vue par défaut !

Franciser l'interface:

  • votre serviteur a déjà fait le boulot pour vous. En attendant que le fruit de mon travail soit disponible directement dans le paquet, vous pouvez utiliser ces 2 fichiers pour franciser l'interface:
  • modifiez ensuite votre fichier /usr/lib/iceowl-extension/chrome.manifest en ajoutant les deux lignes suivantes:

    locale calendar fr-FR jar:chrome/calendar-fr-FR.jar!/locale/fr-FR/calendar/ locale lightning fr-Fr jar:chrome/lightning-fr-FR.jar!/locale/fr-FR/lightning/

  • ensuite, il n'y a plus qu'à redémarrer et on obtient une nouvelle vue qui va bien:

    Interface en français de iceowl-extension aka lightning

Posted mer. 11 juin 2008 17:11:00 Tags:

Devinez qui vient consulter votre blog ?

Quand vous montez un site web, qui plus est un blog, il est bon de savoir qui vient le consulter. Ca vous permet un mimimum de rétroaction: si personne ne vient vous consulter, il y a un problème souvent d'ordre technique (ou social si vous n'avez pas d'amis). Au contraire, il peut arriver que des personnes totalement inconnues à votre cercle proche viennent se connecter à votre site, par exemple, les netbots des moteurs de recherche (voir mon précédent billet sur le sujet).Et puis, c'est pas merveilleux de voir que votre production (qui vous coute tellement de temps) est partagée et diffusée ? Autant avoir des chiffres pour se satisfaire et avoir une idée de sa notoriété.

Dans le monde du libre, le serveur Web est souvent Apache car il est en règle général assez bien packagé par les distributions. Ce serveur produit des logs par défaut qui permettent à minima (out-of-the-box) de savoir quelles sont les adresses IP qui se sont connecté à telle page. Dans les logs sont également présents les erreurs d'accès. Apache produit par défaut une assez bonne quantité de logs qu'il s'agit d'exploiter. Ces fichiers sont en règle générale situés dans /var/log/apache2. On peut bien évidemment les lire en direct mais, si vous vous prêtez à l'exercice, vous verrez que c'est très pénible. L'informatique est faite pour régler les problèmes de capacité de cerveaux des utilisateurs, autant l'utiliser... Ce qu'il nous faut: un bon outil d'analyse de logs Apache

Quand on regarde sur les différents paquets Debian, on constate qu'il n'y a guère que Awstats qui est utilisable et reconnu (et aussi mis à jour). La suite du billet sera donc constituée par quelques infos sur l'installation de ce logiciel libre...

Awstats, késaco ?

  • C'est un outil d'analyse de logs pour serveur Web (Apache/IIS/lighthttpd/etc...)
  • Il s'agit d'un script Perl
  • Qui produit des fichiers html et des images pour affichage dans un navigateur web
  • On peut l'utiliser directement en ligne de commande
  • Ou bien l'intégrer au serveur web via une exécution CGI afin de visualiser les stats du serveur directement depuis le serveur.
  • Le paquet Debian d'Awstats est en version 6.7
  • Il supporte de nombreuses langues

Quelle utilisation d'Awstats ?

Comme je suis paranoiaque, j'estime que mettre à disposition un analyse de logs via le serveur web est risqué. En effet, qui me dit qu'Awstats est exempt de bugs et de failles de sécurité (il y en a eu dans le passé). De plus, mon serveur Web est une machine limitée en capacité de traitement (1Ghz et peu de RAM). Inutile donc d'en rajouter.

Au contraire, je dispose d'une vraie puissance de calcul sur ma machine de bureau qui est bien plus puissante (mais plus gourmande). De plus, pour consulter ces stats, je vais avoir besoin d'un navigateur web qui sera, de toute manière, lancé depuis cette machine de bureau. Autant lui faire faire la totalité du traitement, c'est plus efficace.

Donc, l'objectif est d'installer Awstats sur ma station de travail, de récupérer les logs du serveur via une connexion SSH ou via rsync, de faire le traitement puis de lire les résultats. Conséquence, j'estime que 90% du job est à faire sur la station de travail !

Installation et configuration d'Awstats sous Debian Lenny:

Installation

L'installation du paquet ne pose aucun problème: aptitude install awstats Encore une fois, la force d'une distribution réside dans le travail de ses contributeurs et dans sa facilité d'utilisation (au sens administration système).

Toutefois, il me semble inopportun de laisser le paquet en tant que tel. En effet, il est orienté serveur et notre utilisation est complètement différente: nous ne voulons générer des stats qu'à un moment particulier et non en continu à disposition de tous. Par défaut, awstats rafraichi ses stats toutes les 10 minutes. Ceci est indiqué dans le fichier /etc/cron.d/awstats. Un simple: rm /etc/cron.d/awstats suffit à nous épargner des traitements inutiles

Fonctionnement d'awstats

Sous Debian, voici comment Awstats est installé et comment il fonctionne:

  • L'exécutable qui génère des rapports est situé dans:/usr/lib/cgi-bin/awstats.pl.
  • Le fichier de configuration est situé dans:/etc/awstatsou dans le répertoire du script awstats.pl.
  • Awstats s'éxécute en deux temps: le premier génère les informations de database, le second génère un rapport html
  • Par défaut, /usr/lib/cgi-bin/awstats.pl -config=monserveur lance awstats en utilisant le fichier de conf/etc/awstats/awstats.monserveur.conf.

    Donc lancer la commande suivante: /usr/lib/cgi-bin/awstats.pl -Logfile=./access.log-config=mon.serveur.org aura pour effet de lancer le traitement d'extraction des informations de database et la commande: /usr/lib/cgi-bin/awstats.pl -Logfile=./access.log -config=mon.serveur.org -output -static-links > ./awstats.html générera une page html permettant de visualiser les résultats du log.

Configuration

Voici quelques directives de mon fichier de configuration:

  DirData="~/awstats"
  PurgeLogFile=1
  LevelForWormsDetection=2
  Lang="fr"   DetailedReportsOnNewWindows=0

Ce fichier de configuration est placé dans mon espace utilisateur (pour la suite, je le nomme awstats.conf).

Le script awstats_buildstaticpages.pl

Ce script permet de construire toutes les pages html complètes du rapport d'awstats. En une seule commande, on peut donc générer toute l'information qui nous est nécessaire sans trop se casser la tete pendant des heures... Un exemple d'utilisation:/usr/share/doc/awstats/examples/awstats\_buildstaticpages.pl -config=mon.serveur.org -dir=./awstats/ -awstatsprog=/usr/lib/cgi-bin/awstats.pl

Il suffit ensuite de prendre un browser Web et d'aller ouvrir le fichier./awstats/awstats.mon.serveur.org.html

Récupérer les informations du serveur Web

Ici, c'est simple, on utilisescppour ça. Comme de surcroit, on va scripter tout ça, il nous reste à pouvoir nous connecter sans mot de passe ! C'est possible en utilisant une configuration de SSH pour utiliser l'authentification par clef. Je ne vais pas m'apesentir sur ce sujet, il y a plein d'exemples sur le Web. Voici les commandes pour y arriver:

  • Sur le serveur Web, vérifier que l'option AuthorizedKeys est décommentée dans/etc/ssh/sshd\_configet qu'elle vaut%h/.ssh/autorized\_key
  • Redémarrer le service SSH:/etc/init.d/ssh restart
  • Créer le répertoire /home/user/.ssh/:mkdir /home/user/.ssh
  • Génération de la clef sur le client (la station de travail):ssh-keygen -t dsa
  • Copier la clef au bon endroit:scp user@serveur:/home/user/.ssh/authorized\_keysMaintenant, un simple ssh user@serveur vous permet d'accéder à un shell distant sans mot de passe !

Automatiser le traitement: Bash vient à notre aide

Nous avons tous les éléments de la chaine:

  • L'application est installée et configurée,
  • Nous pouvons récupérer les logs du serveur
  • Nous savons quelles commandes lancer pour avoir nos informations.

Reste à automatiser cette chaine... en mode utilisateur, sans utiliser le compte root (parce que pour le principe, c'est une application à destination de moi). Pour cela:

  • Créer un répertoire ~/awstats:mkdir \~/awstats
  • Créer un lien symbolique du script awstats pour prendre en compte notre fichier de configuration:ln -s /usr/lib/cgi-bin/awstats.pl \~/awstats/awstats.pl * Créer un fichier de configuration bien nommé:cp /etc/awstats/awstats.conf \~/awstats/awstats.mon.serveur.org.conf
  • Editer ce fichier avec les éléments de configuration suivants:
    • LogFile="/tmp/awstats/access.log"
    • SiteDomain="mon.serveur.org"
    • DirData="/tmp/awstats"
    • PurgeLogFile=1
    • LevelForWormsDetection=2
    • Lang="fr"

Un petit script Bash qu'on peut lancer via un lanceur sous Gnome ou KDE (ou XFCE ou Fluxbox ou etc...):

#!/bin/sh
# Script d'analyse de statistiques Web
# C'est du GPL !
    AWSTATS=/usr/lib/cgi-bin/awstats.pl
AWSTATS_DATA_DIR=/tmp/awstats
CONFIG=mon.serveur.org
AWSTATS_REPORT_DIR=~/awstats
BROWSER=iceweasel
DISTANT_SERVER=mon.serveur.org
DISTANT_USER=user
DISTANT_TARGET_FILE=/var/log/apache2
LOGFILENAME=access.log
AWSTATS_BUILD=/usr/share/doc/awstats/examples/awstats_buildstaticpages.pl

# Création du répertoire de données
if ! [ -d $AWSTATS_DATA_DIR ]
then
   mkdir $AWSTATS_DATA_DIR
fi

# Création du répertoire cible
if ! [ -d $AWSTATS_REPORT_DIR ]
then
   mkdir $AWSTATS_REPORT_DIR
fi

# Récupération des informations depuis le serveur
scp $DISTANT_USER@$DISTANT_SERVER:$DISTANT_TARGET_FILE/$LOGFILENAME $AWSTATS_DATA_DIR 1>/dev/null 2>&1

# Lancement de l'analyse
$AWSTATS -config=$CONFIG -Logfile=$AWSTATS_DATA_DIR/$LOGFILENAME 1>/dev/null 2>&1

# Génération des rapports:
$AWSTATS_BUILD -config=$CONFIG -dir=$AWSTATS_REPORT_DIR -awstatsprog=$AWSTATS 1>/dev/null 2>&1

# Nettoyage:
# Des données d'extration:
if [ -e $AWSTATS_DATA_DIR ]
then
      rm -r $AWSTATS_DATA_DIR
fi
# Du fichier de log
# Ouverture du navigateur Web pour affichage:
$BROWSER $AWSTATS_REPORT_DIR/awstats.$CONFIG.html
# End of job !   

Quelques modifications sur le serveur Web ?

Ben meme pas ! Par défaut, Apache enregistre des informations de logs en mode normal qui cache les informations liées au navigateur web. Pour obtenir ces informations, il suffit d'enregistrer les logs au format combined. Sous Debian , le log par défaut de Apache est en combined... Moi je dis, c'est quand meme bien fait !

Références:

Posted ven. 13 juin 2008 19:42:00 Tags:

Ajouter une icone de barre d'adresse sur un site web

Quand vous naviguez sur certains sites web, votre navigateur affiche une icône sur la barre d'adresse. Cette icône est celle de votre site web et elle peut être utilisée par votre navigateur pour identifier plus facilement votre site Web. D'après Wikipédia, cette manière de procéder n'est pas standardisée même s'il existe une page du W3C sur le sujet... et en plus de ça, on doit ça à nos amis de chez µ$oft (avec IE4)!

Qu'importe l'origine, pourvu que ça fonctionne. Le principe est d'utiliser une fichier image et de le rendre disponible.

Spécifications pour l'image favicon:

Voici les spécifications retenues par le W3C pour l'image:

  • Taille 16x16 ou 32x32
  • Couleurs: en 8bits ou 24bits
  • Formats: PNG, GIF ou ICO.

Accès à l'image:

Pour l'accès à l'image, il existe 2 méthodes:

  • Celle toute crade qui consiste à mettre dans la racine du site web le fichier image nommé favicon.
  • Ou bien faire du HTML/XHTML valide en spécifiant quel fichier utiliser pour l'image. Cette méthode que nous allons étudier permet d'affecter une image de site suivant les pages sur lesquelles on circule.

Pour être dans les clous du W3C, il faut spécifier que nous allons utiliser une image (ici, nous avons le choix du nom):

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en-US">
<head profile="http://www.w3.org/2005/10/profile">
<link rel="icon" type="image/png" href="http://monsiteweb.org/monicone.png">

Le lien de type rel ne dispose pas d'attributs W3C propres, on peut donc lui en affecter sous réserve de lui faire un profil d'attribut. La ligne <head profile="http://www.w3.org/2005/10/profile"> est un lien vers la description de ce profil. A noter que ce profil est proposé par le W3C mais ne constitue pas un standard.

Voilà, mes 2 cents (de $ et pas d'€)...

Références:

Posted ven. 27 juin 2008 16:42:00 Tags:

Cloner un système en production

Parfois, il arrive que l'on doive cloner un système qui est déjà en production. L'objectif peut être variable:

  • Le désir de sauvegarder à chaud l'intégralité du système.
  • Disposer d'une solution de secours en cas de panne matérielle.
  • Analyser les problèmes de configuration ou de comportement avec une machine de tests.
  • Réaliser des tests d'intégration
  • le fun ...

Dans cet article, je parlerai bien sûr de ce que je connais bien: les systèmes GNU/Linux, les autres ne m'intéréssant pas du tout, pour des raisons de temps, d'argent et d'éthique !

Une méthode simple

La méthode est simple. Elle repose sur un seul programme qui est assez connu: rsync. Ce petit programme est très astucieux et va nous permettre de parvenir à nos fins de manière assez simple. L'impératif est donc de pouvoir installer rsync sur les deux machines. Sans cela point de salut ! Il va nous falloir également un live CD avec rsync dessus pour la machine cible: je pars de l'hypothèse que le clone n'a pas de système d'exploitation (ou bien un qu'on peut supprimer).

De plus, n'oublions pas que nos deux machines peuvent être très différentes matériellement. En règle générale, les serveurs de production contiennent de la donnée (SGBD, fichiers , répertoires web, etc...). Leur capacité disque est donc souvent importante. Pour faire des tests, on n'a pas forcément besoin de récupérer tout ces fichiers et il est fort possible que nous disposions juste d'une vieille machine pour cloner un serveur en production à la pointe du dernier cri (de la mort qui tue).

Pour des raisons de clarté, les deux machines employées seront nommées de la manière suivante:

  • Source: la machine à cloner. Elle peut disposer d'une configuration matérielle très spécifique ainsi que de systèmes de fichiers exotiques.
  • Cible: le clone.

Faisons un peu le tour de la technique:

  • Installer rsync sur les deux machines
  • Lancer le liveCD sur la Cible.
  • Créer des partitions sur la cible, le système de fichiers importe peu pour le système, davantage pour les données (utilisation d'ACL, de quotas, d'attributs spécifiques, etc...).
  • Recopier l'ensemble des fichiers qui nous intéressent sur le serveur Source.
  • Modifier quelques paramètres pour permettre au noyau de la Cible de démarrer.

Rien de bien sorcier sauf la dernière étape qui est fonction de la machine Cible, bien entendu.

Un exemple concret

J'ai dû cloner un système en production sur mon lieu de travail. Le deal était de disposer d'une machine semblable du point de vue logiciel à un serveur bureautique en production que je ne pouvais forcément pas arrêter sous peine de tout casser et d'avoir une centaine de personnes privées de leur moyen de travailler.

Voici à quoi ressemble la bête Source:

  • Dell PowerEdge 800 de quelques années en Intel Xeon 32 bits avec 1,5 Go de RAM
  • Un disque système de 80Go bien partitionné dans la majorité des cas en ReiserFS (cher Hans, c'était avant que ta femme meure !): 8 partitions allant de root en passant par le swap, /var, /opt, /tmp, /usr et /home en une partition pour le cas où !
  • Un disque de data composé matériellement d'un RAID 5 sur 4 disques de 80Go en SATA, partitionné avec du LVM2 sur lequel vient se mettre une couche DRBD (pour la synchronisation sur une machine de spare) et enfin trois partitions en système de fichier XFS. L'ensemble pèse 220Go et les partitions sont montées à partir du répertoire /data
  • Les contrôleurs disques sont comme indiqués en SATA.
  • Il existe quelques cartes SCSI pour le lecteur de bandes pour les sauvegardes.
  • La machine est équipée de 2 cartes réseaux (1pour la production, 1 pour le spare réseau).
  • Le tout tourne bien entendu sous Debian GNU/Linux mais en Sarge !
  • Les services apportés par cette machine sont grosso-modo!: samba, openLDAP et CUPS.

Maintenant, passons à la machine de test Cible:

  • Pentium 4 2Ghz avec 512Mo de RAM
  • Un disque de 40Go en IDE
  • Une carte réseau !

Les configurations sont bien différentes, le matériel aussi. Comme le noyau utilisé par Debian est assez génériques, je devrai réussir à récupérer un système à peu près stable et qui peut tourner ! Appliquons la méthode:

Sur le serveur Source

  • Installer rsync: aptitude install rsync

Sur le serveur Cible:

  • Démarrer avec un CD de boot sysrescueCD
  • Paramétrer le réseau: dhclient eth0
  • Lancer fdisk et créer des partitions adaptées (un / sur /dev/sda1 et un swap sur /dev/sda2)
  • Créer un système de fichier extended3 sur la partition root: mkfs.ext3 /dev/hda1
  • mkdir /mnt/target
  • monter la partition root cible: mount /dev/sda1 /mnt/target
  • lancer la commande rsync: rsync -Sa --numeric-ids --exclude=/proc --exclude=/sys -e 'ssh -c blowfish -l root' Source:/ /mnt/target/
  • créer les répertoires /sys et /proc: mkdir /mnt/target/sys; mkdir /mnt/target/proc
  • Modifier le fichier /etc/fstab en fonction des éléments du nouveau serveur (/dev/hda1 est root)
  • Modifier le fichier de grub: /mnt/target/boot/grub/menu.lst et mettre la variable root à /dev/hda1.
  • Lancer grub-install pour installer le bootloader sur le disque dur: grub-install -root-directory=/mnt/target /dev/sda (ce n'est pas le le bootloader de la Debian Sarge mais bien celui de sysrescuecd ce qui ne nous gène pas).
  • Rebooter la machine

Quelques explications

SysRescueCD tourne avec un noyau 2.6.25 alors que Sarge est en 2.6.8 ! C'est là qu'on voit qu'il y a eu beaucoup d'évolutions dans le kernel en 3 ans: le pilote IDE est différent: les périphériques en /dev/sd sous le 2.6.25 sont encore reconnus comme des /dev/hd sous le 2.6.8. Rien que ça à gérer, c'est énorme surtout pour le processus de boot ! Sous le 2.6.8, l'image initrd est encore en CramFs alors que sous le 2.6.25, elle est en initramfs.

Tout cela nous oblige à effectuer quelques modifications (le fstab, la config de Grub). Toutefois, cela ne suffit pas ! Un système ainsi configuré ne peut pas booter..., le noyau se lance correctement mais init ne peut pas monter la racine. Pour régler le problème, l'astuce consiste à modifier l'image initrd du noyau de la machine clonée (là, on met vraiment les mains dans le camboui).

  • La manipulation suivante se fera sur une debian Etch ou Lenny ( la machine Cible ne fonctionne pas encore !).
  • Récupérer l'image initrd à modifier (celle du serveur Source ).
  • Sur une station de travail, récupérer les cramfsprogs: aptitude install cramfsprogs
  • Décompresser l'image avec la commande: cramfsck ./initrd.img -x répertoire_temporaire
  • Modifier le fichier ./répertoire_temporaire/script (contient root=/sda1, le changer en root=/dev/hda1).
  • Reconstruire l'image initrd: mkcramfs ./repertoire_temporaire/ ./initrd_mod.img
  • Mettre l'image initrd modifiée sur la machine Cible (avec SysRescueCD par exemple)
  • Rebooter: ça marche !

Conclusion

On a bien vu que le clonage d'une machine en production est assez facile avec cette méthode. On récupère tout, y compris les périphériques /dev. Rsync est assez intéressant de ce point de vue car la "perturbation" de la machine de production est assez faible :installation d'un seul paquet, un peu de bande passante pour faire passer les fichiers.

La méthode permet de s'affranchir des partitions (passage de 8 partitions à 2) ainsi que des systèmes de fichiers: le sysfs du système Source était en ReiserFS et notre système Cible était en ext3.

Ce qui reste complexe à gérer, c'est la différence de comportement du noyau sur la machine Cible avec tout ce que cela peut engendrer.

Références

Posted sam. 28 juin 2008 06:52:00 Tags: