Mais comme diraient mes amis « perlistes »… « perliens »… « perleurs »…bref… qui parlent Perl courrament  :

« There’s More Than One Way To Do It  » (TIMTOWTDI).

A l’extrême, une autre façon consiste à faire un bon « disk dump - dd » du disque vers un fichier « raw »   (ie par ex : # dd if=/dev/sda of=/chemin/fichier.raw). Ce fichier sera ensuite utilisé comme disque virtuel. Je n’ai jamais testé, mais je ne vois pas pourquoi ça ne fonctionnerait pas, à condition bien sûr, que le serveur d’origine n’intègre pas de matériels trop exotiques. Cependant, un des avantages de la virtualisation, lié à l’allocation dynamique de l’espace de stockage, est perdu. En effet, l’espace disque libre est « dumpé » et occupera de la place sur le serveur final. Paradoxal non ? Même si le procédé pourrait être amélioré en utilisant « partimage », pour gérer un peu mieux l’espace non occupé, il faut bien avouer que ce procédé demeure quelque peu « bourrin ».

Entre les deux, je vous propose d’explorer une piste nommée « Mondo ».

« Mondo Rescue »  est un utilitaire, sous licence GPL, qui permet de créer, sur des supports variés (CD, DVD, bande, montage réseau ou disque dur), une image complète ou partielle d’un système Linux.  A l’instar de Ignite sous HP-UX ou Ghost sous Windows.

Son premier atout, est qu’il s’installe sur le système et permet de créer l’archive à chaud. L’intégralité de la migration pourra se dérouler avec un serveur physique fonctionnel. Ce dernier sera arrêté au dernier moment, quand la machine virtuelle sera capable de prendre le relai.

Son deuxième atout est sa capacité à créer une image « iso » bootable et compressée, dont la fonction est de restaurer notre système en s’adaptant au nouveau matériel. A l’inverse de « dd » ou de « partimage », qui réalisent des copies physiques de blocs du système de fichier, Mondo re-crée le partitionnement mémorisé, y restaure les fichiers sauvegardés et en dernier lieu, réinstalle le « bootloader ».

Avant d’aller plus loin, j’attire votre attention, chers lecteurs, sur le fait que la solution « mondo » n’est pas fiable à 100%.  Il n’est pas rare, dans le cas de partitionnements un peu complexes (basés sur LVM entre autres), que ce dernier s’emmêle les pinceaux et donne envie irresistible de s’arracher les cheveux (pour peu qu’il nous en reste !). Je ne vais pas vous infliger le refrain « je ne suis pas responsable bla bla bla… », mais faites tout de même gaffe en production. Si je devais qualifier cette solution en quelques mots, je dirais qu’elle est performante mais reste assez artisanale. Ceci dit, si je prends la peine d’écrire ce billet, c’est qu’elle présente un intérêt (enfin, j’espère) et qu’elle peut tout de même rendre de fiers services.

Installation

Le site officiel fournit  les paquets pour de nombreuses distributions. Sous Debian, il est, en plus, possible d’utiliser les dépôts :

deb ftp://ftp.mondorescue.org/debian X.0 contrib

ou X est le numéro de version ( 4 pour Etch, 5 pour Lenny, 6 pour Squeeze).

Par exemple, pour l’installer sous Squeeze :

# echo « deb ftp://ftp.mondorescue.org/debian 6.0 contrib »  > /etc/apt/source.list.d/mondo.list

# apt-get update

# apt-get install mondo

 Note pour Squeeze : Mondo utilise les outils mkisofs pour la génération des images iso et cdrecord pour la gravure de CD. Ces outils ont été respectivement remplacés dans Squeeze, par  genisoimage et wodim. Il est possible de s’en sortir (pas très proprement), en créant des liens symboliques :

# ln -s /usr/bin/genisoimage /usr/bin/mkisofs

# ln -s /usr/bin/wodim /usr/bin/cdrecord

Il m’est arrivé de rencontrer quelques problèmes avec « Mindi » . Pour la création du boot de l’image iso, un ramdisk est utilisé, sur lequel on est parfois à l’étroit.  On peut l’augmenter en dé-commentant et en affectant une plus grande valeur au paramètre « EXTRA_SPACE » du  fichier de configuration de « Mindi »   (/etc/mindi/mindi.conf).

Utilisation

Il y a encore « More Than One Way » pour utiliser Mondo. La première se fait par une interface « curses », affichée par défaut, lors de l’exécution de mondoarchive sans paramètre.

La deuxième est bien entendu en ligne de commande :

# mondoarchive -O -p nomarchive -i -I / -d /destination -E /destination -T /temporaire -S /Scratchdir -s taille

• -O : pour créer une archive, par opposition à -V pour une vérification,
• -p nom : pour donner un nom à l’archive ( mondoarchive par défaut),
• -i : pour générer une ou des images iso,
• -I : pour spécifier de départ de l’arborescence à sauvegarder. « / » est par défaut, mais nous pouvons décider de ne sauvegarder qu’un bout de l’arborescence,
• -d : l’emplacement des fichiers finaux (iso),
• -E : Les répertoires à exclure. /tmp, /proc, /sys et les montages médias sont exclus par défaut, il convient, en plus, d’exclure le répertoire destination de l’image,
• -T : Le répertoire temporaire. Par défaut, Mondo choisira la partition disposant du plus grand espace disponible,
• -S   : Le répertoire du scratchdisk, c’est à dire le répertoire dans lequel seront construites les images pour la génération des fichiers iso, comme pour le répertoire temporaire, Mondo choisira par défaut la partition disposant du plus grand espace libre,
• -s : La taille maximale des fichiers iso. Si le but est de graver ces fichiers, il faudra choisir une taille adéquate en fonction du média utilisé  : ~ 700 Mo (700m) pour un CD, ~4.7 Go (4.7g) pour un DVD. Autant d’images que nécessaire seront générées.

Un exemple :

# mondoarchive -O -p serveur1 -i -I / -d /home/joel/mondo -E /home/joel/mondo -s 10g

Les images iso porteront le nom « serveur1-x.iso » (x = numéro incrémentiel) est seront placées dans le répertoire « /home/joel/mondo« . Ce répertoire est exclu de l’archive  et les images ne feront pas plus de 10 Go.

Les autres options sont laissées par défaut.

Ensuite, c’est le moment, tant connu des informaticiens, de laisser bosser la machines et d’aller vaquer à d’autres occupations.

Quelques « occupations » plus tard, l’image générée peut être utilisée pour installer la machine virtuelle, en la transférant sur l’hyperviseur  et en l’utilisant comme CDRom virtuel par exemple.

Au boot et après une détection du nouveau matériel, l’interface propose diverses options, dont l’une est « Automatique » pour une réinstallation à l’identique, une autre, « Manuelle », permet, entre autre, d’aller trifouiller le partitionnement et l’adapter –  Très utile quand la taille de l’espace disque allouée à la VM diffère du disque original.

Les données restaurées et avant l’écriture du secteur d’amorçage, il est possible de prendre la main dans un chroot, afin de vérifier le bon montage des partitions, modifier si nécessaire les fichiers de configuration et si besoin regénérer le initramfs  pour qu’il prenne en compte le nouveau matériel.

Pour terminer, je vous propose d’illustrer cet article par un screencast. Il reprend la migration d’un serveur physique sous Debian Squeeze vers une machine virtuelle Proxmox VE / KVM ( précédent article).

Click here to view the video on YouTube.

Sources :

• Site officiel,
• Wikipedia.

Proxmox Virtual Environnement

Proxmox VE s’installe sur un serveur nu, à partir d’une image iso téléchargeable sur le site officiel. Etant donné qu’il repose sur une distribution Debian Lenny, il est tout à fait possible de l’installer, sur un système existant, à partir de paquets. La dernière version (1.8) utilise les extensions de virtualisation des processeurs 64 bits, elle n’est disponible que pour cette architecture, inutile donc,  de tenter une installation sur une machine 32 bits.

Une interface web d’administration offre une surveillance et une gestion simplifiée des machines virtuelles KVM (kernel-based Virtual Machine) et para-virtuelles OpenVZ . Nous pouvons en quelques clics, créer, modifier, supprimer, démarrer, arrêter, suspendre ou visualiser l’état d’une machine.

Des outils, en lignes de commandes, permettent des fonctionnalités plus poussées, telles que la sauvegarde à chaud par snapshot ou la restauration.  Enfin, des fonctions de clustering permettent, par exemple, la migration à chaud de machines virtuelles d’un serveur physique à un autre.

Je vous propose ci-dessous, trois petites démonstrations en screencast. La première montre l’utilisation de l’interface Web pour la création et l’installation d’un serveur virtuel kvm sous Debian Squeeze, la deuxième, le clonage de ce serveur à l’aide des outils de snapshot et de restauration et enfin, la troisième, la création d’un cluster de deux serveurs Proxmox VE ainsi que la migration d’une machine virtuelle d’un serveur vers l’autre.

Démo n°1 – Installation d’un serveur virtuel Debian.

Click here to view the video on YouTube.

Démo n°2 – Utilisation des outils de sauvegarde et de restauration pour le clonage d’une VM.

Click here to view the video on YouTube.

Démo n°3 – Création d’un cluster Proxmox VE et migration à chaud.

Click here to view the video on YouTube.

Sources :

• Site officiel Proxmox,
• Wikipedia.

Sa première originalité est sa capacité à embarquer une version portable de Virtualbox (portable-Virtualbox) pour permettre l’exécution de la distribution dans une machine virtuelle, directement depuis Windows, sans aucune installation, ni reboot. Sa deuxième est, sous réserve d’espace suffisant, la possibilité de conserver les documents présents sur la clé et de continuer à l’utiliser de façon tout à fait classique.

L’opération se déroule en cinq étapes :

Etape 1 :

• Choix du périphérique de stockage USB qui va accueillir la distribution,

Etape 2 :

• Choix de la source entre :
• Une image locale au format iso, dmg ou zip,
• Le téléchargement manuel ou automatique à partir d’une bonne liste de distributions. Des tests sont réalisés pour trouver le miroir le plus rapide, – classe !
• Un CDRom ou DVD inséré dans le lecteur.

Etape 3 :

Etape 4 :

Etape 5 :

Liens :

• Site officiel : www.linuxliveusb.com
• Distributions supportées.

C’est en vidéo, c’est en Français et c’est par ici (http://torglut.blogspot.com/) !

Bonne visite !

Bien sûr, nous pouvons toujours nous en sortir avec Dia, Inkscape, Openoffice ou tout autre logiciel permettant le tracé de formes géométriques, mais le fait de de disposer de modèles de composants (widgets), à l’échelle, facilement positionables et alignables apportent un confort non négligeable.

Vous l’avez compris, Evolus Pencil Project rempli parfaitement ce rôle.

Pencil Project, à ne pas confondre avec l’outil de dessin et d’animation 2D du même nom (pencil), est une extension Firefox, développée sous licence GPL par la société Vietnamienne Evolus. Elle est tout de même disponible en version « standalone« , grâce à une exécution avec Xulrunner.

L’interface est sobre et la prise en main extrêmement rapide. L’application est fournie avec plusieurs styles de « widgets » qui s’intègrent dans votre maquette par un simple glissé / déposé. Des guides dynamiques aident au positionnement des composants. Les principales fonctions de dessin vectoriel sont disponibles (dessus, dessous, alignement, agrandissement, rotation, etc…) et permettent de fignoler la mise en page pour un résultat très propre.

Copie d’écran

L’enregistrement des fichier se fait sous l’extension « .ep », un format XML propre à Evolus Pencil. Pour la réutilisation d’un dessin dans un document ou tout simplement pour l’impression, il faut passer par un export au format PNG. Des exports vers d’autres formats (OpenOffice, Word, PDF, … ) sont prévus moyennant l’ajout de « templates ». A ce jour, je n’ai pas exploré cette piste, le format PNG me convenant parfaitement. Je regrette juste l’impossibilité d’imprimer directement depuis l’application.

Exemple de maquette  ( le message d’erreur a été vu sur : http://www.risacher.com/la-rache )

Lien :

Le problème principal de système, tel qu’il est décrit, est l’absence de maîtrise de la bande passante utilisée… Quand les « synchros » se mettent en route, la connexion Internet en prend un coup, souvent au dépend d’autres services. En bref, « ça rame dur ! ».

Une bonne solution pour ne pas pénaliser l’utilisation courante du réseau serait de gérer de la QoS (qualité de service), mais ça reste assez lourd à mettre en place… La gestion de la QoS au sein d’un réseau fera très probablement l’objet d’un prochain billet. En attendant, je vais aborder une solution très simple, qui permet de limiter la bande passante au niveau des clients.

« Trickle » est un gestionnaire de bande passante en espace utilisateur. Dans son utilisation la plus simple, il permet de lancer une commande en limitant sa bande passante montante (upload)  ou descendante (download), avec, respectivement, les options ‘-u‘ et ‘-d‘.

L’exemple suivant va lancer « wget » (pour télécharger les sources d’un noyau linux depuis kernel.org) en limitant l’utilisation de la bande passante à 20 Ko/s :

$ trickle -d 20 wget -c  http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.35-rc3.tar.bz2

Autre exemple : l’utilisation d’unison pour synchroniser un dossier via ssh en limitant le débit montant à 10 Ko/s et le débit descendant à 30 Ko/s.

$ trickle -u 10 -d 30 unison ~/JopaOne ssh://joel@monserveur.jopa.fr//home/joel/JopaOne

Trickle peut fonctionner en mode « collaboratif » grâce à un démon : trickled, qui peut, lui aussi, être lancé en espace utilisateur. Contrairement à l’utilisation précédente, la limitation n’est plus définie pour chaque commande mais  la bande passante maximale est passée en paramètres au démon et partagée par toutes les instances de trickle.

$ trickled -u 10 -d 30 

$ trickle unison /home/joel/JopaOne ssh://joel@monserveur.jopa.fr//home/joel/JopaOne -batch

$ trickle wget -c  http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.35-rc3.tar.bz2

Si besoin, il est également possible de prioriser certaines applications par rapport à d’autres pour ce partage de ressources. Je vous renvoie vers le man ou le site du projet pour la liste des options et paramètres disponibles.

Lien :

Trickle (http://monkey.org/~marius/pages/?page=trickle)

Lors d’un redimensionnement classique ou plus exactement de l’étirement d’une image, cette dernière est déformée uniformément, ce qui donne, très souvent, un résultat qui n’est pas franchement terrible.

« Liquid rescale » est une implémentation de l’algorithme « Seam Carving« . Un algorithme de redimensionnement d’image écrit par Shai Avidan et Ariel Shamir (ce sont eux les bons !!!), qui va privilégier la déformation de zones dites de moindre importance. L’importance d’un pixel est détecté par la mesure de son contraste par rapport aux pixels voisin. Nous avons la possibilité d’aider le plugin en repérant, grâce à un masque,  les zones de grande importance qu’il faudra éviter de déformer.

Prenons un exemple :

J’avais une belle photo pour l’occasion, mais Madame m’a opposé son droit à l’image. J’ai cédé à la censure et vous propose ici une photo beaucoup moins bonne, mais néanmoins suffisamment démonstratrice.

Image d’origine

Je souhaite, afin de donner une sensation d’espace, doubler la largeur de la photo, sans toucher à la hauteur (c’est un peu excessif, mais d’autant plus parlant pour l’exemple). Un redimensionnement classique sans conservation du ratio hauteur/largeur va donner l’image affreuse suivante :

Image étirée grâce à la fonction classique « échelle et taille de l’image ».

Nous avons l’habitude des écrans 16/9ème mal réglés, mais ici, le résultat est quand même bien tassé… L’effet de déformation est flagrant sur le personnage.

Le plugin magique, après un minimum de manipulations, va nous donner un résultat bien meilleur :

Image étirée grâce au plugin Liquid Rescale

Le jeune homme est préservé de toute déformation et reste svelte et beau !

Utilisation :

Ce plugin est automatiquement installé sous Ubuntu avec le paquet « gimp-plugin-registry »… Dans tous les cas, il peut être téléchargé depuis le site officiel.

Nous allons voir son utilisation, pas à pas… Prenons une autre photo :

Une fois l’image chargée dans Gimp, commençons par repérer les zones importantes (à ne pas déformer) sur un nouveau calque transparent :

Menu : Calque => Nouveau Calque

(ou Shitf + Ctrl + N )

Sur ce nouveau calque, nous allons colorier les zones à préserver, c’est à dire,  ici, les deux personnages.

Sélectionnons maintenant le calque d’origine (l’arrière plan) et lançons le plugin :

Menu : Calque => Redimensionnement Liquide…

Ajustons la largeur ( Une fois de plus, pour l’exemple, la valeur de la largeur est doublée).

Dans la zone « Masque de conservation d’éléments » :

Nous allons activer « Conserver les éléments » et sélectionner le calque sur lequel nous avons colorié.

Il ne reste plus qu’à valider.

Comme nous l’avons fait pour la conservation d’éléments, il est possible de passer au plugin un calque contenant des éléments à supprimer. Cette fonction est utilisée pour faire disparaitre des éléments et est plus efficace lors d’une réduction d’image.

Le but, ici, n’est pas de fournir un dossier détaillé, mais plutôt de faire un témoignage ou donner un retour d’expérience sur ce que peut-être l’amusante mise en place d’une petite solution de domotique.

L’idée de départ était de pouvoir faire des choses relativement simples, telles que :

• Fermer les volets, couper l’alimentation de certains appareils au lieu de les laisser en veille ( TV, ampli, moniteurs, imprimantes) et éteindre les lumières lorsque l’alarme est activée,
• Faire l’opération inverse lorsque l’alarme est désactivée,
• Allumer automatiquement certaines lumières à la tombée du jour,
• Ouvrir automatiquement les volets le matin en guise de réveil,
• Mettre automatiquement en marche mon serveur de sauvegardes chaque nuit et l’éteindre une fois les backups terminés,
• etc…

Cette installation, en plus du respect évident des trois lois de la robotique, se devait de ne pas négliger le WAF (Woman Acceptance Factor). En bref, une simplicité maximale d’utilisation et le moins d’aléas possible – Hors de question, pour la pérennité du projet,  que la TV s’éteigne par « accident » en plein dénouement d’un épisode des « Experts » , la série préférée de Maman…

1 – Une norme et du matériel,

Pour mener à bien ce projet, j’ai utilisé la technologie courant porteur X10… Un système qui n’est plus tout jeune (1975), mais qui a le mérite d’être simple à mettre en oeuvre, toujours fonctionnel et pas trop cher (enfin… tout est relatif).

Il existe deux principaux types de modules : les  contrôleurs et les récepteurs. Le système X10 utilise le réseau électrique existant pour diffuser des trames aux différents modules. Les trames sont structurées avec une partie adresse et une partie commande (ou ordre).

Une adresse X10 est composée :

• d’un code maison, sur 4 bits, de A à P,
• et d’un code appareil, sur 4 bits également,  de 1 à 16.

Comme nous sommes sur un principe de diffusion, nous pouvons configurer plusieurs modules avec la même adresse – tous les récepteurs voient passer les trames, mais n’exécutent l’ordre que si l’adresse leur correspond.

Ci-dessous, la liste non exhaustive des  ordres qui peuvent être transmis :

• Marche (ON), Arrêt (OFF),
• Variation croissante (BRIGHT + Valeur), variation décroissante (DIM + Valeur),
• Toutes les lumières allumées (ALL LIGHTS ON) ou éteintes (ALL LIGHTS OFF),
• Tout allumé, sans distinction du type d’appareil (ALL ON) ou tout éteint (ALL OFF).

Récepteurs (exemples) :

Les récepteurs, comme leur nom l’indique, vont être réceptifs aux ordres X10 pour effectuer l’action commandée. Le tableau ci-dessous présente quelques exemples de matériels :

	Module Appareil : Se connecte entre la prise et l'appareil. Est capable d'interpréter des ordres ON et OFF.
	Module lampe : Identique au module appareil, mais ne supporte pas des intensités élevées. Il est toutefois capable de gérer des commandes supplémentaires (DIM / BRIGHT) .
	Module lampe (douille) : S'insère entre l'ampoule et la douille d'origine.
	Module mural : remplace un interrupteur. Existe en version variateur ou 3 positions pour volets roulants ou stores.
	Micro module : se positionne derrière un interrupteur existant (dans la boite d'encastrement).
	Module rackable : Prend place directement au niveau du tableau électrique.

Contrôleurs (exemples) :

Les contrôleurs sont capables de générer des trames X10 sur le réseau.

	Le CM11 est le module indispensable. Connecté au port série ou usb d'un ordinateur, il va nous permettre de communiquer avec le réseau X10. Il est capable de recevoir ou d'envoyer des trames X10. Il est programmable, pour un fonctionnement ordinateur éteint. Ce modèle est apparemment obsolète et remplacé par le CM15.
	Le module radio permet de transformer des ordres RF, émis depuis une télécommande ou un capteur sans fil en ordre X10.
	Un exemple de détecteur sans fil. Il joue le rôle de détecteur de présence, mais aussi d'obscurité.
	Centrale d'alarme X10 capable de générer des ordres X10 en fonction d'évènements : Armement, désarmement, déclenchement, etc... Elle peut également servir de console de commande X10.

2 – Des logiciels,

MisterHouse

MisterHouse est probablement le projet le plus complet de domotique libre.

• Il supporte des matériels allant bien au-delà du X10,
• Est capable d’exécuter des actions basées sur de la reconnaissance vocale, des évènements horaires, réseaux, matériels, etc…,
• Dispose d’une interface web,
• Couplé à un magnétoscope numérique (VCR), permet la programmation d’enregistrements,
• S’interface avec les mails, le téléphone,
• Gère des caméras de surveillance,
• Produit de la synthèse vocale,
• etc…etc…etc…

Bref, du lourd, du trop lourd pour un démarrage en douceur… Je voulais bricoler avec mes petites mimines et là, c’était vraiment trop d’un coup…

ControlX1O::CM11

ControlX10::CM11 est la librairie Perl MisterHouse utilise pour la gestion du X10. Elle est relativement facile à utiliser.  Je m’en suis servi pour coder un petit utilitaire, « TuX10« , qui permettait de gérer des modules X10, d’envoyer et recevoir des trames, le tout en ligne de commandes. Après avoir « pissé » un bon nombre de lignes et mon programme quasi finalisé, j’ai découvert « Heyu« , qui fait la même chose….Mais en mieux… Ce n’est pas grave, un peu de code aide souvent à comprendre pas mal de choses…

Heyu

Heyu est donc un utilitaire, qui fait la même chose que TuX10, mais en mieux

Ils s’utilise, dans un usage courant, de la façon suivante :

# heyu <Commande> <Module>

Par exemple, dans l’hypothèse ou la lumière de mon salon est adressé « A1″,

Pour l’allumer :

# heyu ON A1

Pour l’éteindre :

# heyu OFF A1

Pour l’allumer avec un variation à 50% (le niveau doit être donné entre 1 et 22) :

# heyu DIMB A1 11

C’est très pratique pour allumer un appareil à heure fixe à l’aide d’un simple cron…

Exemple : allumage de mon serveur de sauvegardes, qui porte l’adresse « C1″, tous les jours à 23H00 :

# CRONTAB
00   23   *    *    *   /usr/local/bin/heyu ON C1

Heyu dispose d’une multitude de commandes et d’options. Nous en verrons quelques unes dans la suite, pour le reste :

# heyu help

ou de façon plus classique :

# man heyu

3 – Un scénario,

Les modes de fonctionnement

J’ai imaginé trois modes de fonctionnement , en fonction de ma présence et de mon activité dans la maison : Les modes « présence », « sommeil » et « absence ».

Le mode « Présence »

C’est le mode de fonctionnement normal, quand je suis à la maison.

• Il est déclenché par l’arrêt de l’alarme ou un signal de réveil,
• Tous les appareils sont sous tension (TV, Hifi, matériel informatique, etc…),
• Les volets sont ouverts,
• La lumière du séjour s’allume automatiquement quand la nuit tombe et s’éteint quand le jour se lève – classe !

Le mode « Sommeil »

Ce mode est actif pendant la nuit, quand je dors…

• Activé manuellement via une télécommande ou la console (Signal Réveil OFF),
• Les appareils ne sont plus alimentés,
• Les volets fermés,
• Les lumières éteintes,
• La lumière du séjour/cuisine s’allume à 50% quand une présence est détectée :  Juste ce qu’il faut pour y voir suffisamment lors des excursions nocturnes près du frigo. Cette attention permet de ne pas être éblouis et de reprendre tranquillement sa nuit après le casse-croute… c’est important !
• Ce mode peut-être désactivé par un signal de réveil manuel ou automatique, pour passer en mode « Présence » (Signal Réveil ON).
• Le passage en mode « présence » est déclenché automatiquement tous les jours de la semaine à 6h30, pour bénéficier d’un doux réveil à la lumière du jour. ( Nda : Penser à ajouter un mode « vacances »…c’est tôt 6h30 quand on est en RTT !)

Le mode « Absence »

• Déclenché par la mise en marche de l’alarme,
• Identique au mode précédent, mais le seul ordre X10 pris en compte est l’arrêt de l’alarme pour le passage en mode « Présence ».

En clair, on attend juste que l’alarme soit désactivée.

4 – Et du bricolage…

Cher lecteur, si tu as tenu jusque là, c’est le moment où nous allons mettre les mains dans le cambouis… L’expression est d’usage, mais c’est plutôt dans le placo que se logent les petits bidules X10… Mais ne nous égarons pas….

Commençons par un petit état de ces différents bidules équipant la maison.

Les éléments X10 utilisés et leur adresse :

Configuration générale :

Ma première idée était de charger la totalité des règles et des macros dans le CM11, pour que le système puisse fonctionner de façon autonome, y compris quand l’ordinateur est éteint. Cependant, j’ai vite changé d’avis… La rom du CM11 est d’une taille plutôt limité et on s’arrache vite les cheveux à gérer des tests qui disparaissent en segmentant un peu les choses. Comme de toute façon, l’ordinateur n’est jamais éteint, j’ai fini par utiliser un fichier de macros par mode. Le bon fichier est uploadé lors d’un changement d’état.

Attaquons la configuration de base de heyu. Le fichier /etc/heyu/x10.conf permet de spécifier le port à utiliser pour l’accès au CM11, un code maison par défaut, de déclarer des alias pour les modules (ce n’est pas obligatoire) et enfin d’affecter l’exécution de scripts à des évènements.

# /etc/heyu/x10.conf - Fichier de configuration HEYU
 
# Port série à utiliser :
TTY  /dev/ttyS0
 
# Code maison par défaut
HOUSECODE A
 
# Fichier de LOGs
LOG_DIR /var/log/
 
# Nom du fichier contenant les macros à uploader
SCHEDULE_FILE x10.sched

Le système est capable de calculer les heures de couché et de levé du soleil en fonction de la date et de la position géographique.

# Nombre de jours à calculer
PROGRAM_DAYS           366
 
# Position Géographique
LONGITUDE   E1:30
LATITUDE     N43:30
 
# Mode de calcul
DAWN_OPTION FIRST
DUSK_OPTION  FIRST

Il est également possible de définir des alias…

# ALIAS
 
ALIAS  lampe_sejour       A1   StdLM
ALIAS  halogene           A2   StdLM
ALIAS  test1              A3   StdAM
ALIAS  test2              A4   StdAM
ALIAS  hifi               A5   StdAM
 
ALIAS  vr_jour            A7   shutter
ALIAS  vr_nuit            A8   shutter
ALIAS  vr                 A7,8
 
ALIAS  inter_reveil       A9
 
ALIAS  mvt_bureau         A10
ALIAS  obs_bureau         A11
ALIAS  mvt_sejour         A12
ALIAS  obs_sejour         A13
 
ALIAS   nuit              B1
ALIAS   alarme            B3
 
ALIAS  sauvegarde         C1    StdAM
 
ALIAS   mode_nuit         D1

Exécution de scripts sur évènement X10.

Quand l’ordre « D1 ON », qui signale la tombé de la nuit est détecté sur le réseau, on crée un fichier sur le système, qui permettra de détecter simplement s’il fait nuit ou pas… Ce flag est positionné quelque-soit le mode de fonctionnement.

# Gestion du mode nuit
SCRIPT D1 on anysrc ::  touch /var/tux10/NUIT
SCRIPT D1 off anysrc ::  rm -f /var/tux10/NUIT

De la même façon, l’ordre « A9 OFF » indique que l’on souhaite passer en mode « sommeil », « B3 ON » en mode « Absence » et « B3 OFF » ou « A9 ON » en mode présence.

# Gestion du mode sommeil
SCRIPT A9 off anysrc :: /home/heyu/mode_sommeil.sh
SCRIPT A9 on anysrc :: /home/heyu/mode_presence.sh
 
# Gestion du mode absence (alarme)
SCRIPT B3 on anysrc :: /home/heyu/mode_absence.sh
SCRIPT B3 off anysrc :: /home/heyu/mode_presence.sh

Toujours à l’heure…

Pour que tout fonctionne parfaitement, il faut s’assurer que l’horloge du CM11 est bien à l’heure… Une nouvelle entrée dans la crontab va effectuer une remise à l’heure régulière grâce à la commande « setclock » d’heyu

# CRONTAB
 
00   23   *    *    *   /usr/local/bin/heyu ON C1
00  */6   *    *    *  /usr/local/bin/heyu setclock

Le mode « présence »

Comme nous l’avons vu, ce mode est déclenché soit par désactivation de l’alarme (B3 OFF), soit par un signal de réveil (A9 ON).

Sur l’un de ces évènements, Heyu a été précédemment configuré pour lancer le script « mode_presence.sh« .
Ce dernier envoie les ordres d’ouverture des volets, de mise sous tension des appareils, allume la lumière s’il fait nuit et charge les macros de présence dans la rom du CM11.

mode_presence.sh

#!/bin/bash
# mode_presence.sh
 
# Ouverture des volets, mise sous tensions des appareils
/usr/local/bin/heyu on A4,5,7,8
 
# Allumer la lumière, si necessaire
if [ -e /var/tux10/NUIT ]; then
   /usr/local/bin/heyu on A1
fi
 
# Upload des macros si nécessaire
cmp -s /etc/heyu/x10.sched.presence /etc/heyu/x10.sched
if [ !$? -eq 0 ]; then
    cp /etc/heyu/x10.sched.presence /etc/heyu.x10.sched
    /usr/local/bin/heyu upload
fi

Au niveau des macros, on va juste définir un timer qui gère l’allumage et l’extinction automatique des lumières en fonction du jour et de la nuit.

/etc/heyu/x10.sched.presence

# x10.sched.presence
 
# Définition d'un timer tous les jours.
# Lance la macro lum_off à l'aurore,
# La macro lum_on 10 minutes avant le crépuscule.
timer smtwtfs 01/01-12/31 dawn dusk-10 lum_off lum_on
 
# Macro lum_on - Envoie les ordres A1 ON et D1 ON
macro lum_on 0 on a1; on d1
 
# Macro lum_off - Envoie les ordres A1 OFF et D1 OFF
macro lum_off 0 off a1; off d1

Le mode « absence »

Ce mode est déclenché par l’activation de l’alarme uniquement (B3 ON)

Heyu est configuré pour exécuter  le script « mode_absence.sh » lorsque le mode est activé.
Le script envoi les ordres de fermeture des volets, de mise hors tension des appareils, éteint les lumières et charge les macros d’absence.

mode_absence.sh

#!/bin/bash
# mode_absence.sh
 
# Fermeture des volets, mise hors tensions des appareils et de l'éclairage
/usr/local/bin/heyu on A1,2,4,5,7,8
 
# Upload des macros si nécessaire
cmp -s /etc/heyu/x10.sched.absence /etc/heyu/x10.sched
if [ !$? -eq 0 ]; then
    cp /etc/heyu/x10.sched.absence /etc/heyu.x10.sched
    /usr/local/bin/heyu upload
fi

Les macros et timers sont  sensiblement identiques à l’étape précédente. Nous n’allons gérer que le « flag » D1 indiquant au système s’il fait jour ou nuit – Inutile d’allumer les lumières s’il n’y a personne à la maison.

/etc/heyu/x10.sched.absence

# x10.sched.presence
 
# Définition d'un timer tous les jours.
# Lance la macro lum_off à l'aurore,
# La macro lum_on 10 minutes avant le crépuscule.
timer smtwtfs 01/01-12/31 dawn dusk-10 lum_off lum_on
 
# Macro lum_on - Envoi l'ordre D1 ON
macro lum_on 0 on d1
 
# Macro lum_off - Envoi l'ordre D1 OFF
macro lum_off 0 off d1

Le mode « sommeil »

Ce mode est déclenché par l’envoi de « A9 OFF« .

Heyu est configuré pour exécuter « mode_sommeil.sh » lors de l’entrée dans ce mode.

Le script ferme les volets roulants, coupe l’alimentation des divers appareils et éteint les lumières. Les macros « embarqués » s’occupent de l’éclairage interactif du séjour (présence près du frigo) et du réveil.

mode_sommeil.sh

# mode_sommeil.sh
 
# Fermeture des volets, mise hors tensions des appareils et de l'éclairage
/usr/local/bin/heyu on A1,2,4,5,7,8
 
# Upload des macros si nécessaire
cmp -s /etc/heyu/x10.sched.sommeil /etc/heyu/x10.sched
if [ !$? -eq 0 ]; then
    cp /etc/heyu/x10.sched.sommeil /etc/heyu.x10.sched
    /usr/local/bin/heyu upload
fi

/etc/heyu/x10.sched.sommeil

# x10.sched.sommeil
 
# Le fameux Timer qui réveille...
# Du lundi au vendredi à 6h30
# passage en mode présence
timer .mtwtf. 01/01-12/31 6:30 00:00 reveil null
# Macro réveil
macro reveil 0 on a9
 
# Ici aussi, on trace la tombée de la nuit
# et le levé du jour
timer smtwtfs 01/01-12/31 dawn dusk-10 night_off night_on
macro night_on 0 on d1
macro night_off 0 off d1
 
# Enfin, la lumière pour le casse croute..
# A12 ON : Détection d'une présence
# A12 OFF : Tout est à nouveau calme
trigger a12 on lum_on
trigger a12 off lum_off
 
# Macro lum_off
macro lum_off 0 off a1
 
# Macro lum_on : Allume la lumière à 50 %
macro lum_on 0 dimb a1 11

5 – En conclusion

Le système tel qui est décrit est fonctionnel depuis quelques années. Il faut savoir que la technologie X10 n’est pas très réactive – il peut se passer quelques secondes avant qu’un appareil réagisse à un ordre, en particulier quand l’installation prend de l’importance et que plusieurs ordres sont transmis à la suite…

J’espère que ce billet apportera des informations utiles à tous ceux qui voudraient se lancer dans une aventure « domotique ».

Liens :

• X10 sur wikipedia,
• Intellihome.be : Fournisseur de modules X10,
• MisterHouse (sourceforge),
• ControlX10::CM11 (librairie Perl),
• Heyu

Tor (The Onion Router) est un réseau permettant la transmission anonyme de paquets TCP au travers d’internet…

…Au lieu d’emprunter un itinéraire direct entre la source et la destination, les paquets de données suivent une trajectoire aléatoire à travers plusieurs relais…

La suite de ce billet donne une brève introduction à Tor et à son principe de fonctionnement, pour finir par un exemple pratique d’installation et d’utilisation.

Comment ça marche ?

Après interrogation d’un serveur Tor, le client reçoit une liste de noeuds. Il construit alors un chemin aléatoire au travers, de telle sorte que chaque relais ne connaisse que l’adresse de son prédécesseur et de son successeur. Aucun noeud ne connait à lui seul le chemin complet.

Un nouveau chemin sera recalculé régulièrement.

Pour garantir sa confidentialité dès le départ, un paquet tcp est chiffré « en couches » successives avec la clef publique de chaque noeud, en commençant par le dernier…

Lorsque le paquet parcours son chemin, chaque couche de chiffrement sera enlevée par son noeud respectif, jusqu’au dernier, qui transmettra alors le paquet en clair au serveur destinataire. Je vous laisse faire l’analogie avec l’oignon… Même si mon schéma est un peu « carré ».

Il faut être conscient, cependant, que Tor a ses limites : Il gère seulement le transport des paquets TCP et n’assure pas de protection en UDP. Protocole utilisé entre autres pour les requêtes DNS. De plus, une page web peut récolter directement des informations privées (dont l’adresse IP), directement auprès du navigateur, par l’utilisation de Javascript ou la lecture de cookies.

Pour la navigation Web, on va généralement coupler Tor  à un serveur mandataire (proxy) tel que privoxy. Ce dernier va faire l’interface entre le navigateur et Tor, tout en fournissant un filtrage anonymisant supplémentaire (gestion des cookies, des accès, suppression des pubs, etc…).

En pratique

Tor est disponible sous licence BSD et facilement installable pour la majorité des distributions Linux et BSD. Il est également disponible pour de nombreuses plateformes telles que Windows, OSX ou Androïd… si si !).

Sous Ubuntu 10.4 :

 # echo "deb http://deb.torproject.org/torproject.org lucid main" >
         /etc/apt/sources.list.d/tor.list
 # gpg --keyserver keys.gnupg.net --recv 886DDD89
 # gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
 # apt-get update
 # apt-get install tor privoxy
. 

Un (tout) petit peu de configuration…

/etc/privoxy/config/

...
#  Décommenter la ligne suivante pour connecter Privoxy à Tor
forward-socks5   /               127.0.0.1:9050 .
...
# Il peut être judicieux de commenter la ligne suivante pour
# que les logs ne soient pas écrits.
# logfile logfile
...

On redémarre tout ça :

 # /etc/init.d/tor restart
 # /etc/init.d/privoxy restart

Privoxy doit ensuite être déclaré comme proxy dans les préférences du navigateur ou directement dans les préférences réseaux de Gnome. Dans l’exemple, nous avons bien une installation locale (127.0.0.1) et le port laissé par défaut (8118).

Le premier indice permettant de conclure que la configuration est bonne est la lenteur de la navigation. Le passage au travers du réseau Tor ne se fait pas sans perte de performances…

Le second peut se trouver sur la page : http://www.monip.org, qui ne devrait plus retourner notre adresse IP publique, mais celle du dernier relai traversé.

Au delà de la navigation

Au delà de la navigation web et des services pris en charge par le proxy, TOR est capable de sécuriser les connexions d’autres services grâce à la commande « torify« . Par exemple, la commande suivante permet une connexion ssh à travers le réseau Tor.

$ torify ssh mon.serveur.public.et.fictif.com

Voilà pour un petit tour rapide au pays de Tor… Pour (beaucoup) plus d’informations, je vous conseille de visiter le site officiel du projet et sa page Wikipédia.

Liens :

• Tor Project,
• Wikipedia – Tor (Réseau),
• Privoxy.

J’ai eu l’agréable surprise de découvrir qu’il existait un paquet pour Squeeze, mais après une bonne soirée d’acharnement, je n’ai pas réussi à obtenir quelque chose de vraiment fonctionnel. Une interface web pleine de bugs, des modules manquants, bref, pas génial génial.

L’installation étant bien documentée, sur le site officiel, pour une distribution RedHat, je me suis finalement résigné à tenter le coup sur une CentOS 5.  Après tout, je n’avais pas mis le nez dans une RedHat depuis des lustres, c’était l’occasion.

Heureux de cette expérience réussie sous CentOS, j’ai ressenti une pointe de frustration de n’avoir pas pu faire tourner le binious sous ma distribution préférée. J’ai finalement consacré une dernière soirée à une installation à partir des sources, sous Lenny.

CentOS 5

La documentation officielle est très bien faite et ne justifie pas un article dédié à l’installation sous CentOS. Il faut veiller cependant à adapter la configuration du dépôt utilisée dans cette doc, en remplaçant RHEL5 par CentOS5.

/etc/yum.repos.d/inverse.repo

[RHEL5]
 
name=Inverse SOGo Repository
 
#baseurl=http://inverse.ca/downloads/SOGo/RHEL5/$basearch
 
baseurl=http://inverse.ca/downloads/SOGo/CentOS5/nightly/$basearch
 
gpgcheck=0

Note : J’ai utilisé la branche « nightly » après avoir rencontré des problèmes de dépendances avec la branche classique (inverse.ca/downloads/SOGo/CentOS5/$basearch). C’est évidemment peu recommandé pour une machine en production.

A noter également que la doc est basée sur une utilisation avec postgresql, mais passe sous silence l’installation de ce dernier. Un petit coup de « yum » règle rapidement le problème :

# yum install postgresql-server

Enfin, j’ai bloqué un petit moment à cause du firewall SeLinux qui interdit par défaut les connexions sur le port http. Pour autoriser les connexions au port 80 :

# setsebool httpd_can_network_connect=1

Debian Lenny

Pré-requis

SOGo utilise un LDAP pour l’authentification et les annuaires mails centralisés, un serveur SMTP et IMAP pour la gestion des mails. Dans cet exemple, je vais me baser sur l’architecture décrite ici :

Installation d’un serveur mail brique par brique… (OpenLDAP, Postfix, Cyrus-imap, TLS, SASL, Spamassassin, Amavis, etc…)

Installation de quelques paquets nécessaires au fonctionnement et à la compilation de SOGo ( Apache2, GNUStep, Postgresql, etc…)

# aptitude install apache2 apache2-mpm-prefork apache2-prefork-dev
# aptitude install postgresql
# aptitude install make patch subversion monotone
# aptitude install gobjc gnustep-make libgnustep-base1.16 libgnustep-base-dev libpq5 libpq-dev libldap2-dev libxml2-dev libmysqlclient15-dev gnustep-base-common gnustep-base-runtime

La compilation de SOGo nécessite la librairie Memcached (libmemcached2 libmemcached-dev), non disponible par défaut sous Lenny. Les paquets peuvent cependant être empruntés à Squeeze :

- http://packages.debian.org/squeeze/libmemcached2
- http://packages.debian.org/squeeze/libmemcached-dev

# aptitude install memcached
# dpkg -i libmemcached2_0.31-1_i386.deb libmemcached-dev_0.31-1_i386.deb

Postgresql

Création d’un utilisateur « sogo » dans postgresql et création d’un base « sogo« .

# su – postgres
$ createuser –no-superuser –no-createdb –no-createrole –encrypted –pwprompt sogo
$ createdb -O sogo sogo

Note : Pour l’exemple, j’ai utilisé « sogopasswd » comme mot de passe.

Récupération des sources

SOGo  ( monotone )

$ mtn db init –db=db.mtn
$ mtn –db=db.mtn pull inverse.ca ca.inverse.sogo
$ mtn –db=db.mtn checkout –branch ca.inverse.sogo SOGo

SOPE (Subversion)

$ svn export -r 1660 http://svn.opengroupware.org/SOPE/trunk/ SOPE

Compilation

SOPE

$ cd SOPE
$ patch -p0 < ../SOGo/SOPE/sope-patchset-r1660.diff
$ patch -p0 < ../SOGo/SOPE/sope-gsmake2.diff
$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
$ ./configure –with-gnustep –enable-strip –enable-debug
$ make
$ su
# make install
# exit

SOGo

$ cd ../SOGo
$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
$ ./configure –enable-strip –enable-debug
$ make
$ su
# make install
# cp Scripts/sogod-wrapper /usr/sbin/
# cp debian/sogo.init /etc/init.d/sogo

# chmod +x /etc/init.d/sogo

Edition du fichier /etc/init.d/sogo pour affecter 3 à la variable PREFORK. Ce qui permet de lancer 3 démons Sogo simultanément.

/etc/init.d/sogo

...
 
# specify more if you are using a load-balancer
 
# PREFORK=1
 
PREFORK=3
 
SOGO_ARGS=""
 
USER=sogo
 
...

Configuration

Création d’un utilisateur « sogo » :

# adduser sogo –home /var/lib/sogo

Création des répertoires :

# mkdir /var/spool/sogo /var/run/sogo /var/log/sogo
# chown -R sogo /var/spool/sogo /var/run/sogo /var/log/sogo

Création du fichier de configuration :

# su – sogo
$ mkdir -p GNUstep/Defaults
$ vi GNUstep/Defaults/.GNUstepDefaults

/var/lib/sogo/GNUstep/Defaults/.GNUstepDefaults

{
     NSGlobalDomain = {
     };
     gdnc = {
};
 
sogod = {
    NGImap4DisableIMAP4Pooling = YES;
    NGUseUTF8AsURLEncoding = YES;
    OCSFolderInfoURL = "postgresql://sogo:sogopasswd@localhost:5432/sogo/sogo_folder_info";
    SOGoACLsSendEMailNotifications = YES;
    SOGoAppointmentSendEMailNotifications = YES;
    SOGoAuthenticationMethod = LDAP;
    SOGoCalendarDefaultRoles = (
     PublicViewer
);
 
SOGoDefaultLanguage = French;
SOGoDefaultMailDomain = linet.jopa.fr;
SOGoDraftsFolderName = INBOX/Drafts;
SOGoFallbackIMAP4Server = mail.linet.jopa.fr;
SOGoFoldersSendEMailNotifications = YES;
SOGoLDAPSources = (
{
     CNFieldName = cn;
     IDFieldName = uid;
     UIDFieldName = uid;
     baseDN = "dc=linet,dc=jopa,dc=fr";
     bindDN = "cn=guest,dc=linet,dc=jopa,dc=fr";
     bindFields = uid;
     IMAPHostFieldName = site;
     bindPassword = "MotDePasseGuestLDAP";
     canAuthenticate = YES;
     displayName = "Adresses Jopa";
     hostname = localhost;
     id = public;
     isAddressBook = YES;
     port = 389;
     scope = SUB;
}
);
SOGoMailingMechanism = smtp;
SOGoOtherUsersFolderName = "Other Users";
SOGoProfileURL = "postgresql://sogo:sogopasswd@localhost:5432/sogo/sogo_user_profile";
SOGoSMTPServer = mail.linet.jopa.fr;
SOGoSentFolderName = INBOX/Sent;
SOGoServerTimeZone = Europe/Paris;
SOGoSharedFolderName = "Shared Folders";
SOGoTrashFolderName = INBOX/Trash;
WOApplicationRedirectURL = "http://labo.linet.jopa.fr";
WOMessageUseUTF8 = YES;
WOParsersUseUTF8 = YES;
WOPort = 20000;
 
WOUseRelativeURLs = NO;
SOGoSuperUsernames = (joel);
SOGoForceIMAPLoginWithEmail = NO;
 
};
}

Notes :

- J’utilise l’utilisateur Guest pour la lecture de l’annuaire LDAP. C’est utilisateur a des droits en lecture seule sur la branche contenant mes utilisateurs. Si l’annuaire autorise une lecture anonyme, la connexion à l’annuaire sous un utilisateur particulier n’est pas nécessaire.
- labo.linet.jopa.fr est l’url de la machine sur laquelle est installée Sogo.

Apache

Création d’un fichier de configuration : /etc/apache2/conf.d/sogo.conf

Alias /sogo.woa/WebServerResources/ \
        /usr/local/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo.woa/WebServerResources/ \
        /usr/local/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGO.woa/WebServerResources/ \
        /usr/local/lib/GNUstep/SOGo/WebServerResources/
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*jpg">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*png">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*gif">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*css">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*js">
  SetHandler default-handler
</LocationMatch>
 
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
           /usr/local/lib/GNUstep/SOGo/$1.SOGo/Resources/$2
 
<Proxy balancer://sogocluster>
  RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
  RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
 
  RequestHeader set "x-webobjects-server-port" "80"
  RequestHeader set "x-webobjects-server-name" "labo.linet.jopa.fr"
  RequestHeader set "x-webobjects-server-url" "http://labo.linet.jopa.fr"
 
 
  BalancerMember http://127.0.0.1:20000 retry=1 max=1 timeout=120
  BalancerMember http://127.0.0.1:20001 retry=1 max=1 timeout=120
  BalancerMember http://127.0.0.1:20002 retry=1 max=1 timeout=120
  ProxySet lbmethod=byrequests maxattempts=1
  Order allow,deny
  Allow from all
</Proxy>
 
SetEnv proxy-nokeepalive 1
ProxyRequests Off
ProxyPass /SOGo balancer://sogocluster/SOGo

Activation des modules apache :
# a2enmod proxy
# a2enmod proxy_http
# a2enmod proxy_balancer
# a2enmod headers

Démarrage

# /etc/init.d/apache2 restart
# /etc/init.d/sogo start

Si tout se passe bien, l’interface Web de Sogo est disponible via l’url : http://votre_serveur/SOGo

Sources :

- http://www.scalableogo.org

- http://wiki.auf.org/wikiteki/ZA/Montr%C3%A9al/SOGo/ProcedureInstallation